21 Ideas for Software Developer

21 Ideas for Software Developer(marinin.xyz)

32 points by marinintim 8 years ago | 7 comments

jasode 8 years ago |

This list is fine for what it is but if we want to be meta and go a level higher, we would categorize the author's perspective as "programming is a means to an end".

Therefore, the article is really "21 Ideas for Software Developers Who are Paid to Solve Clients' Business Problems".

Yes, that can be a valid perspective but if we already agree with that as a base premise, the 21 ideas are common sense. It's tautology.

However, there is another perspective to programming which is that programming is NOT the means to an end. For some, the programming is itself the enjoyable activity. Programming is how some may self-actualize[1] and express themselves. In this case, the sentiments are reversed: any business and monetary value from programming is a side effect and the money becomes the means to an end to fund more programming.

Yes, the programming-is-just-a-tool perspective outnumbers the programming-as-artistic-expression but that doesn't change the fact that both exist. You just have to be aware that if you're a "programmer-artist" you will not fit in culturally at a Big Company that requires "boring software deliverables" from you.

[1] https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs

marinintim 8 years ago | |

That is indeed another perspective, yet not that different after all, if we'd look at what programming _is_. At its core, it is problem solving and mashing keys on the keyboard.

I don't think that keyboard part is really meaningful to anyone who claims to love programming, so it must be problem solving coupled with complex interactions between abstract idea how to solve it with concrete pecularities of programming languages, platforms, libraries, etc. The second part doesn't go anywhere whether you solve problems for Business Folks or scratch your own itch.

That means that difference between the perspectives is only who's supplying the problems. That reminds me of another distinction, namely, the one between painters and commercial illustrators (not sure if that is proper nomenclature). The path of Painter is hard and lonely, most of the painters we know today did some kind of commercial work or lived off 'grants' from philantropists. Or you can earn your paycheck doing something else and program as a hobbyist, for its own sake. I think that this is also valid programming 'culture' that exists somewhat under the radars of 'tech industry'.

mclehman 8 years ago | | |

> I don't think that keyboard part is really meaningful to anyone who claims to love programming

I'd beg to differ on that front.

cirgue 8 years ago |

> People differ and people think differently: sometimes stuff we think as difficult seems easy to business people. That is a conflict that we have to solve, not avoid.

This, and its inverse (things that seem difficult to business people might seem trivial to developers) was the biggest 'aha' moment of my career so far. As developers/engineers, we are the ones that have the best fine-grain understanding of the cost and complexity trade-offs of what we do. A big part of a developer's contribution to a project lies in communicating those trade-offs to stakeholders in a way they can reason about effectively.

the_arun 8 years ago |

Very opinionated list of thoughts. For eg. >> often ‘playing with a new framework’ doesn’t solve business problem.

May be we could re-articulate that as - Nothing wrong in playing with new frameworks as long as it results in improving the product.

mannykannot 8 years ago | |

I am fine with it the way it is, as I have seen too many 'ego' and resume-padding projects justified by nebulous claims of benefit. I was looking at a case recently, where the use of a fashionable database engine, sold on making the application more fault-tolerant in ways that did not really matter, instead impaired the exploitation of its innate parallelism.

It is not difficult for the nominal technical expert to guide a client into choosing the solution he wants, rather than the one the customer needs.

collyw 8 years ago | |

He seems to miss out that everything is a trade off.

Sure playing with a new framework may not meet the initial business needs, but it may be worthwhile in the mid to long term. Learning Django for me has paid for itself multiple times over in terms of gained productivity.

> "Every new successful framework is a step in interesting direction, so think about ‘what does this framework/library change about my work’"

I am not sure that is actually the case, especially with front end frameworks.