
21 Ideas for Software Developer - marinintim
https://marinin.xyz/en/entry/21-ideas/
======
jasode
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](https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs)

~~~
marinintim
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
> 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
> 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
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
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.

