The Benefits of Sticking Around

Dear new developer,

Over the last twenty years, I’ve had two work modes. I’ve either been at a company for a number of years (3, 8, 2, and 3) or been a contractor/consultant working for clients for weeks or months. Both modes have upsides; I wrote before about the benefits of a small consulting company.

I want to sing the praises of being at a place for years. Settling in. Camping out. Hunkering down.

Benefits

The first benefit is credibility. When you are around for a while, you pick up knowledge that can’t be documented well. I’m talking about understanding old processes, who worked on something, remembering when a bizarre problem popped up in the past, or an intuitive sense of a code base.

While this knowledge can be captured to some extent, by process documentation, version control, ticket history and architecture documents, respectively, such documentation is a poor replica of living through the events or writing the code.

Even if you don’t know exactly where to find such knowledge, in the back of your mind you know it exists. That puts you in a good place to search and re-discover it. I’ve spelunked for answers and discussions in Slack many a time. Other newer team members didn’t even know a topic had been discussed.

Having this history brings credibility to your opinions, because you can inform said opinions by what you know. This type of credibility is, by definition, unavailable to someone new.

The second benefit is being forced to live with your past decisions. We’re all, of course, living with past decisions made by others. Who hasn’t arrived at a new place and seen all the crap work that people before you left?

I’ll tell you, it’s a special feeling when you see a poor tool, code segment, or architectural choice that you chose or had input on. Not a good one, either.

Living this gives you empathy for all the other decision makers. This occurs even in consulting shops when you have long-lived projects.

One special case is the ache of the postponed bug fix. I endured this myself. I was at a company for years and there was one bug that showed up when a user was changing preferences in a certain way. It was rare, but unpleasant. I spent time characterizing the bug and coming up with a possible fix. Because it wasn’t a quick one, I discussed it with other team members. We determined that it wasn’t worth the effort to fix based on how users encountered it.

Every time that bug popped up, I knew it wasn’t going to get fixed. We’d have to work around it and accept the degraded experience for our users. It was painful.

Know there are bugs that are not going to be fixed because the business value is not there. While you can encounter difficult bugs everywhere, experiencing such continually postponed bug fixes is only possible when you’ve been at a place for years.

The third benefit is, in some ways, the inverse of the second: the joy of seeing past efforts pay off. At the company with the preferences bug, we invested in large scale refactors and architectural changes too. In one case, we swapped out part of the data access layer from a lesser used choice to a better known option. In another case, we layered on HTTP caching which greatly helped the application performance.

When you stick around, you get a chance to succeed in these large efforts because:

• You have the time to put into them
• You have a deep understanding of the code and system
• You have credibility to propose such changes
• You know who to mobilize to get stuff done
• You understand where both the high leverage and scary parts of the system are

This isn’t only code components, either. Seeing a document or process you wrote help others years later is joyous as well.

These are lessons you can’t pick up when you move on regularly.

Downsides

There are downsides, of course:

• Your salary won’t grow as quickly as it would if you were to move from place to place. Especially when you are newer in your career, you can easily get 25-50% salary increases by switching jobs.
• Depending on team size, you may suffer from the curse of the expert beginner.
• Lack of exposure to different technologies or approaches, though you can mitigate that via online communities and personal experimentation.

I’m not going to dig too deeply into these because everyone’s situation is different. Think about these downsides and you may decide they outweigh the benefits.

How to find a place to settle in

Focus on the people and the problem you are working on. Do you trust the people to do right by you? Is the problem interesting?

You want to be learning things all the time, either from people around you or because the problem demands it. Preferably both. Take jobs that help you grow.

Also, understand the business. The best learning opportunity in the world isn’t great for hunkering down if it goes out of business quickly. You learn from a failed company, but as a new developer, I’d suggest working for a profitable business, or at least one with a solid path to profit. That’s going to be a good place to settle in.

Your gut might lead you to a large company (I know folks who have been at Microsoft for decades). Or to a smaller, less flashy company.

I’d suggest settling in to a company for three or more years at least once in your career. You’ll gain experience you can’t acquire any other way.

Sincerely,

Dan