What Programmers Want Is Less Stupid And More Programming
thecodist.com
thecodist.com
There are two kinds of stupid.
Goal stupid, Facebook for dogs, funded startup, take the money, be upfront about the chances for business success but professional about chances of working software
Process stupid, Facebook, but putting 30 devs in different rooms not allowing them to talk or see each others code.
Goal stupid pays the bills.
Process stupid is what you are concerned about here. Process stupid is something you can almost always change as one lone dev. You won't ever change goal stupid. Let schumpter teach them.
Over-confident idiots (especially at management positions) is the must common cause of failure.
"The best programmers are always self-motivated: just give them opportunity to rock and stay out of the way."
and
"Programmers also complain a lot and can be incredibly lazy which is a good thing as it forces them to find ways to make things easier."
Self motivation needs to be greater than laziness. :)
Or at least it does with me.
And then something flips and you get that flash of inspiration; and you dig into the program as fast as you can. In the end, you come out with a little piece of code that's relatively clean and maybe extensible and it works.
And you know... you did it... that's why you're here. Moments like that keep you going and boil your blood if you're in the world of TPS reports and their ilk.
Some people prefer rigidity. I don't understand their preference, but I respect that it is their preference. But it's hard to say that arbitrary choice always leads to anarchy or the one rigid framework always leads to inflexibility. Everything varies. That's the beauty of people - we are all different, yet we coexists.
> Good programmers like challenges. Good programmers
> hate stupid.
Is anyone who labels themselves a programmer going to disagree with this, especially when they can insert their own values for "challenge" and "stupid"?The only interesting detail in the article, sadly, isn't investigated:
> I've [provided effective management] on occasion (but always
> as a leader who also codes), and I know it can be done.
The article would be much more helpful if it discussed the specifics of providing effective management, or even better, how an coder came to mangage a team in a world full of non-coding managers.My first point about "flow" is, I think, connected to this idea. Stupid wastes time. It breaks flow and replaces meaningful, objective feedback with noise. I also agree strongly that our happiness is correlated strongly with spending as much of our time on programming (I.e. real work) and as little time on stupid shit as possible.