Programmers must program. If anything at all prevents a programmer from programming, he or she will grow unhappy. Incomplete designs, slow builds, too many salespeople, noisy construction out on the street, whatever. Programming good. Not programming bad.
I'm a glassblower as well as a programmer, and it's the same deal in this seemingly quite different line of trade. I recently was working in a group shop environment where many things were preventing me from getting work don - distractions, inadequate ventilation, inconsistent fuel supply - and I became quite unhappy.
That was my thought when reading the article. Replace programmer with accountant, marketer, designer, etc and the article would read the same. As much as programmers think we're special snowflakes, there's always another group (see previous list) that thinks they're special too and that no one else "gets" how they work.
A lot of startups that are trying to be cool have lots of distractions. In fact, distractions are what they spend their time trying to create. They want to have people around who are on the 8 + 4 plan. Weeks will go by as the programmers spend 8 hours working and 4 hours fucking around.
I think one of things that is a key de-motivator for devs is having to work with other engineers that don't really care about the quality of code they write, as they don't perceive software as an art-form or craftsmanship, but more as something that pays their bills. A lot of dev orgs don't spend enough resource/time evaluating dev work on a technical levels, leading to lots of bad code and frustrating the hell out of the good devs. The places who do instill passion and draw great devs, much like Apple at its height.
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.
required each of 30 programmers to write only their code and never see anyone's else's (because the managers thought they would steal the code) - priceless! Thank you for this.)
Over-confident idiots (especially at management positions) is the must common cause of failure.
I've always felt "laziness" in programmers is often "I don't want to do this tedious crappy task, I'm going to do fuck all until an elegant solution pops into my head at which point I'll at least partially automate it"
I know that feeling. So often, especially when things are busy or deadlines are tight, I feel bad for wasting time surfing the internet or slowly tinkering on some unimportant task no one cares about. The big job is getting no attention. "The programming" is just gone, I'm hanging around killing time.
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.
What's up with this attitude that any activity that isn't coding is stupid? Why is planning your coding work so uncomfortable to most programmers? I worked on a SDLC based project management tool http://www.dynamicalsoftware.com/analysis/code-roller and what I learned is that this attitude is prevalent in a lot of dev shops.
"corporate standards" are at least partially good. They should be reasonable though and adaptive to the times. Having a set of acceptable programming languages, frameworks, etc. ensures that the company understands the risks of those choices, can apply reasonable upgrade/maintenance/security patches as needed, can attract and retain personnel that understand the language, etc. Allowing arbitrary choice leads to complete anarchy. The opposite is also at least as bad. Having one rigid language/framework leads to obsolescence and inflexibility. A good programmer will be able to make a strong case as to why this new language/platform is vastly superior to the current one because changing to the new one and supporting the old one are not zero-cost propositions.
Why not just create an environment that suits the company and its management. The programmer can decide whether that environment is best suited for them.
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.
Can't agree more. In a lotta cases is up to the programmer to keep solving the desired problems (interesting programming), we tend to say yes to too many things and this sends us to the path of perdition!. You gotta fight to keep doing the cool stuff.
yup, this is actually want everybody wants. You can't have a boring, repetitive job. Challenge wakes everyone up unless you don't rise up to that challenge.
As the person being replied to, I'll respond. This is an excellent post. Major upvote. I agree with everything the OP is saying.
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.
It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs. Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.
