Legibility Is Ruining You(jimmyhmiller.com)
jimmyhmiller.com
Legibility Is Ruining You
https://jimmyhmiller.com/legibility-is-ruining-you
7 comments
Feels like the real issue is that metrics aren’t just measuring but they’re shaping behavior : Once you reduce something complex like some good code, happy users or solid product decisions into a number then people start optimizing the number instead of the thing itself. True thzt it scales better but then you lose a lot of what really matters; I don’t think companies are wrong to do it but just that the trade-off is way bigger than people can admit.
TLDR: It is the world that has been pulled over your eyes to blind you from the truth.
This essay is asking a personal question: what do you care about?
But when you're on the job, you're getting paid to do some work by other people. So if you care about something, you have to communicate why it's important to other people - that is, make it legible.
But when you're on the job, you're getting paid to do some work by other people. So if you care about something, you have to communicate why it's important to other people - that is, make it legible.
As a manager, I've tried for years to balance both sides of this coin.
However, what I find in practice is that your success depends almost entirely on the trust your leadership has in you.
Strong support? Doesn't really matter what you work on, legible or not. Weak support? You can do exactly what they ask and it'll still be an uphill battle, leaving you in a hard situation where you can find ways to do the illegible work, but it will require spending political capital you already don't have (And to preempt the "make that work visible and valued" counterargument, that only goes so far if incentives are misaligned), or gambling that you can change their perceptions by only focusing on the legible work for a time even if it results in worse long-term engineering outcomes and may not bear fruit.
In short, I'd say the most actionable advice I'd give is less about where you spend your time, and more finding a team (or more importantly, a sponsor) where however you spend your time will be valued.
Strong support? Doesn't really matter what you work on, legible or not. Weak support? You can do exactly what they ask and it'll still be an uphill battle, leaving you in a hard situation where you can find ways to do the illegible work, but it will require spending political capital you already don't have (And to preempt the "make that work visible and valued" counterargument, that only goes so far if incentives are misaligned), or gambling that you can change their perceptions by only focusing on the legible work for a time even if it results in worse long-term engineering outcomes and may not bear fruit.
In short, I'd say the most actionable advice I'd give is less about where you spend your time, and more finding a team (or more importantly, a sponsor) where however you spend your time will be valued.
The book Moral Mazes by Robert Jackall is a supporting reference to your take, worth a read.
I think this needs to be re-written with different terminology.
"...you don't care about code review"
Code review is one of the things I care about most! In fact, now what we're in an age where many code changes are generated by LLMs, I think that code reviews are far more important than they used to be.
"Processes adopted by a company aren't about the end result of the work. Their stated goals and their actual goals are always distinct."
Wrong again. Often the goal is exactly as stated, for better or for worse. Let's take incident reviews as an example: their goal is to reduce the occurrence of emergency incidents in the future by learning from the mistakes that led to incidents in the past. There's no doublethink involved.