Avoid toxic environments

Dear new developer,

Avoid toxic workplaces. I wish I didn’t have to write this, but there are enough stories out there (here’s a few on HackerNews) that I feel I should.

How do you know? If you have to ask if an environment is toxic, it probably is.

There are levels of toxicity, of course. Fundamentally it is about a lack of trust between you and the organization, but can take many forms. Some blatant indicators:

  • yelling
  • belittling
  • disrespect
  • verbal abuse
  • throwing things
  • empty promises

Avoid these kind of environments. If you come across one while interviewing, give it a pass.

If you accidentally find yourself in one (after all, you could have misread signals in an interview or the situation at a once-happy company could degrade) leave ASAP.

You may not recognize you are in a toxic workplace, but your body might. Listen to yourself. Notice how you feel about going into work. Having a bad day here and there is not unusual, but regularly dreading work is an indicator; dig deeper and try to understand why.

Or try other ways to gain insight. Track your mood on a scale from one to ten for a month or two. Keep a journal if that’s your bent. Ask your friends for feedback on how you like the position and how your mood is.

Avoid toxic workplaces. You may learn some skills but it will come at an emotional cost.

Sincerely,

Dan

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

Plant a tree

Dear new developer,

Here’s a great quote:

The best time to plant a tree is 20 years ago. The second best time is now.

Unknown

I spent a little bit of time trying to track down the original source, but my google skills failed me. But no matter the source of the quote, it is worthwhile advice.

What does this mean to you? It means that you should start a long play now. That is, an activity which will pay dividends in the future, but does not right now.

What is an example of a long play?

I think one successful long play for me is my blog. I have been blogging since 2003 and it has helped me in a number of ways. Both directly, in being a “proof of work” for employers, and indirectly, by helping raise my profile in the community. But the benefits didn’t accrue in the first 6 months or the first year. It was the continual effort of writing, at least once a month, which delivered the value.

Another example of the long play is this blog itself. I wrote for months before I had any appreciable traffic.

Other possible long plays:

I didn’t realize how many of these long plays I’d written about (or folks had guest posted about) on this blog until I put the above list together. The long play has obviously been a long running theme.

The common thread is that all of these activities accrete value over time. Slowly at first. Oh so slowly!

Here’s the thing, though. The long play can be scary to commit to. It doesn’t have immediate financial returns, just like planting a tree today won’t give you shade tomorrow. You only see the benefits years or decades from now. That makes it tough to invest time, at least for me.

How do you know what kind of long play makes sense for you? The only way I know to learn this is to try different things. Sure, you can read about them and try the activity in your mind. But there’s a world of difference between, say, thinking about contributing to an open source project and actually doing so. When you try a long play activity, you can see whether you enjoy it enough to keep doing it.

A few other fun facts about long plays:

  • Committing to a long play doesn’t mean you can’t stop. You can stop if you want. Knowing this makes it easier to start.
  • Starting small is wise. Don’t expect to, say, submit a PR to rails or another high profile open source project as your first contribution. Finding a typo or expanding the documentation is much more realistic.
  • Different long plays require different levels of effort.
  • Long plays can pay dividends in the short term, but that’s a side benefit, not the main one.
  • You probably don’t have energy to have a day job, enjoy a personal life, and do a bunch of long plays. I’d start with one or maybe two.
  • Pick something you enjoy. An analogy: when starting a two sided marketplace like AirBnB, you run into a chicken and egg problem. No supply means no demand, and vice versa. So you need to kickstart one side, and one way is to have your marketplace provide value for one type of party. This is called “single player mode”. In the same way, a long play is going to be hard, so pick something that gives you personal value and enjoyment. Even if no one else benefits, you still do.
  • The level of effort you put into a long play will change over time. I wrote a blog post every day for 100 days once. I now write one blog post on my professional blog every month because I less available effort and time.
  • You don’t have to know exactly how a long play will turn out. You won’t, in fact. It can change over time as you get a clearer vision of your goals.

However, there are two things you must do for a long play.

You must commit. No activity is fun all the time. Sure, it was a rush to publish a book based on this blog, but there was a ton of dreary activities leading up to that event. I’ll tell you what, I even started and stopped the proposal a few times and needed a kick from my SO to submit it.

You must start. Just start. Pick something from the above list (or another kind of activity which resonates with you) and block out time to do it.

Plant that tree today. I guarantee you won’t regret it.

Sincerely,

Dan