The Software Ark: Issue 9
Quote of the week
Just a reminder that all bug prioritisation schemes in practice degenerate to three scheduling categories: do it now, do it later, never do it. If you have a numbered system with many priority levels, what you actually have is a bureaucratic system of denial.
- Kevlin Henney
Articles
Not quite the same as dashboarding done right - since there is no such thing as a "correct" dashboard - only a useful one. You want metrics, explanations, worry-lines (i.e. if it hits this point we start to worry), links to other dashboards, key external metrics, etc. You need to boil the ocean to find the most useful few metrics.
This is tough, so instead I've found more success with hierarchical dashboards. You build a top-level dashboard of key business metrics. You build a set of lower level dashboards for each key system, and sub-dashboards as needed for deep-dives. A good dashboard takes time - typically a couple of hours each month. But it saves you a lot of time when things go wrong.
Last week I was in SF meeting with the wider WA BizX team. It came as no surprise that the engineers were warm, kind, geniune, with solid technical depth - even the more senior engineers. There was no "level-itis". What did surprise me was that I was having a very deep technical conversation with someone on the management path last week, and I was out of my depth. My previous experience with managers were with people who were only "lightly technical". The shift was great! The entire trip made me excited to work at WhatsApp and I felt energized by the idea that someone would call me out on any BS and I'd need to be on my A-game. It also got me thinking about Engineering Leadership.
I've always believed in benevolent dictatorship (Guido's BDFL), and hierarchies. Not as a way to drive career satisfaction, but as a way to build a cohesive product, and drive efficiencies. Having a single-threaded-owner across the org to escalate to really does help. At the very least, it provides a consistent prioritization landscape you can rely on. But at the same time, hierarchies can stem creativity, force one-person's vision, and inhibit career satisfaction. It's why you need checked-power; almost, selective anarchy. You have to be critical, otherwise things can go wrong fast.
It's not that you can't get by without hierarchy - it's just harder, especially the more senior you get. Driving impact in the absense of hierarchy requires investing in more time-consuming forms of influence like the favor bank. It's not bad, things just take longer. In return you get a better marketplace of ideas - at least in theory. I'm curious to see what I think in 6 months.
As a free-market capitalist, doing stuff you don't enjoy doing was always part of the game, but framing focus that way wasn't something I considered, even if it was something I followed. When thinking about work I looked at it like creativity in a straight-jacket: how do you find work that makes you happy but is valuable enough to get you well paid.
Often it's work that the org needs done even if you don't enjoy it. My rule has always been to enjoy the domain, and the process. Building well crafted software brings me joy, even if what exactly said software does doesn't enthuse me. To do this, I've found it important to know my stakeholders, read through 3 year plans, and fully contextualize the big-picture. Knowing how my work fits into the broader picture helps me advocate for calls that I think will pan out long-term, even if they hurt right now.
It helps that I love to play devil's advocate. Arguing a position I don't hold is genuinely a lot of fun for me - it's not about being right, but about refining an argument. Taken too far it can be very frustrating, so I've had to get better at knowing when to stop. That said, it usually gives me a robust understanding of the factors at play, and lets me know which arguments are most convincing in support and in opposition. I've also found "whining" to a good friend at work be a powerful motivator. Not only does it force a different perspective (which is essential when I'm emotionally invested), it also acts as a litmus test. If I feel better after whining, it stops there. If it still frustrates me, it might be worth doing something about. It's a weird blend of pragmatism, idealism, and optimism all in one go.
This in turn has made me happier. Acknowledging that the world is not aligned around my priorities makes it less frustrating when there's bad code, or time-pressure, or repetitive tasks. It's becomes about finding those little things in a day that make it fruitful.
In the end, my role is that of the impatient optimist. I believe things can get better, and that I can change things. And that's good enough for me.
Links
- An aging programmer's thoughts - "I have no idea about how effective pair programming is. My desire to discover it is zero." resonates with me.
- The lost art of maintanence - we all like cool tech, but sometimes you've just got to deal with what you have.
- A brutalist HTML quine - seems like a bit of a cheat to be honest.
- Robots will be able to traverse graphs - useful context for the inevitable uprising
- Markov chains and matrixes - it's never too early for stats
selfin python - worse is better- How passwordless works
- Who doesn't like state machines - I still remember using a BNF to solve a lexical parser problem in an interview - CFGs are just FSMs with an infinite stack :)
- Multi-tenancy is hard, enter shuffle sharding
- Optimal recommendation under a finite time budget
- Resiliency in distributed systems
- Criticism in brainstorms leads to better results - critique away
- Prioritization is hard
