Be Desired, Not Required

"Make something people need and you’ll make a living.  Make something people want, you’ll make a fortune."

There are lots of developers out there with "job security".  You know the type: they’re the ones that know all the system trivia.  They’re the keepers of the system’s oral history and when something extraordinary needs to be done with the system, they’re who gets tapped.  These developers usually find themselves in this position due to lack of documentation, bad design, planning failures, or some combination of these and a dozen other things.  In some situations, they become a "required" component to keep the system running.  This may seem like great position at first, but try taking a vacation or getting promoted when you are a required component: at best it’s not fun, at worst it’s impossible.  Heck, even getting sick is more miserable if you have to keep things running while trying to recuperate.

While it may seem more risky, you’ll be better off if you’re desired, rather than required.  Pretend that every development iteration is your last.  At the same time, pretend that you are your own replacement and it’s your first day.  What information would you want?  Would you know how to find it?  Does the body of documentation relay not only what the system does, but what you were thinking when you designed/built it?  Does it build easily?  Does it have good test coverage?  How about a decent installer?

Having all of these things in place makes it a lot easier to transition to new/better opportunities.  But that’s just the medium-term benefit.  The short term benefit is that by keeping things in order, it will force you to work better and be both a better developer and a better employee.  In the long term, your reputation will be well served by being known as the Big Swinging Developer who "does things right" and "leaves things in order".

Comments are closed here.