This was originally published on the now-defunct Barricade company blog. Republished here as I think it continues to be relevant.

Defending your time is a critical developer skill, and one that doesn’t really get talked about enough.

Every developer has war stories about the job (or often, multiple jobs) where their boss kept pushing them harder, making them forsake family, friends, and hobbies, until eventually they burned out and quit. It’s actually so common that it’s almost a rite of passage in our profession — the hardy developer who stood up, threw off her chains and shouted, “No more!”

I don’t like this story for a couple of reasons. Most obviously, it’s a painful one for the developer to experience, but it’s also a professional failure. Part of our jobs as software developers is to manage expectations, and stories like this are, generally, times when we have failed to do that.

Defending your own time, therefore, tackles two major problems in software companies: bad planning, and burnout.

Bad or no planning

When you’re willing to yield frequently to demands of your time, planning takes a back seat. This can be useful sometimes, especially in an early stage company, but it’s a sort of debt that can become a chronic organizational issue if not kept in check.

When time is constrained, however, decisions must become less reactive. This presents the opportunity to make a team much leaner, by shortening development cycles so deliverables are more tangible. A neat side effect of this is improved morale as progress becomes more visible.

Burnout

Defending against burnout protects both your mental health (Ash Huang recently posted an excellent article about burn out and its personal consequences), and the company’s health.

Replacing a burned out developer is not like replacing a faulty server. Today, it can takes months to find, let alone acclimate a new developer. That’s the sort of time lag that can literally kill smaller companies.

A responsible developer will, quite reasonably, not want this to happen.

Setting boundaries

Setting boundaries is the first step to defending your time. These should be soft boundaries, not inviolable covenants. They’re the sort of nebulous edge of your comfort zone — things that are fine once and a while, but might be a problem if they became the status quo.

This is a lot easier to do early on; you want to make small calibrations to working relationships rather than large step changes (like ntp!). When it gets to the point that you’re angry or resentful, it can be difficult to reverse course.

Defending boundaries

Like trademarks, your time boundaries should be defended to ensure they are respected. It’s a little unfair to assume others should infer them from subtle personal cues.

There’s an art to this defence, which is why you want your boundaries to be soft — it allows for diplomacy. When you’re burning the midnight oil too frequently, it’s worth pointing out that this means there probably needs to be more flexibility built into the development process rather than, for example, fuming silently.

Getting over the fear of feedback is a hurdle that, once overcome, will allow your career to flourish. Given the current job market, the most dire consequence of this going badly is you not getting a paycheck for a couple of weeks, finding a better job, and getting at least a modest pay rise. There are worse ways to fail.

ESTIMATES ARE NOT DEADLINES

I don’t wish to retread too much ground; the crux of it is that estimates are only useful when constantly refined. Too often, developers are the ones who tie themselves to these estimates. Sometimes it’s pride, sometimes it’s a poor organization grasp on what estimates actually mean. If this sounds familiar, start by agreeing to update estimates once daily with the people who are interested in the outcome (aka, “stakeholders”).

Resist the temptation to promise the world, and disappear into a cave for two weeks.

TAKE YOUR HOLIDAYS

A recurring anti-pattern across software companies of implicitly rewarding employees who don’t take holidays. This is a long running theme in American companies, but it has also crept into European startups eager to emulate the success of their counterparts across the Atlantic. Mathias from Travis CI touched on this at the end of last year, and the huge response demonstrated the reach of this issue.

Taking your holidays allows you to recharge, and helps your company become more fault tolerant. A developer can be a specialist, but should never be a data silo. Their loss should never stop the company from working. Ensuring holidays are taken means the company can be prepared in the event of sickness or attrition, and usually makes it easier to onboard new people (because things are documented or processes are created).

When you defend your time, you make your life better and you make your company better.