june 7, 2025

after working full-time at the same programming job for 8 years, I’ve made the decision to leave – and I’m realizing that there are some things I’ll especially miss…

my coworkers

this one’s fairly obvious I think, due to the whole “social beings” quandary: I’m gonna miss the people I’ve worked with for the better part of a decade.

I have been the last one standing on my team like 3 times during my tenure – so even though I’ve been working on the same team for 7+ years, I’m lucky to have worked directly with lots of people who have since moved onto other teams or left the company.

and there are lots of things I’ll miss – office small talk rocks, technical peers and mentors rock, our semi-annual tradition of meeting at a cafe on the uws and walking through central park… rocks!

heck, I’ll even miss seeing their fingerprints all over the code. a few times I’ve even been able to clock who wrote a piece of code just because I know one person particularly likes to implement function interfaces and another likes extremely specific variable names… like recognizing J.D. Salinger’s style in a de-contextualized line from Catcher In The Rye.

I will miss all that.

the codebase

me when they shut off my access to the closed source repository:

is it cringe to miss the code?

the generation ship model of software development resonates with me – programming in an unfamiliar codebase is like an exercise in archaeology. and just like any archaeologist leaving their dig, I feel attached to what I’ve learned and the efforts I’ve put into learning it.

I have come across my fair share of incomprehensible code that I was either afraid to refactor, or refactored with a bug because I didn’t fully understand its purpose.

and now I will indulge myself by enumerating some guideposts for writing robust code in a codebase with many collaborators over a long period of time (thus relieving my dear reader of any duty they may feel to indulge me – I’ll see you at the conclusion):

• before changing code you don’t 100% understand, don’t just try to figure out what the code is doing – try to understand what it’s intending to do… read the tests and the documentation, and if no tests exist, write them; if only to form a theory. ultimately, reading just the code to infer intention assumes the code is correct, and forming a strong hypothesis on intention is critical to maintaining the code over time.
• design systems for what is needed, as simply as possible. designing a complex system to account for future needs sounds great and cool, but as we can’t predict the future (and usually struggle to even understand the present), this will probably come back to bite us.
• …instead, keep the code footprint small and covered with tests, so you or your collaborators can refactor without fear of spending the next cycle writing a postmortem. (allow me to share what has become my favorite online resource for the whats and whys of refactoring)
• always write the good tests, even (or especially) if you have to refactor the source code to do it. the definition of “good” has been the subject of debate for many a programmer – my humble offering is that a good test is one which fails if an assumption of the theory behind the code is broken.
• document the code (see 101 course on technical writing), and use inline code comments sparingly. that last part can be controversial, but mostly I mean: prefer to refactor the code to be more intuitive over explaining it with a potentially confusing comment. and if you do write a comment, try to include a link to a long-term fix or wiki page with more context.

this is all to say that communicating the intention behind the design is the hardest part of collaborating in a long-living codebase. as Peter Naur argues in programming as theory building, a program is much more than just “how it works” (i.e. the design or even the source code) – it is the shared mental construct that we build together (or the theories behind the design).

so I will miss being mind-melded to this codebase and helping my fellow loyal workers mind-meld to it in kind. but in a way, this throbbing and all-encompassing hive-mind (all hail) has become a part of me as well. you can take the bee out of the hive, but you can’t take the hive out of the bee, and my little guideposts will accompany me wherever I go, searching to be accepted by yet another swarm…

I’ll end with the same cheesy-but-poignant line from the aforementioned medium post:

Finally, it’s your turn to leave the ship. You hand the code off to your successor. You wish them well.

parting thoughts

so yeah, I’ll miss my coworkers (normal) and the codebase (less normal). if I had to write another section, maybe it would be “the process”, which tie the two together (retroes <3)… but no one’s putting a gun to my head.

but maybe I’ll just say that programming is for “social beings” (full circle). we are much better at building and maintaining the mental construct of what all is happening – or should be happening – together.

but there’s also a secret sauce: everyone has to try, and feel comfortable saying “I don’t know” or “why?”. that can be hard enough with human egos – let alone layoffs/re-orgs, a hypercritical culture, or the spreading belief that we can just “vibe code” our problems away (don’t get me started). to me, if the pursuit of truth is the goal, the only path forward is feeling safe enough to be honest – and there ain’t no way out but through.

last but not least, a few rapidfire recommendations for working at any company for a long time:

• take all your vacation
• don’t work outside of hours
• make use of all your benefits
• care for and hear each other or risk letting the alienation and dissonance of the workplace run rampant
• organize, if there is an opportunity to do so – especially if you want to work somewhere a long time, for a long time.

it’s been a great ride. if you worked with me and you’re reading this – please, don’t be a stranger!