The Single Most Important Rule for Retaining Software Developers

There are good problems and bad problems when developing software.

A good problem is designing an elegant caching mechanism for your configuration variables, or determining how to architect your service oriented architecture so it doesn’t look like the New York subway system.

A bad problem is figuring out how to re-architect your code to work with a partner whose API goes down twice a day, spending three hours trying to get your code into source control, or filling out ten minutes of paperwork for a five minute code change.

Paul Graham makes mention of this in Taste for Makers:

“Not every kind of hard is good. There is good pain and bad pain. You want the kind of pain you get from going running, not the kind you get from stepping on a nail. A difficult problem could be good for a designer, but a fickle client or unreliable materials would not be.”

And in Great Hackers:

“One of the worst kinds of projects is writing an interface to a piece of software that’s full of bugs…you don’t learn anything from [doing this]. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn’t teach you anything, because the bugs are random…Working on nasty little problems makes you stupid.”

Bad problems are not interesting, not fun, and they teach you nothing. They create frustration and, given enough of them, will eventually cause burnout.

I’ve seen a string of bad problems last for months, and cause developer after developer to leave a company in search of more interesting work. Bad problems wreak havoc on your ability to meet Rob’s Criteria for Keeping Your Developers Happy.

Look at any large financial institution, government agency, and [insert name of large organization that considers developers to be a cog in their wheel here]. I’ve worked at a few of these companies, and often hear developers who are out of work joking: “If things get bad enough I could always go work for Company X.” Ouch…tell me that doesn’t hurt your ability to find good people.

On the flip side, look at Google, Fog Creek Software, and SourceGear. I’ve never worked at these companies, but evidence is strong that good problems are at the forefront of their agendas. And by some shocking coincidence they get a bazillion resumes for every open position.

A steady stream of good problems is the foundation for keeping your developers happy. Minimizing bad problems and maximizing good problems should be every development manager’s #1 goal.

[Digg this post]

Start Small, Get Big
Growth Secrets for Self-Funded Startups. It'll Change Your Life.
What you get for signing up:
  • A 170-page ebook collecting my best startup articles from the past 5 years
  • Previously unpublished startup-related screencasts
  • Exclusive revenue-growing techniques I don't publish on this blog
"The ideas and information Rob provides should be required reading for anyone that wants to create a successful business on the web." ~ Jeff Lewis
Startups for the Rest of Us...
If you're trying to grow your startup you've come to the right place. I'm a serial web entrepreneur here to share what I've learned in my 11 years as a self-funded startup founder. Luckily several thousand people have decided to stick around and join the conversation.

For more on why you should read this blog, go here.

3 comments ↓

#1 Adnan Masood on 11.18.06 at 2:04 am

When Albert Einstein said “It’s not that I’m so smart, it’s just that I stay with problems longer”, he definitely meant good problems. There needs to be a certain degree of balance between mundane support chores and creativity, I say 15%-85% probably. The disturbance in this balance can create choas. Very well said Rob, “bad problems teach you nothing” therefore you spend all this time solving them in vain. Not Good!

#2 http:// on 11.20.06 at 6:57 pm

You make a great point, Anonymous! =) So right, Rob. Since beginning at my current post roughly a year ago, I’ve had to deal with more and more of the “bad” kinds of problems (retrofitting screwily designed systems, “enhancing” old systems with largely incompatible but cool-sounding features — let’s add some Ajax to the such-and-such Web app we built back in 2001! — and the like) and it’s systematically whittled away at my ability to keep positive about the place. Shame how those in power understand and largely agree with the concepts you and Mr. Graham address so rightly, but ignore them so regularly in practice.

#3 engtech on 11.20.06 at 7:03 pm

I’m really feeling this one. I just spent two weeks hacking a workaround because we’re stuck using a crappy vendor EDA tool instead of One That Works. It was one of those jobs where I kept on referring back to their documentation because I couldn’t believe I had to go through such a complicated process to do an elementary task. Did I learn anything from doing that? Nope.