Here is the secret: learn to walk away.

Developers who find themselves staying at the office later and later are in a downward spiral. The more they heroically work, the more work is piled on. The more work piled on, the more heroically they work. Late night heroics should be an exception and not the expectation.

Why does this occur? The answer is simple, you trained your manager to permanently expect heroics.

Being a hero is a classic mistake, and consistently working massive amounts of overtime will give your managers a false perception of your daily output. As a result, they will pile an inhuman amount of work on you. Here are the 2 biggest reasons:

1. Overloading is unintentional, but you never correct them
2. Intentional overloading so to appear a productive manager, but you never set personal boundaries

Are you noticing a pattern? It is your responsibility to set the expectations. Unless you are masochistic, don’t be a hero. Inform your manager of the true number of hours worked, and learn to set personal boundaries. You have a life too.

Coding Horror had an insanely great article on software imprinting and the baby duck syndrome. Go read it…I will wait…

The notion of software imprinting got me thinking if this was also true to software process. It is not uncommon to hear the old mantra “We have always done it this way” when it comes to departmental development practices.

I have seen instances of developers whose first jobs were to simply hack out code turn into horrible developers. On the other hand, I have seen developers have a crummy first job turn into TDD machines.

Are processes such as TDD, Continuous Integration, Agile, and SCRUM slow to be adopted due to software process imprinting?

Is it the case that some of us choose not to unlearn our first software process, or is it the inability to break the mold and adopt something better?