Legibility is Ruining You
31 points by banana_oatmeal
31 points by banana_oatmeal
Making humans fungible is not an assumption. It is a desired end state to remove power from workers and concentrate it in the hands of managers. If this leads to halved productivity compared to empowered (and happy) employees, that's an acceptable and perfectly rational trade-off in their eyes.
- Any engineers with the same job title perform roughly the same.
- Engineers can be shuffled and reorganized without substantial loss of productivity.
This gave me flashbacks to my unhappy tenure at Google (2008-2010). What a sausage factory. Their whole hiring process was based on engineers as interchangeable parts, who could be interviewed by people they’d never meet again, and hired without first thinking of what group they’d work in. Once you got there, your code quality was measured by whether your line breaks and whitespace matched their “legibility” rules and whether every. single. function you wrote had a boilerplate unit test. That was the most miserable 18 months of my career.
Shh, you’ll ruin the dreams of many not-yet-employed-by-FAANG devs by mentioning what reality is like :)
whether your line breaks and whitespace matched their “legibility” rules and whether every. single. function you wrote had a boilerplate unit test
oh so that's why I failed the tech screen :thoink:
As the initial Occupy dragged on, I had a hunch that much of their ~power was coming from their inability to articulate legible demands or values that could be understood, framed, categorized, co-opted, and strategized against.
On some level I hoped they would manage to just sit there for years, banging their drums and deeply disturbing everyone who needed them to make one kind of sense or another.
That's a very interesting connection to draw. It reminded me of a classic Crimethinc article, Why We Don't Make Demands. They don't put it in terms of legibility but that's a good way to frame it. From the conclusion:
Instead of making demands, let’s start setting objectives. The difference is that we set objectives on our own terms, at our own pace, as opportunities arise. They need not be framed within the logic of the ruling powers, and their realization does not depend upon the goodwill of the authorities.
Thanks for posting this. I also liked:
A movement that includes a variety of agendas is flexible, unpredictable; it is difficult to buy it off, difficult to trick the participants into relinquishing their autonomy in return for a few concessions. A movement that prizes reductive uniformity is bound to alienate one demographic after another as it subordinates their needs and concerns.
and
Demand-based politics limits the entire scope of change to reforms that can be made within the logic of the existing order
It's essentially the industrialisation of software development, the fate we visited upon so many other fields of endeavour come back to haunt us. Software itself is, with few exceptions, the distillation and encoding of thin rules from an existing body of thick rules painstakingly evolved, maintained, and owned by workers, the ultimate Taylorist dream. There have been upsides to this, yes - when we reduced the friction of processes that were already all but algorithmic in nature, or in the rare cases we created something truly new and beneficial -, but it also enabled unprecedented control by the managerial class while disenfranchising a workforce who, ironically, must still more often than not carve its own desire paths through the rulebook in order to get anything done.
To hell with legibility; just do the illegible and be illegible. Be a non-conformist. Stop using LLMs to generate code so you can make more milquetoast code and produce more boring words for other people to have an LLM summarize for them. There's 0 demand for both; let's focus our creativity on the tail ends of the distribution and create weird code and outrageous ideas/words instead
Also nice connection to Value Capture by C Thi Nguyen, I'm part way through the audiobook and it's really speaking to me lately.
So I mostly agree, but at the same time I think that a bunch of the processes mentioned here are widespread because they have real value as long as they are recognized as means and not ends.
Code review contributes greatly to quality and maintainability and nobody should be shipping unreviewed code unless something's on fire and there's literally no one you can grab to look over your shoulder.
If you spend one hour out of every two weeks to look over upcoming work and ask yourselves whether each task is still relevant to current needs, whether it's defined enough to work on, whether it has unresolved dependencies, or whether you need to break a chunk off or do some research — it won't just "increase velocity", it will make people feel better and more confident about their work.
Style guides save endless arguments over the kind of crap where the supposed benefits of A vs B are far smaller than the benefit of everyone just agreeing to one of them, and they make code review less likely to turn into an adversarial process. Etc. Etc.
The question is, do you have a team that does those things because they take some pride in work and recognize those things as tools that help them write high quality code, make customers happy, etc.? Or do you have a team that does those things because a team that follows the processes is "doing good work" regardless of whether they ship on time, regardless of whether their code is buggy, and regardless of whether the thing they're building serves customer needs?
“Ship on time” is totally about legibility. In my experience, the perceived value of a ship date is orders of magnitude more than actually shipping.
Fair enough, but just call it sloppy language on my part. I don't mean working to arbitrary deadlines, so much as not having your work wasted. i.e., does the feature ship at all, and in time to do any good?
Sorry - I do agree with your points, but the whole thing around estimation and delivery is a huge trigger for me, let’s just say I’ve been bludgeoned with it in a past life.
“Not having your work wasted” is a really good phrasing.
Relatable. I used to work for an agency. I mostly enjoyed the work, but having to log every hour of my time felt dehumanizing.
the processes mentioned here are widespread because they have real value as long as they are recognized as means and not ends.
Came here to say basically this. The social cohesion you gain is what's valuable. That cohesion can result in concrete gains that are legible, but that's not necessarily the main benefit.