On being critical, and the risk of burning out.

I enjoyed Josh Braegger's short essay: 5 Ways To Burn Out Programming.

I was particularly interested in this part:

It's really easy to fall into the "being critical" trap. It's easy to tell other people what the "wrong" choice is. I imagine it's because as software engineers, our job is to find faults in our applications and fix them. And if we don't find them, someone else finds them for us.

But I don't think we need to be negative about our job, decisions that are being made (even if it's not our decision) and what we're working on. Some of the best projects I've worked on worked out that way because we had a great, positive team. We enjoyed showing up every day to work, told each other when we did awesome things, held back heavy-handed criticism and phrased it in a productive manner.

I think this is a fine line, but absolutely one worth dwelling on.

One the one hand, the value of a workplace full of positive energy, respect, cooperation, and dignity is incalculable. I think it's well-put by the Perforce commandments:

P4 Commandments -- Values we work by

* We have high standards.
* We are straightforward.
* We rise to responsibility.
* We like work we can be proud of.
* We like to hear what we've done.
* We value both people skills and job skills.
* We treat each other with dignity and respect.
* We are one team. We are not in competition with each other.
* We talk and listen. We like feedback.
* We appreciate creative and practical solutions. There might be
  a better way.
* We appreciate people for who they are.
* Fun is always an option. It is not mandatory.
* These are the best years of our lives.

Yet, software engineering definitely attracts obsessive, detail-oriented perfectionists. If you aren't passionate about every little crook and cranny of your project, things fall apart quick. Software is hard enough to build in the best of cases; if you don't obsess over it, if you don't demand the utmost from it, if you don't poke at it and tear it apart and rip into it, the result isn't worth squat.

But there's definitely a difference between being critical of the software, and being critical of the people. Two of the most challenging things you will face as a software engineer are:

1. Learning how to be critical of the work, without being critical of the worker.
2. Learning how to receive a criticism of your work, without taking it as a criticism of yourself.

I suspect that most people find that the second one is markedly harder than the first.

Some of the most exciting, enjoyable, and illuminating times in my software career have involved working with people who "don't suffer fools gladly." Ask a stupid question, and they'll let you know. Make a poor design choice, and they'll let you know. Phrase a line of code poorly, and they'll let you know.

But, time and again, these are the people I most value, and most seek out. My life is short; the amount remaining to learn is large; and, as my old friend Walt used to say, "if you aren't struggling, you aren't learning."

So, go ahead and be a perfectionist. Strive to write the best software you possibly can.

But don't think you're there yet. Did you just write some software? Well, there's a mistake in it. I guarantee it. Go back, and look at it again; write another test; show it to somebody else; run a checker over it. Be as critical as you possibly can about that code, just remember that the person who wrote it is a human being, and the code is the code.