Dear new developer,
A few years ago, I suggested you over-index at your first month or two on the job. I stand by that advice. Extra effort up front will earn you a reputation as a good employee. I also think that first impressions matter; plan to make a good first impression with your team and manager.
On the other hand, it is important to set your boundaries and learn how to say no.
How can both statements be true? The answer is that you must thoughtfully consider what you want.
Reasonable boundaries
Corey Quinn wrote a great tweetstorm about what to do when you start a job. The whole thing is worth a read, but I wanted to call out one piece of advice in particular, “begin with reasonable boundaries”:
What’s reasonable? Ah, there’s the rub. You want to balance being a team player, helping your company succeed and not being abused. Because there are companies out there that will abuse you. For the past couple of years, the job market for developers, especially once you are no longer “junior”, has been stellar, but that won’t last forever. And there are firms out there whose whole business model is to hire developers, place them in soul-sucking positions or places they can’t be successful, wring them dry, and start anew with another set of developers. Avoid these places.
Other jobs will be less obvious about this, and may not even be intentional. It could be an organizational flaw or a historical artifact that the company’s success depends on violating norms around work life balance for their employees. In any case, considering and setting your own boundaries will ensure that you are “working to live”, not “living to work”.
Think about time and effort you want to invest, both on the job and in side projects. I can’t offer you specific guidance other than to write down what you are thinking and revisit it periodically (every quarter or so). Map what your current job expects with what you are willing to give, too. If the expectations diverge, that’s a signal it is time to move on.
After you have determined your boundaries, set them. As Corey suggests, one way is to set an alarm and leave work at a regular time. There are many other ways:
- Don’t check work emails outside of work hours.
- Ask for more money if you are expected to wear a pager (if it wasn’t part of the job description).
- Avoid tasks beyond your job description (unless you want to take them on).
- Don’t install slack on your personal phone.
- Turn off your notifications.
Don’t be flagrant about your boundaries, but be firm. “I’m sorry, I can’t do that” is a phrase you’ll want to use regularly. Some flexibility will help: find out what team norms are and work within them as best you can. For instance, if your whole team starts work at 10am, then align your hours: stop work at 6pm, not at 5pm. You’ll have an easier time maintaining boundaries if the team doesn’t view them as counter productive.
When in doubt, have a conversation with your manager at your one to one. It may be an awkward conversation, so a good way to start is to ask the manager about how they manage their boundaries.
Crossing boundaries
As a software developer, there will be times when you’ll break your boundaries. At the end of almost every project I have worked on as a developer, there was “crunch time”, where I worked more hours than usual. Not 80 hour weeks, but more than 40. This is in part because estimation is hard. There are surprises at the end of every effort. Examples include:
- New requirements that weren’t clear at the beginning
- Tasks that the team should have done earlier but forgot about
- External changes that require software to change as well
- An accumulation of schedule slips from earlier in the project that pile up at the end
In some cases you can push back on these surprises by shifting dates or cutting functionality; in other cases you just need to grit your teeth and deal with it.
Break your boundaries rarely and intentionally. If it becomes a regular occurrence, consider other employment.
Sincerely,
Dan
Letters To A New Developer 
One thought on “Set your boundaries”