Epistemic status: High confidence about the pros/cons discussed regarding my own experience, fairly low confidence about the parts I heard secondhand.
Epistemic effort: Low-to-medium effort. I realized these things were connected while I was in the shower last night, then I spent two hours stream-of-consciousness writing to get them onto the page. I then read it over once for minor editing and shared it with a friend to sanity check.
1.

"Bike shedding" is one of the best terms I've learned in my time as a software engineer. It refers to giving disproportionate weight to marginal but easy-to-grasp issues while more serious ones are overlooked. (It originates from an apocryphal story of a committee whose job it was to approve plans for a nuclear power plant. Instead, the committee spent the majority of its time discussing what materials to use for the staff bike shed.)

Programmers are notorious for falling into this trap. I suspect we're far more susceptible to it than even the nuclear engineers in that story, because developer tools are highly customizable by nature of themselves being software. Many of us got into coding in the first place because we enjoyed tweaking (or better yet building from scratch) our workspace to fit our preferences.

This deep customization works great when you first start coding—most people's early experiences are little personal projects they build alone—but disagreements arise when you start to work with other engineers who inevitably have their own, totally different preferences. Some of these are useful, but most of them are arbitrary. Whether to use tabs or spaces, which continuous integration service to choose, whether to force alphabetical ordering of imports or to not... the list goes on and on. This is like deciding which side of the road to drive on. You should not really care if you're on the left or the right as long as you're driving on the same side as everyone else.

I'm as much a culprit as any other developer. Formatting in particular has always been the source of many wasted hours tweaking lines of code and, worse, leaving little "nits" in code reviews. This year, I'm proud to say I've gone cold turkey with wasting time on code formatting, though it's not a function of my self control. These days I use Prettier, an opinionated Typescript formatter. Given a valid program, it will reprint the code from scratch in conformance to a strict, consistent style.

Take the following example from Prettier's docs:


It fits in a single line so it's going to stay as is. However, we've all run into this situation:


Suddenly our previous format for calling function breaks down because this is too long. Prettier is going to do the painstaking work of reprinting it like that for you:


This is great! It's even more powerful when you configure the whole project so that every developer who works on the codebase deals with the same rules. Suddenly, we're not wasting time formatting whitespace in our own code. More importantly, we're not starting comment threads on Github about why it would be nice to have a little more whitespace here, a little less whitespace there, and an extra semicolon over there "just to make it a little more clear".

(Some relevant history to avoid a flamewar with my friends who are Go enthusiasts: Pretter was inspired by Gofmt, a tool that automatically formats Go source code. The Go Blog has a great overview of why code formatters are powerful. I'll leave it to you to explore the arguments. 🙂)

2.

At a BBQ yesterday, a friend mentioned an ambitious infrastructure project he worked on a few years ago. It was a new type of transportation network with lots of multidisciplinary work between engineers, planners, service people, technocrats, and business owners. This particular technology hadn't been tried before, which is what made him so excited to work on it but also the reason it failed. I asked him what happened, and he said the core problem was one of interfaces: because nothing like this had been built before, every single responsibility and dependency had to be explicitly discussed before anything could move forward. For conventional projects, the roles of various team members are well-defined and understood, but for something new these roles have to be hashed out on the fly.

Without understood patterns about how to solve problems, the project was bogged down with inefficient overlaps of focus as well as gaps that everyone thought were someone else's responsibility. Coordination to figure out who owned each piece was time-consuming and expensive, resulting in budget overruns.

Specifically, he noted that many pieces of the project were not well understood. Because no one had built this kind of network before, the people working on the project didn't have defined patterns about how to tackle problems as they arose. It wasn't even that the individual technical problems were extremely challenging, more that it was hard to know who was responsible for executing the solution. He said the project was bogged down by having to coordinate whose responsibility each piece was, resulting in everything taking far more time than in more conventional infrastructure projects.

I thought this was fascinating. I hadn't considered the possibility that the well-established common knowledge that characterizes more conventional projects was such an advantage. The failure wasn't in the design itself—the failure was that the interfaces were ambiguous.

3.

I'm generally not a big follower of traditional gender roles. As a female engineer who was the only girl on her 2nd grade Pony Baseball team and served as the editor of her college's libertarian-leaning paper, I'm a bit of a statistical anomaly as far as feminine stereotypes go. However, there is one traditional gender norm wish we hadn't done away with so fast: men picking up the check.

This is not about getting a free meal—I'd be just as happy if the norm were reversed. The thing we've lost by throwing away this tradition is simplicity. Instead of a simple rule where everyone knows what to expect, receiving the bill at the end of dinner turns a fun date into an awkward test that stresses out both parties.

Renegotiating these issues every single time you grab a drink or a bite to eat with someone of the opposite gender is exhausting. I always worry: "If I insist on grabbing the check, will he feel like I'm trying to make some feminist statement? If I don't grab the check, will he think that I'm just trying to take advantage of gender roles to get a free meal, even though I probably make as much if not more than him?" I've never been on the opposite side of this, but I can only imagine the concerns running through his head are even more intense: "If I grab the check, will she think I'm trying to impose gender norms on her? That I don't think she can pay for it herself? And if I don't grab the check will she be offended that I didn't do the gentlemanly thing and offer?"

No matter what you do it comes off as a political statement. It's like deciding whether to use he, she, (s)he, or they (I'm not going to list all of the possibilities because we could be here all night...) when you need a generic pronoun to discuss a hypothetical person. Back when every writing style guide prescribed the generic "he", it was a trivial choice. Now it's up to the writer to decide, turning a small technical detail into a distracting decision. The upside of this cultural shift may be worth it, but the ambiguity comes with a cost.

I've been lucky to be in wonderful long-term relationships, which means we get past these worries pretty darn quickly and just move on to the fun part of hanging out. But it's still annoying to hash out who pays each time. We roughly want to keep it even, but we also don't want it to feel transactional by keeping some sort of tally. I've toyed with the idea of flipping a coin each time, which results in a fair split if you hang out a lot, but that still involves annoying overhead. It would be so much easier if we could just pick a simple rule and stick with it.

I miss this norm of men picking up the check not because I think it's inherently "the right way" but because it is useful.

(This obviously goes without saying, but it'd be wishful to think it's not necessary to state explicitly: defaulting to traditional gender norms has its obvious flaws, and on net I'm pleased to live now rather than 50 years ago when women needed their husband to cosign on a loan.)

4.

When I was younger, I thought tradition was patently ridiculous. Why would you do something just because people had been doing it for years before? That sounded like a silly reason to do anything, besides maybe some aesthetic appeal that didn't resonate with me at all. If another system worked better, I thought, you should switch to that without hesitation.

In the past few years, I've realized that another word for tradition is "convention", and conventions can be really useful. They can save time and headaches if everyone knows what to expect from everyone else. This simplicity is not necessarily worth the other problems it causes—there are times when we should seriously consider bucking tradition, and it's worth pushing the envelope to see if some new way of doing things works better—but the tradeoffs are real, and we should order our priorities carefully. Sometimes, throwing away convention just for the sake of not "arbitrarily" following tradition can create its own problems.