I wanted to talk about a few things relating to being a professional. Specifically, dealing with being a professional software developer. Whether you work for a small contractor, a start-up company, or a monstrous development firm. I want to focus on the idea of job security and the illusion many developers harbor about it.

I ended up discussing the topic with a coworker once. The discussion had ventured to the topic of what happens when a key developer leaves a project. In some teams or projects, the key developer takes with them the potential success of the project. That is, the developer had been employed under the “Superman Syndrome.” This is what happens when a single developer finds themselves in a position to create themselves job security through obscurity. Either they have mastered a complex codebase, memorized certain pieces of information and neglected to share it, or have an extremely high tolerance for bad code. When they leave the project, the remaining members are forced to pick up the pieces (at the peril of their paychecks) or scrap the project. Neither scenario is beneficial.

Under this situation, the developer has created what they believe is job security. The reality of the situation is this is a false sense of security. A lazy company or management may let this slide. It’s a slippery slope and it will only get worse with every day this developer is entrusted with resposibility. The up-tick is that this developer is not likely creating many new technologies, but rather maintaining the seemingly unmaintainable. If you are reading this and think you possess job security, you’re delusional. Your employer has no reason to be tolerant of such behavior; there is always a recent college graduate that can fill your shoes.

The worst kind of Superman is the kind that intentionally does their job in such a bizarre manner that others find it difficult to work with their products. By this I mean they write complex or poor code in the hopes that others will be incapable of maintaining it, thus ensuring the company will always need them. Some do this more indirectly than others by choosing a poor design or omitting the design process entirely. This is more poisonous to the company than anything else and I consider it a form of insider sabotage.

You never know when you or another key developer could be hit by a bus. If you are the key developer, don’t leave a mess for someone else to deal with. If you are not the key developer, it would behoove you to document as many things that can be learned as possible. This will create a knowledge trail that will help you and your co-workers deal with a gaping hole in the team.

I believe that what a single developer adds to a project should not be quantifiable. A high quality developer will add a skill-set to the group to fill a specific role. A developer’s success is measured by their intellectual output, so they must possess the ability to flex, learn, craft, lead, and take direction. For example, I hope that if I left the group or project I am currently assigned to that I will leave the group or project in a better state than I joined it. I also would like to think that the only thing I take with me would be my abilities and experience. I hope that the main thing that will be missed in my absence would be my ability to solve problems and create solutions to complex situations.

Moving on to something in a slightly different direction, I wanted to briefly talk about how to build yourself into key developer that positively impacts every development team you join. Jeff Atwood recently dug up a good article (by Steve Yegge) recently about how to do so. You have to treat software development like a craft. Crafts must be practiced, honed, and enjoyed. Going to work does not merely mean that you are advancing your abilities, so take a peek over at Jeff’s coverage of the article or the original article itself. While you’re at it, be sure to read Norvig’s article about how to develop yourself in the span of 10 years.

I personally believe that I have an ability to perform a craft that must be honed and perfected like any other artisan skill. Even professional football players have to go to practice to maintain and improve their abilities. I practice by playing a little golf, reporting bugs to prominent open source projects, and contributing patches. I eventually gain commitbit access to a full project, then I will likely have to tackle the more social and political aspects to being a developer. I am also a graduate student which requires the most critical and analytical thought process of any task I’ve undergone. If you are a developer, I urge you to practice your craft (or not, it’ll make me look better and get paid more).

So in closing, software engineering is a craft like no other. It’s possible for too many people to get comfortable in their job. It’s possible for some people to poison and ruin everything they touch. It’s also possible for someone to make a hugely positive impact to everything they work on and everyone they work with. As a professional, everyone has to decide what they want their role to be.

tags: code kata, job security, professional