Three things I'm bad at

Every couple of years I try to write down what I am bad at. Not in a self-deprecating way. Not as a résumé exercise in reverse. Just: what are the honest weaknesses in my craft, right now, that I would like to be less bad at in two years.

Here are three.

I am bad at estimating distributed-systems work

I am fine at estimating the single-service, single-database, single-request kind of work. Give me a feature in one process and I will give you a date. I might miss by a day, not a week.

Put a queue, a cache, and a third service in the picture and my estimates start lying to me in a specific way. I undercount the time it takes to design the failure modes. I say "two weeks for the happy path, another week for the edges" and what I mean is "two weeks for the happy path, another six for the edges, the last two of which I did not know existed." I keep doing this. I have been doing this for years.

The tell is always the same. I spec out the work on a whiteboard, I can see the data flowing through the boxes, and the estimate falls out of the whiteboard diagram. What is missing from the diagram is every place two boxes can disagree about state. The boxes look serene. The reality is that three of them are racing each other and one of them is going to be briefly wrong on every tenth deployment.

The moment I noticed it most clearly was on the referrers API work. I estimated four weeks for the index. It took seven. The extra three weeks were entirely about what to do when the index disagreed with the source of truth, which happened for reasons I had not imagined, in patterns that only showed up at a traffic volume I had not tested against. I was not wrong about the index. I was wrong about the world the index lived in.

What I am trying is to build estimates in two columns. The first column is the code I can see. The second column is the disagreements between systems that my code creates or inherits. I multiply the second column by two before I tell anyone a date. It is a hack. It has not failed me yet. I expect it to fail me in a way I have not yet imagined, and at that point I will write another post.

I let a junior engineer's PR sit too long

This one is not a technical skill. It is worse.

I tell the engineers I mentor that a PR review is the single highest-leverage thing a senior engineer does in a day. I believe it. I still, regularly, leave a junior's PR open in a browser tab for two days before getting to it. Sometimes three. I tell myself I am waiting for a clean chunk of time to give it the careful read it deserves, which is true. I am also, underneath that, avoiding the emotional weight of delivering hard feedback to someone I like, which is also true, and which I am less eager to admit.

The cost is not that the feature ships a day later. The cost is what happens to the junior engineer in the meantime. They have moved on to the next task, they have built on top of the branch, they have lost the context they had in their head when they opened the PR. When my review finally lands, they have to remember what they were thinking, re-engage, and revise under time pressure they would not have had if I had shown up on day one.

I noticed it most clearly watching one of the engineers I mentor actively slow down over a quarter. Not because she was struggling. Because every PR she opened with me on it took a week to close, and she stopped opening bold ones.

What I am trying is a rule: no PR from a junior sits in my queue for more than four working hours without at least a quick pass. Not a thorough review. A fifteen-minute read with either "looks broadly right, will do a careful second pass tomorrow" or "two things to think about before I go deeper." Four hours. That is the target. I miss it, and I log the miss in the same text file I keep for broken things. Over a quarter the misses have gone down. Not zero. Down.

I read Go like it is Java

I write Java most days. I grew up on it. My instincts about what a codebase should look like are Java-shaped — classes, interfaces, dependency injection, exceptions that bubble up a stack of layers.

A few of the services I touch are Go. I have been contributing to Go codebases for four years now, which I realize as I write this is a long time to still be bad at something. I am still bad at reading it.

Specifically: I read a Go function and reach for the abstraction that is not there. I see a struct and four methods on it and my instinct is to ask where the interface lives. I see error returns threaded through every call site and my instinct is to ask where the try/catch goes. Neither instinct is useful, and every time I indulge them I am quietly pulling the code I am reading away from the shape its authors wanted and toward a shape that reminds me of home.

The tell is that my Go code reviews are measurably worse than my Java reviews. The comments I leave are more pedantic, less perceptive. I catch style issues and miss idiom. A Go engineer on my team once, kindly, told me that I was reviewing their PR as if it were a Java PR. They were right. I thanked them. I am still doing it.

What I am trying is to read Go without reading for review. I read a Go file a week — a file in a popular Go project, something I will never have to change — and I try to notice the shapes the language actually rewards. When the struct does not implement an interface, I make myself ask what is gained by the absence instead of what is missing. When errors are passed up three levels, I make myself ask why the original author did not wrap. It is slow. It is also the only way I can tell it is working — my Go reviews are getting a little less Java-shaped each month. Not fast. Not yet comfortable. Slowly.

Why I am publishing this

The temptation, writing a portfolio site, is to only publish the parts of yourself that are already good. That is the incentive. That is also a trap.

The thing about publishing a weakness is that you can no longer pretend to yourself you did not know. I have known I was bad at distributed-systems estimation for five years. I tell people in private conversations that I am working on it. Writing it down here means the next time I blow an estimate by three weeks, I cannot tell myself the story that this is the exception. The exception is the rule. I am the one making the estimate.

Publishing weaknesses is a cheat code for getting better at them. Not because anyone is watching. Because I am.