< Blog

Five Years

Today marks the five year anniversary of my current job. It's an interesting milestone to hit because on the one hand, my dad still works at the same company he's worked for since significantly before I was born, and on the other hand, five years feels like such a long time.

Time to do a bit of reflecting, shall we?

How many teams have I been on?

Two. I only changed teams - that is, left one team that existed to join a different team that also existed - once.

But maybe three, since during my time on the team I'm on now, the team split into two, and my current team has a different name than it had when I joined it.

Maybe four, because the first team I was on had 100% turnover apart from myself since I joined it, including of responsibilities, so was it really the same team when I started and when I left?

Or six, because I've also been on two sub-teams, one for community involvement and one for our company's internal conference (I ran that one year, which was pretty cool!)

Or eight, because I was on the internal conference team for three years, and each year was, in a sense, a different team.

In conclusion, I've been on more than one team, and fewer than a hundred.

Some less ambiguous numerical facts about the job

Some life milestones that have happened during these five years

(Not in chronological order)

Some work-related observations

I value automated end-to-end tests a lot and get frustrated when we introduce recurring bugs that could have been prevented by automated end-to-end tests.

I also value fast and useful in-memory tests, which play a different role than end-to-end tests, even though there is some overlap.

People spend a lot of time arguing over whether to classify tests as "acceptance" or "unit" or "functional", even though they all run the same way and do basically the same thing.

Misapplication of the testing pyramid is probably responsible for more bugs than anything else. This is unsurprising because the idea of the testing pyramid is very broadly applicable and easily misunderstood.

A lot of people think they are doing test-driven development when they're not.

There isn't a broad consensus over whether the second "D" in "TDD" stands for "development" or "design". You'd think it wouldn't matter, but when the priorities of software design clash with those of feature development, what people think they're optimizing for starts to matter a whole lot.

Working for a very large company has a lot of drawbacks and a lot of benefits. It's sometimes easy to take the benefits for granted and fail to recognize them.

One drawback of working for a very large company is that the people who are motivated to resolve a problem often have almost no power to do so. I don't know how this can ever be fixed.

At a large company, it's really easy to make a change that you think is benign, but actually zonks the entire day for a whole bunch of people, many of whom you may not know. I've been on both sides of this, pretty frequently. There are things that could be done to make this less likely, but we've chosen not to.

One benefit of working for a very large company is that it can provide the flexibility to let you work on problems that you find more interesting, and with people that you gel with better, than where you started. How much a company chooses to embrace this type of thing can vary.

Another benefit is that it's a lot easier to have teams dedicated to making certain parts of the engineering process go smoothly. This is a double-edged sword though, because it means that you don't learn how those parts of the process work.

Another benefit is that if something goes wrong, there's usually someone who knows how to help. On the flip side, when there isn't and you're still stuck to go it alone, then there's a whole lot of people who are really impressed with you when you figure it out.

Running an internal conference seems like a daunting task, but with a good team, it's quite manageable.

Running an internal conference at a large company is very rewarding.

It's hard to give negative (or constructive) feedback because making people feel bad is painful.

It's hard to give positive feedback because it's not always that easy to notice that it needs to be given.

Wearing many hats is a good opportunity for expanding the types of things you know how to do. But it's very hard to do well, and there's a reason why "Jack of all trades, master of none" isn't always considered a good thing.

It can be disheartening to work on a project only to have the project get scrapped, but that type of thing is rarely held against you. It does make it harder to point to material accomplishments though.

Not all disagreements need to be discussed immediately, or even at all.

Tech debt is very costly, and its cost goes up really fast the longer it's there, but when engineers don't get to set their own priorities, it's very hard to advocate for cleaning it up. There should probably be a job position dedicated solely to tech debt cleanup advocacy.

I've found certain types of work to be much more engaging than others. Other people have also found this, although the work that they find the most engaging is not always the same work that I find the most engaging. It feels silly when I'm working on something that someone else would find more engaging while they're working on something that would have hooked me.

Friction in a process is neither inherently good nor inherently bad. Sometimes it means that you're learning, which is usually hard. Sometimes it means that an unnecessary barrier is in your way. "If it's hard, do it more" and "If it's hard, do it less" as blanket statements are both wrong.

Nobody writes good internal documentation, not even people who advocate for doing it well (like me!)

...not even people whose workflows are completely dependent on having good internal documentation.

The microservice versus monolith debate often feels both unresolveable and perpetually relevant. I think there is a worst-of-both-worlds, where you have some code in a monolith that gets stepped on all the time and some other code in a microservice whose deployment has to be carefully coordinated with that of the monolith. Thankfully, I'm not in that world, but I know people who are.

If a meeting doesn't have an agenda, then it's not a meeting; it's a chitchat. That's fine, but it can be kind of annoying to think you're going to a meeting and wind up in a chitchat instead.

Pair programming is a valuable tool, but much like a hammer, if you hit a developer over the head with it too many times, you probably won't like the results. (This is, in both cases, somewhat developer-dependent)

The willingness to stop doing something you started recently is really important. There's the obvious benefit that you don't wind up with rituals that don't help, but the less obvious win is that it also makes it a lot easier to try new things. A lot of people will agree to try something new when it's easier to roll back.

I have always found public speaking to be very scary, but also rewarding. Giving prepared talks has never really gotten less scary, although I've gotten more comfortable ad-libbing on a mic, for instance, while MC'ing a conference.

I've never thought my talks were good, but people have generally liked them.

I wonder what the next five years will hold. Or the five after that.

Five years! Sheesh!