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.

It’s pretty common for developers to disagree on the role of comments in source code, sometimes in a rather vehement manner. I think at least part of the problem comes from a fundamental misunderstanding, in that most developers simply don’t explain well what they mean when they talk of well-commented code. I believe there are multiple types of code comments, of varying value in different stages of a project and I also suggest that when disagreements come to pass over comments, it’s largely because developers are using the same word to describe very different things. Here are the types of code comments I commonly see and what purposes they serve well.

I don’t normally post on Fridays, but I’m doing so today in honor of a very special birthday. Today, my paternal grandfather would have turned 100 years old had cancer not taken him from us 21 years ago, and as I’ve reflected on things he taught me so many years ago, I realized that perhaps the best way to memorialize that would be to share some things. I’m writing a bit freeform, so I hope this doesn’t turn into a eulogy (I can’t do the man justice).

I use Evernote as my software package of choice for managing to do lists, as well as for archiving the little bits of data I need here and there. Following (somewhat loosely) David Allen’s Getting Things Done methodology, I’ve created the following notebooks in my evernote account.

It’s been an interesting couple of months. While I’ve been getting the business going, I’ve also been trying to get my house ready to sell, trying to sell the house, and picking up contract work. What’s been amazing to me during the process is how utterly unreliable some companies and individuals are that I’ve worked with. For instance, I’ve dealt with plumbers who said that the work they were doing replacing galvanized pipe under the house would be done within a single day and ended up losing some shrubs I just planted because the water was off for three days during a heat wave. The same plumbers also managed to knock some duct work and a dryer vent loose, ultimately causing moisture problems under the house, which made a buyer back out at the last minute.
Reliability is not free, nor is it cheap, but lack of reliability is even more expensive. In terms of business, the problems they created cost me several thousand dollars, both in repairs and in opportunity cost (because there were quite a few hours I was not able to work out of the house when I expected to be able to, because we had to go through the process of showing it again).