Set your boundaries

Chain link fence

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

The Art To And Power Of Saying No

Dear new developer,

There’s an art to saying no. And there’s power in doing so.

I worked on a project that was creating a Yahoo clone early in my career. The lead developer got sick. I said “yes, I can help.” I jumped in and helped out, a lot. I ended up working 96 hours in a single week. The site launched. I was thanked by my company with … a t-shirt and six-pack of beer.

I have learned since then how to say no.

The art is in saying no without being a jerk, and to making sure that everyone realizes that they are all on the same team. My best advice for that is to flip things around and say “yes, but.” “Yes, I’m happy to shift to working on task B, but should I finish task A first.” “Yes, I can help you with the release, but Jane is waiting on this feature.” This makes it clear that you are happy to help, but have other obligations as well.

After you describe the two options, ask for prioritization. Especially as a new developer, you simply don’t have the bigger picture. Maybe task B is blocking three other developers from making forward progress. Maybe that release is really important because of a bug fix that needs to go out before the launch of a new product. I have never once been dinged when I asked for prioritization. It shows that you care about working on important things, are aware that there is a bigger picture, and are flexible.

However, be aware that as soon as you juxtapose two tasks that both need to get done, you will be asked to estimate those tasks. Practice that, as it is a skill you’ll need as a software developer.

The power of saying no is in protecting your time. You only have one life to live (#yolo). When you have a salaried job, there’s very little downside to your company in trying to take more hours. Even if they are really nice people, you are the person responsible for establishing and protecting your boundaries. If you say yes all the time, you may end up working a lot of hours.

The other issue is that it feels good to work, especially as a new developer. “Look, I’m getting stuff done.” “I’m building cool stuff.” But the point of life is to live, not just to work. As I look back over my career, I’m proud of what I’ve built, but a lot of what I’ve built is gone. Don’t let a company suck you in and not learn to live a life.

Learn to say no.

Sincerely,

Dan