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
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'.
I'd beg to differ on that front.
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.
May be we could re-articulate that as - Nothing wrong in playing with new frameworks as long as it results in improving the product.
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.
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.
