Be nice to programmers

The question is not "What's wrong with this?" The proper question is "How can I make this better?" He's adopted a negative mindset by choice, whether he realizes it or not. That's not even what really grinds my gears about this post.

The really bad part of this post is the implication that this mentality (whether one takes the author's negative point of view, or my slightly more positive interpretation) is endemic to software development. It's not. Asking the question, "How can I make this better," ought to be a fundamental part of one's daily routine. Had the author adopted this mentality in general, he might have noticed a flaw in his workflow:

1. Write some code

2. Run the code

3. Get an error message

4. Find the error and back to step 1

There are some critical steps missing. A more appropriate approach would be:

0. Think about what I'm building

1. Write some code

2. Run (Test) the code

3. Get an error (of some sort)

3.5 Think about what might have gone wrong and verify it

4. Go to step zero.

That's right, when you find an error there are two distinct thought processes involved. First you think about what might have gone wrong. This would be the forming a hypothesis step of the scientific method (I've lumped testing into step 3.5 so as not to stray too far from the author's initial workflow, but suffice it to say that testing should be a recursive call to this entire process). Once you've discovered the source of the error, it's time to consider how best to fix it. Yes, more thinking. Only then should one go back to writing production code.

Sadly, I don't think the author's method is that rare. I had a professor who referred to the write/run/test/fix method as the original genetic programming. I think that's a fair statement. The problem with this method is that one ends up with a system that may work, but with no deep understanding of why it works. Absent that understanding, it will be more difficult to improve (fix) the system.

God help the next poor soul (aka the author in six months) to work on the system. Therein lies the negative feedback loop.

Yea I got over that. Shit happens. Don't sweat the small stuff, yada yada yada. Besides when you fix it everyone lights up. It's the closest thing I've seen to a performer doing some amazing stunt with me being the amazing person. Focus on that, and not so much on that it broke. The difference between developers and non-devs is we can fix it, and that's really cool power. This article is almost like Wolverine complaining about his super powers being lame and always having to save the day. YOU'RE WOLVERINE STFU!

I think after being a programmer I have changed my outlook for the better because I realize what's possible instead of being trapped by other people's ideas/mistakes. I see how things are connected and if I changed this or that how it changes our limitations. Anyone can say "What if" very few can "Here's how." And that is really empowering and liberating.

I suppose when I was younger I was negative I wanted everything to be perfect like it couldn't be, but as I matured I see bugs, missing features, bad design as just opportunities and not the end of the world. Being late, bugs, complaining users, whatever it just doesn't bother me.

I'm not tuning them out just choosing to listen to what's really important and cutting through the bull because I expect all of it to happen. We're late ok I'll work a little more realizing I can really only make it about 10% faster, there bugs give me a reproducible test case and I'll fix it, users bitching reach out to them personally and find out what's the real problem.

And just like anything else in life, whether it's programming, football, music, or ditch digging, your attitude is your choice. The difference came when I chose to be positive...and laugh a lot more at all of the irony, bad choices we make, and gotchas that always creep up. Laughing really helps.

I was addressing what the parent comment (from peeters) insightfully observed about the original article's four-step workflow description: getting to the next bug and fixing it could either be thought of negatively ("damn, I have another bug in my code") or positively ("I've solved this problem and made some forward progress"). Whether you find this negative or positive is a function of your mental state.

This is analogous to the mason's iterative workflow: noticing that his stone doesn't yet fit quite right and chipping a bit more off the side until it fits perfectly.

During development, most of our daily feedback comes from the code itself, not from people yelling at us about how broken it is (although that does happen sometimes).

Among all the non-programmers I've talked to about work, I've never found one who doesn't have to deal with some sort of constant, repetitive negative feedback. Teachers have to deal with some kids that simply won't stop acting out, and who continually perform poorly on assignments (not to mention parents happy to tell them everything that the teacher is doing wrong). The salespeople have countless deals they fail to close. The manager has to make painful decisions about other peoples' livelihoods, and absorb the criticisms coming down from higher up the chain. The artist has to deal with everyone being a critic, and doesn't have the luxury of dealing with things that either work or don't work, it's all subjective. The doctor can't cure everyone. The lawyer can't get justice for everybody. The data-entry clerk peon has to ignore that they're completely replaceable and that they'll probably be replaced by a computer sooner or later. Anyone building anything (not just software) has to deal with the reality that 95% of the time, it's not done yet, and you still have more work to do and things to fix.

That's not to say that some people aren't going to be happier in certain fields than others, or that some subsets of the field fit some mindsets better than others, but software is pretty good work. The article acknowledges this right up front, and then ignores that to dwell on the negatives. It blew my mind a little to see such a negative perspective. If I fix a simple bug in my code, it doesn't bother me much, because I know I sometimes make mistakes. If I find and fix a really interesting subtle thing, then it means I learned something new, and that the product is now in better shape than it was yesterday. If there's a usability issue, it's an opportunity to figure out a new way to do it. And all the while I have the constant positive feedback of knowing that this thing that I built is doing something, I can directly watch it do that thing, and that it's being used by people to get stuff done.

Unless you build everything exactly right the first time, and never have to deal with external changes that mean the software needs to change, you're never going to be free of negative feedback. So you should start looking at why you're letting the negative parts drive your attitude.

EDIT: My own personal idiosyncrasy is that I get very suspicious, maybe even paranoid, about a complex task if everything seems to work right the first time and I don't have a few cycles of negative feedback. I know it's complex, and so I don't expect perfection out of the gate, so a few runs through the "fix one thing, find another issue" washer are oddly reassuring to me. Even though rationally I know that fixing things I knew to test for doesn't mean it's any less likely that there are errors in the things I haven't thought to test.

Unfortunately, many developers don't get a lot of opportunities to see their product in action. If you work on some public-facing service like Google or Facebook, you'll get to see your code being used. But if you work on a product that big companies deploy on their internal networks to improve their productivity, you won't see much of it.