Why can’t I just code all day?

“Why can’t I just code all day?”

The question struck me in the middle of the third interview I was conducting that week, and I couldn’t let it go. I barely paid attention to the program the candidate was writing, but I knew he wasn’t going to get the job after two minutes anyway. Too nervous, and I don’t want to work with nervous people.

I hurriedly filled out my feedback, calling out some weird variable names and topping it off with “Lean Against Hire”, which usually does the trick without incurring too many questions. As I scrambled off to my next meeting, all I could think was, Why do I have to do all this stuff? Interviews, standups, all-hands, presentations, writing/reviewing docs, mandatory trainings, OKR plannings… Why can’t I just write code? That thing that I went to school for and am actually good at?

I sat through the next meeting, asking just enough questions to show that I was paying attention, even though I wasn’t. All this cruft that chops up my day into 30 minute blocks is the worst part of my job. No one looks forward to a scrum call. When I get into the office, the first thing I do is figure out how to cut through all the BS as fast as possible so I can have some long, focused, headphones-on-don’t-talk-to-me coding time. It’s when I’m happiest, and it’s when I’m doing my best work. It’s a total win-win, so why is it I didn’t fire up Vim until 4PM today?

Next up was a 1:1 with my manager. A few years ago, she was the best engineer I had ever worked with, and we made some internal tooling so good that it was now a full-fledged product offering. But it was too good; she got promoted, and now she wearily trods from meeting to meeting as the Tech-Lead Manager of 12. I haven’t seen her send a PR in weeks. How do all the best engineers let this happen to them? Can’t they see through their shiny new titles and and responsibilities that they are trading job satisfaction for money?

It’s simple, I figured: Programming is the best part of my day. I make more than enough to be financially stable, so I should maximize the time I get to do the fun stuff. So, no more cruft. No more interviews, or corporate trainings, or half-day roadmapping sessions. For the first time in my career, I’m going to be an engineer above all else, dammit.

I couldn’t tell my boss this, of course. But I didn’t need to. I had been a senior engineer for years, so she mostly let me do what I want, choosing to split her time between the 11 other reports.

Additionally, I knew not to cut out everything. I’m not an idiot, and obviously I’d waste time making the wrong thing if I didn’t attend stand-ups and read through designs. But I ruthlessly cut things out; all-hands, interviews, anything that I felt didn’t add value. If anyone asked, I would be honest, saying I was having too many meetings lately and needed to cut back. In the end, not many people asked. I looked at my next week: 4 hours of meetings, total. It’s still 10% of my time, but it looked like a nice start.

And a nice start it was. I could really get into a groove in a way I hadn’t been able to since pulling all-nighters in college. A couple of times, I accidentally coded through lunch, lost in the design patterns and not realizing the hours were going by until my stomach loudly complained. It was liberating to not be squeezing work in between interruptions, and when Friday afternoon came I felt a tinge of actually looking forward to getting started again on Monday.

A few glorious weeks later, I was sitting in iteration planning. My team had noticed my improved productivity, and I’d even garnered some formal recognition from the product manager. I should have done this a long time ago, and I was less paying attention as much as considering if I could put this meeting on the chopping block as well.

“Kevin, can you start the design for the iOS version of the app?”

I looked up, a bit annoyed to be disturbed from my daydream. “What?” I said.

“One of our OKRs this quarter is to add iPhone support. It’s a big project, but can you start it this sprint?”, our TL asked.

I blinked. “Uh, sure. But, why are we doing an iOS app? Do our two markets actually intersect that much?”

“Yeah, we chatted about that a lot. The answer is not really, but enough that it could be worth pursuing, and we have some partners that really want it. Happy to talk more offline, I’ll put you down for the initial design in the meantime.”

As we went through the rest of the task list, my emotions turned from surprise, to confusion, to anger. There is no way we should be working an another mobile platform. It’ll be nothing but a massive maintenance burden and will detract from our core market. When the meeting was over, I immediately scheduled the first open block I could find with our TL and PM, which of course was several days later.

Until then, I prepared a presentation listing all the reasons why this was a dumb idea. After I showed it to them in the meeting, our PM responded quickly: “This is all perfectly reasonable, and actually would have been really useful in our partner discussions. But there are a lot of stakeholders for this project that we’ve already aligned with on multiple axes. This presentation doesn’t take into account their needs — perhaps we should pull you into these conversations moving forward?”

And so it ended, as quickly as it had began. I had a few product scoping meetings added to my calendar, and the rest came falling down as you might expect. We hired a sub-par engineer who wrote code like an ML model trained on Excel spreadsheet formulas, so I started interviewing again and helped revamp our hiring process. We spent a few months designing something that turned out to be a near-duplicate of another system elsewhere in the company, so I started doing presentations and design reviews to increase visibility and get early cross-team feedback. And of course I had to go to planning and alignment meetings to make sure no one made any more inane decisions that I’d have to implement.

The point of the above (fictional*) parable is a bit of a thought experiment to play out what would happen if I did just optimize for coding time. I do actually believe that we should be cutting out meetings that we don’t add value to, that many companies could do more to support asynchronous work, and that we should do as much Deep Work as possible.

But at the end of the day, we don’t work in a vacuum. Organizations are large, complex structures that necessarily have serious communication bottlenecks and overhead. As you rise in seniority as an engineer, you will naturally fill these bottlenecks not as a result of greed for more power or money or responsibility. You will do more high-level planning across teams and resolving ambiguities, because if you don’t, then decisions will be handed down to you that you disagree with. Good engineers often want to be involved in these decisions, but that requires working through many layers of communication. And yes, this means less coding, more meetings.

*You know it’s fictional, because I use Emacs, not Vim. Well, VSCode now, but that’s for another time.