Notes to me in 1993

Plus: It’s easy to miss productivity opportunities outside of engineering; and, the disturbing inevitability that a platform we come to love must eventually die.

I turned 46 earlier this month. I don’t think I said that anywhere? As an introverted kid who mostly liked grown-ups more than kids, with a birthday just a few days after Christmas and the New Year, I have generally been on the side of “haven’t we already celebrated enough?” by the time my birthday rolled around, and I continue the tradition today.

There’s a whole lot about the last 30 years that 16-year-old me would … I don’t even know. I mean, y’all is an important part of my vocabulary, I have a kid, and there was a whole global pandemic, none of which I anticipated. There were many times where success was most definitely not assured or even likely.

But: If someone had told me 30 years ago that I would end up in a role where I would speak/write/educate about how to be more productive/efficient at [something having to do with computers], 16-year-old me would have said “yep, that sounds about right.” Every new job I’ve taken, for years, has been attached to a story that started when I was the editor for my high school yearbook, published in 1993, the year I was a senior and we switched to making the book using … computers.

Look at those fancy drop caps.

It’s my first week at newjob, which I promise not to talk about too much here, but the first week of a job is always a time for reflection for me about what came before and how I got to where I am, never mind the birthday and New Year bits. It’s been a long and winding journey, but I’ve stopped being surprised that it keeps crossing this path.

---

What are we missing if we’re just looking at productivity as an engineering problem?

"Agile Otter" Tim Ottinger @tottinge

“How long does a 2-point story usually take?” “We peg story points to half-days so 2 points is one day.” “Yes, how long does a 2-point story usually take?” “One day.” “Historically, or ideally?” “One day.” “Most of the features you released are over 40 days old.” “But, um….”

This thread really resonated with me because it highlights how leaders who are trying to improve productivity can be reluctant to look at processes outside of the development loop, and overemphasize the impact engineers have on the overall process of getting value to customers so they will keep paying you money, or whatever it is they do for you.

Amdhal’s law — the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used — tells us something that seems like it should be obvious: if you improve the performance of a subsystem, the improvement to the overall system can only be as large as the time the subsystem consumed.

We talked about this a lot in frontend performance conversations, how backend-centric teams would optimize a request/response loop to take 50ms less, while sending a 2MB JavaScript payload that they thought didn’t matter because it’s on a CDN.

This same reality applies to any process. That is, if you target a part of your delivery pipeline that takes two days, but delivering anything actually takes 40 days, the best you’re going to do is 38 days. At a certain size, org structures don’t typically make it easy to have this kind of cross-functional approach to productivity, and I think that’s going to limit the upside of some productivity conversations.

---

What if platforms can be doomed by our love of them?

I missed this the first time around, but I’m glad I came across this long, deeply heartfelt, brutally nostalgic rant

Stop Talking to Each Other and Start Buying Things: Three Decades of Survival in the Desert of Social Media

about the evolution and (inevitable?) demise of platforms we come to rely on. (I’m especially glad that I read it before Cory Doctorow’s also-good but much-less-fun post on the same topic, which mostly served the purpose of making me seriously question whether this can even be avoided in an arrangement where there is also capitalism.)

---

A favor

For the people who made it this far: It’s been a very long while since I worked at a company with 50-200 engineers, but companies that size have so much opportunity to introduce productive changes, and it will be so much easier to do it now than a year from now if you’re trying to grow.

So: It’s time for me to learn some things about how companies this size work, by talking to engineering leaders at companies in that realm.

I’m curious to learn about how teams are arranged, how cross-functional collaboration works, the tools your engineers depend on and the tools they hate — really, this 200-ish engineer world has changed so much since I was in it last, and I’m eager for an updated perspective. If you’re willing to chat, you can find a time here.

p.s. This is 100% not a Sales Call unless, uh, you’re into that sort of thing. But I am very happy to share my own experiences where useful and relevant, too!