One thing that separates successful career programmers from those with a bit…less success (we won’t call it failure, because it usually doesn’t manifest as abject failure, but rather as stunted potential) is their ability to figure out their value to the people who are retaining their services. Regardless of what that job posting says, what the recruiters tell you (more on this in a minute), or what you’d like to hear, you are NOT ever hired into a position simply to write code. You are hired to solve a problem that someone has, with the expectation that your solving of said problem presents an advantage greater than that provided by simply keeping (or using elsewhere) the money required to hire you. It’s a simple thing that is missed fairly frequently when discussions of programmer salaries come up, as well as when programmers sit and complain about the messes they deal with at their jobs. It also happens in just about every other industry. I’ve had similar discussions with people in other industries. The fitness industry, for instance, is loaded with people who live under the belief that the fitness program they are selling is actually the reason they have clients, instead of what the clients are actually there for, such as losing weight, gaining muscle, just the feeling of accomplishment and pushing past obstacles, etc. The dividing line between the successful ones in that industry and those who are unsuccessful is also remarkably similar, in that the latter fail to line up their offerings with what their customers are actually buying, versus what they think they are selling.

I’ve had a few projects over the years that have required insane amounts of work in a very short time period and usually have tremendous and horrible consequences for at least one person on a team (or the company as a whole). Besides the occasional server crash or “if we get this thing out, we land a huge customer” type of work, I’ve noticed some significant commonalities about deathmarch projects that I believe could be used to help an individual detect whether they are about to sign onto one. It’s hard to tell when you are interviewing, but after mulling it over, every single time it has happened to me, the signs have been there all along. So, without further ado, allow me to introduce some warning signs that I’ve noticed that frequently come during interviews or the first week of working a death march project.

All healthy companies are much alike; all dysfunctional ones are dysfunctional in their own way. For instance, every healthy company I’ve worked at has fairly consistently spent time and effort to make sure their employees are appreciated and productive. They’ve spent time involving the employees in the process, giving them workable goals to progress towards, and generally making sure that their people are taken care of so that they can take care of the company. And while such stability is laudable and makes the places fun to work, if you really want the good war stories, you have to work at a dysfunctional place.

Judging by the actions of a few companies I’ve encountered over the ten and a half years of my full-time, professional programming career, many companies would like to quickly lose their most talented people, preferably to their competitors and preferably for easily and cheaply avoidable reasons. Towards this end, I’d like to offer a list of suggestions of ways to make absolutely certain that your development staff is interested in greener pastures, no matter how much barbed wire they have to climb to get to them. Here are my suggestions for how to achieve near perfect turnover (except for sadists) within a three to four year period.