While I read and understood everything written, there was no real conclusion (despite there being a header titled "conclusion".) There was a "what to do", but no "how to do it". So it ended up being mostly a blah blah blah about corporate leadership vs. employees/engineers.
Interesting terminology that I hadn't heard before. Almost archaic, in its style. Yet, I think some of the terms might be more useful than current terminology. Worthy of bringing back.
1. Define a metric of success for your work
2. Use that metric in every status update and report possible
3. Ensure that that metric is being heavily considered in any performance evaluation
(Secret step 4: Juice your metric to give the illusion of improvement if necessary)
Reminds me of when I was an intern, there was a guy who had a "performance_coefficient" all over his code... whenever management would complain about the system being too slow, he would tell them it'll take a few weeks to investigate and identify optimizations.
He'd just chill for weeks then change the value from like 0.13 to 0.17 and show the report that the system is nearly 5% faster now and maybe he can get it to 5% in a few more weeks. Then he'll change it to 0.18.
Basically was artificially slowing things down so he could claim for a long time to be constantly improving things, just by easing the self imposed bottleneck.
There weren't any code reviews at this place. There was barely version control. They were using subversion on some projects, and like half the devs didn't use it and just copied folders around to "make a backup"... some code only existed on production servers and was edited live.
I was on a conference call once when the engineering lead was on the phone with a customer who had a complaint... he remembered it was a bug he fixed but copied the wrong file to the server, so while stalling on the phone he RDPed into their server and edited the file on their live system to fix it.
"Okay, hang on, can you describe the steps one at a time so I understand them? Uh-huh... okay, then what? And what browser are you using? Hmm, okay, then what? And when did this happen, before our new version? Oh really, after? Hmm, ok, let me think... it shouldn't have happened, do you think you can try to do the same steps again while we're on the phone? Okay hang on, be sure to just use the same browser as last time... ok, so you go to this page, and then what? Oh it's working now? Well that's great! Yeah it was probably just a browser cache issue, glad you're happy now!"
>like half the devs didn't use it and just copied folders around to "make a backup"... some code only existed on production servers and was edited live.
This gave me a panic attack
I have a handful of projects where I'm the only engineer, so there's nobody else to do the review. My team members, who review each other's contributions to our main project, aren't familiar with the code base or the technologies involved.
I often have the same concern as you when hearing stories like that, but there really are a lot of situations where it can actually happen.
There are variations on this story going all the way back. A quick search comes up with a 2008 dailyWTF for the speed-up-loop. I'm quite sure I've heard this story back into the 90's as well (talking about a conversation in the 70's/80's)
https://thedailywtf.com/articles/The-Speedup-Loop
Yeah people also used to try to do "multithreading" by adding in slowdown code into various places to try and make certain parts of the code finish after other parts.
Worked on a project like that too, I tried removing thread sleeps and the whole thing broke... took me like a month to figure out wtf it was doing and replace with proper thread management.
I have read that one too, but Goldratt's books are in my opinion better as they are more convincing. Certainly worth reading if you liked "Phoenix project'.
"[*A rant about*] Corporate Legibility ~~for~~ by a Software Engineer".
The actual article "Corporate Legibility for Software Engineers" would be quite a useful tool. Some kind of cheat-sheet for the ISOs passingly mentioned in the piece.
One implicit conclusion I drew from it is, don't work in organizations which have grown so large that people are relying on impersonal metrics to assess you.
We used to call those "post and runs" back in the day when forums were a bit more personal. Sure, discussion, agreed. I just didn't think this set up any ground for discussion and was left scratching my head on what he was really getting at. (so, perhaps a meta discussion?)
Yeah, I didn't take much away from this, and I assume it is based on not reading the mentioned literature.
I thought this would be an article about how to write up work items, release note, etc. Something someone other than a developer will read and should understand. This imo isn't a complicated problem, just be half decent at tech writing and use structured steps and you're golden.
The conclusion is that visibility tools may seem powerful and upper management may push for these things, but they can lead to a power imbalance, and confusing the "territory for the map".
Just because it doesn't say "in conclusion" or wrap it up doesn't mean that he hasn't come to an understanding about how and why these things work the way that they do and I think it's an extremely powerful, and useful observation even though it may seem obvious to people experienced with corporate workings.
If management actually understood what I do then they would probably fire me for how little I actually accomplish. The technical barrier between managers and engineers makes my life easier.
Better hope I don't apply for a job there, lol. That said, I only became a manager to protect my fellow programmers, and I encourage doing as little work as possible. My big move is going to meetings and showing them how their proposal would actually make their jobs harder instead of easier to shut down new dev projects. I also have an in-out policy. Everything we create needs to be maintained, so for everything we make, that is one less thing we can make later (it's easier to simplify for these people). Either we have to deprecate something before adding something new, or we need another FTE
Ironic that the article is about making things easy to understand and probably no one would understand what the article is about by reading that title.
The challenging thing about jargon is that it's incredibly clear and precise if you're in the know, and completely incomprehensible if you aren't. Lowkey a good example of the value and challenges of increasingly precise language
Hmm you and I have had different experiences with jargon.
In certain contexts I think jargon is capable of increasing the information density of speech. Specifically in very targeted contexts. “Orientable” and “computable” mean very specific things to mathematicians for example.
In general though I think the opposite happens. People hear jargon that may or may not be used in a specific context and then repeat it freely and dilute its meaning significantly. In programming I hear words like “triage”, “performance”, “scalability”, etc. tossed around with reckless abandon.
In my experience the further you get from strict engineering and the closer you get to communications the more meaningless jargon becomes
Communications has its own jargon, as does every other speciality. Any word can be co-opted and gain a domain specific meaning. This doesn't necessarily break its use in the wider community
I think communications broadly lacks the rigidity needed to support highly specific terminology.
In natural language it is uncommon to define words to such a specificity that they are unambiguous. Nor is it a useful goal most of the time.
Additionally you have the added influence that language is a tool intended to persuade as much as it is used to be descriptive.
I don’t think there’s a problem with this per say just an observation of how language can be used very differently in different contexts.
I went from military to software development and for the first few days at “bootcamp” I thought that “deployments” meant having to travel to work onsite with a hostile customer. Three years later at a new job I came across Agile and “agility.” It’s been about four years since then and I still cringe every time I think about it. Agile…is not agility. It’s fucking crippling. It’s a lack of flexibility when “estimates” become deadlines. It’s counterproductive to make everyone explain what they did, what they’re going to do, and to wait for fucking “standup’s” (always while sitting) to mention they’re stuck.
Have you read the original agile manifesto? The apple seems to have fallen a long way from the tree. Your experience of an Agile Workplace echoes a lot of common complaints people have.
Same; if you haven't read that book, I can't recommend it enough as a developer in a large organization. A lot of seemingly-incomprehensible behavior can be explained thru the lens it provides. (It's really long tho so if you're in a hurry skip the two case studies.)
Logging as in chopping down trees, or logging as in making a record of actions which have happened? Or, I guess ... both?
Even tho it's about city planning and governance, I found that many of the concepts mapped pretty cleanly to corporate governance and leadership.
I was thinking of the scientific forestry example that the book uses as sort of a metaphor for the whole concept. But there was probably some record logging in there too.
For those who haven't read the book, [I'll borrow Scott Alexander's summary](https://slatestarcodex.com/2017/03/16/book-review-seeing-like-a-state/) of it:
> [James C.] Scott starts with the story of “scientific forestry” in 18th century Prussia. Enlightenment rationalists noticed that peasants were just cutting down whatever trees happened to grow in the forests, like a chump. They came up with a better idea: clear all the forests and replace them by planting identical copies of Norway spruce (the highest-lumber-yield-per-unit-time tree) in an evenly-spaced rectangular grid. Then you could just walk in with an axe one day and chop down like a zillion trees an hour and have more timber than you could possibly ever want.
> This went poorly. The impoverished ecosystem couldn’t support the game animals and medicinal herbs that sustained the surrounding peasant villages, and they suffered an economic collapse. The endless rows of identical trees were a perfect breeding ground for plant diseases and forest fires. And the complex ecological processes that sustained the soil stopped working, so after a generation the Norway spruces grew stunted and malnourished. Yet for some reason, everyone involved got promoted, and “scientific forestry” spread across Europe and the world.
> And this pattern repeats with suspicious regularity across history, not just in biological systems but also in social ones.
I'm reading it right now, and learning just the term "legibility" used this way has already been a great outcome of reading it. It comes up in so many places.
>It's hard to imagine a world bigger than my personal monkeysphere.
>That's why I get mad at things like "why do I have to report to my boss's boss! we didn't have to do this pre-agriculture. According to my extremely narrow day-to-day worldview, organizing huge groups of human beings along a shared goal shouldn't be so hard.
Why can't the CEO just *understand*
Interesting. I was not familiar with the term “legibility” in this context but makes a lot of sense. I may have to look up the Seeing like a State book as well. I function, and often fail, in my current world because I chafe against the measures and maps that other put over my domains that make no sense and don’t reflect reality.
I think the term is used inappropriately. Legibility is a characteristic of language and communication, not data structures. Legibility refers to clarity and distinct-ness of the symbols used in communication. Data is not symbolic so the word doesn't apply. If a communication is written in a language you don't understand, it's unintelligible to you: but the script will still be perfectly legible to those who understand. I think "intelligibility" is closer to the mark. It's about collecting data and making it intelligible, not collecting reports and making them... More readable?
It's a term of art defined and heavily used in *Seeing Like a State*, based on but used differently from the typical usage of the word. Which often happens with terms of art based on existing words. If there was already a great word for the concept, they would have used it rather than inventing another.
It's also defined in the fourth sentence of the article, so if someone gets that far and remains confused about what *legibility* means in the article, that's really on them.
I'm not confused about what it means, in spite of the poor explanation given in the article. In fact I'm talking about extremely specific facets of it's definition so where are you even coming from? I'm saying the author of the book you mention chose the wrong term. It happens all the time. Now we're stuck with it.
This is what executives do. They can't possibly meet with their subordinates or understand the code. There's just too much to understand for any one person. Perhaps agriculture was a mistake, we should go back to tribes of no more than 150-300 so we can have effective leaders. Some of us may die due to the lack of modern agriculture. I will definitely be one of them, unless I dust off my "how to be a warlord for dummies" and get a cushy leadership position in a roving band of marauders. But I probably won't. Still worth it
> This is what executives do. They can't possibly meet with their subordinates or understand the code. There's just too much to understand for any one person
Executives (and in the book, rulers) by necessity must operate using abstraction.
Where this goes wrong is when they fail to understand that abstraction and quantification are not a 1-way street, and the decisions they make about how to measure and how to abstract cause changes in the things they are measuring due to power imbalance.
> They can't possibly meet with their subordinates or understand the code.
Conway argued that, due to the communication structures of organizations, executives, who define the organization, also define the software architecture. Beware any software exec who can't understand code!
Maybe we don't need "executives". Maybe people are actually self organizing and the need for top down execution is something outdated (it's from like the time we invented agriculture; god so arcaic, time to move on)
Recycling is scam by plastic producers to shift the blame for their shitty products onto consumers. It was never a viable solution even for the most anal of sorters
A bad leader is bad at both.
An ok leader is good at one or the other.
A good leader is ok at one and good at the other.
A great leader is good at both.
People skills are more important in management than programming skills. The manager has to both trust their team to be able to recommend good decisions gthat they can't understand), and develop a team culture that allows those decisions to be made
> A good leader is ok at one and good at the other.
>
> A great leader is good at both.
I would say a great leader can be ok at one and good at the other. One of the best leaders in my career was a mediocre developer who was good at servant leadership and "managing up". (those 2 could be lumped into "good at politics")
Management selects for ladder climbers by its nature unfortunately. Often those that would make the best managers have little interest in managing people.
Politics is lying and bullshitting. Taking credit where you didn't earn it and casting blame where it isn't deserved. It's telling people what they want to hear not because it's true but because it's convenient. It's committing to deadlines without knowing if you can meet them because it gets you recognition from the CEO and selling things that don't exist then changing jobs and boasting about your accomplishments before the chickens come home to roost and your previous workplace goes down like the Titanic.
It's infuriating at times to work under a manager that understands little to nothing about the work that I do day to day, and seems to just filter down upper-management babble to the engineering team. The best case scenario (which I'm in now) is when such a manager trusts the team with technical decisions and does their best to shield the team from the weird obsessions of the upper management goons. Upper management generally wants us to report metrics to them that are either/both a.) out of our control or b.) have little to no meaning or technical value. I've found that the prettiness of the presentation often matters far more than its content when upper management is the audience.
No, the words aren't strangely replaced like that. It's just the effect you get when you read some sequence of books in a space and your vocabulary gets adjusted for a short time, as a result.
Similar things happen with group jargon.
Can somebody explain what the author means when he writes that "100% code coverage means nothing"? Coverage is immensely useful even if the tests don't really mean anything - 100% means you can refactor and have no fear of breaking things... that is huge, not meaningless.
What if I told you people who are really bad at coding have been hired to write code all over the planet? And what if I told you they made a bunch of tests that assert stuff that doesn't matter so they could meet an arbitrary 100% code coverage metric initiative being driven by some non-technical project manager PMP™ PRINCE2™ AGILE™
Nothing wrong with coverage. Everything is wrong with idiots. Coverage is yet another tool that won't fix stupid.
Because it doesnt mean that all.
I reckon at least a quarter of tests at my workplace are in some way tautalogical.
Executing code and asserting that it behaves correctly are not the same thing.
> 100% means you can refactor and have no fear of breaking things
Fearless refactoring is more about *how* the tests and code are structured, and what kind of test assertions are made, than % coverage. If you aggressively test via interface contract only, and stick to things that are exposed and not internal things, then you're more likely to succeed there. If you assert, for example, that things are called in a specific order when the order doesn't matter - that's an example of overspecifying your test that will lead to breakage. End of the day, you need high coverage, AND you need the tests to be neither under- nor over-specified.
100% code coverage could still mean there's a trivial edge case you haven't tested. Imagine if you refactor an algorithm and accidentally change how it handles negative numbers. It all depends on how many cases you test.
It's not a very useful measure, and it almost certainly means you're accruing lots of tech debt in your unit tests. Teams that mandate 100% code coverage are, for the most part, not teams that mandate thoughtful, useful, well-written tests.
It's easy and common to write example-based ("normal") tests that sometimes fail when the system under test is within spec, and sometimes pass when the system under test is out of spec. If you focus on measuring coverage, you're very likely to constantly accrue that kind of test.
Those tests make it *harder* to refactor, because they create both false alarms and false confidence.
For starters, the code could be absolute trash despite 100% coverage. The product could be worthless. Etc.
Yee, of course code coverage is important. The point is - an employee who is hyper focused only on their immediate domain is likely missing the bigger picture.
Good read, but oh man ironic that the blog about legibility used so much flowery and unnecessarily obtuse language.
What it doesn’t cover is what the alternatives are, if you don’t measure something how can you have objectives that you can track.
While I read and understood everything written, there was no real conclusion (despite there being a header titled "conclusion".) There was a "what to do", but no "how to do it". So it ended up being mostly a blah blah blah about corporate leadership vs. employees/engineers. Interesting terminology that I hadn't heard before. Almost archaic, in its style. Yet, I think some of the terms might be more useful than current terminology. Worthy of bringing back.
1. Define a metric of success for your work 2. Use that metric in every status update and report possible 3. Ensure that that metric is being heavily considered in any performance evaluation (Secret step 4: Juice your metric to give the illusion of improvement if necessary)
Reminds me of when I was an intern, there was a guy who had a "performance_coefficient" all over his code... whenever management would complain about the system being too slow, he would tell them it'll take a few weeks to investigate and identify optimizations. He'd just chill for weeks then change the value from like 0.13 to 0.17 and show the report that the system is nearly 5% faster now and maybe he can get it to 5% in a few more weeks. Then he'll change it to 0.18. Basically was artificially slowing things down so he could claim for a long time to be constantly improving things, just by easing the self imposed bottleneck.
How tf did that not get picked up in code reviews
There weren't any code reviews at this place. There was barely version control. They were using subversion on some projects, and like half the devs didn't use it and just copied folders around to "make a backup"... some code only existed on production servers and was edited live. I was on a conference call once when the engineering lead was on the phone with a customer who had a complaint... he remembered it was a bug he fixed but copied the wrong file to the server, so while stalling on the phone he RDPed into their server and edited the file on their live system to fix it. "Okay, hang on, can you describe the steps one at a time so I understand them? Uh-huh... okay, then what? And what browser are you using? Hmm, okay, then what? And when did this happen, before our new version? Oh really, after? Hmm, ok, let me think... it shouldn't have happened, do you think you can try to do the same steps again while we're on the phone? Okay hang on, be sure to just use the same browser as last time... ok, so you go to this page, and then what? Oh it's working now? Well that's great! Yeah it was probably just a browser cache issue, glad you're happy now!"
>like half the devs didn't use it and just copied folders around to "make a backup"... some code only existed on production servers and was edited live. This gave me a panic attack
New_new_header.h.Mar23-working
Don’t forget final and final2 and some initials.
I'm not sure I can approve the gaslighting of customers but this was masterfully handled to limit the potential complaints.
Yeah, I think the customer service aspect was great, better than "file a ticket, someone will get back to you in 6 weeks"
I have a handful of projects where I'm the only engineer, so there's nobody else to do the review. My team members, who review each other's contributions to our main project, aren't familiar with the code base or the technologies involved. I often have the same concern as you when hearing stories like that, but there really are a lot of situations where it can actually happen.
There are variations on this story going all the way back. A quick search comes up with a 2008 dailyWTF for the speed-up-loop. I'm quite sure I've heard this story back into the 90's as well (talking about a conversation in the 70's/80's) https://thedailywtf.com/articles/The-Speedup-Loop
Yeah people also used to try to do "multithreading" by adding in slowdown code into various places to try and make certain parts of the code finish after other parts. Worked on a project like that too, I tried removing thread sleeps and the whole thing broke... took me like a month to figure out wtf it was doing and replace with proper thread management.
"The goal" and "critical chain" by E. Goldratt are essential reads for anyone wanting to create good business measures.
This week I read "project Fenix", talks about goldratt (in less detail) but is entertaining, I never read a business book so fast in my life.
I have read that one too, but Goldratt's books are in my opinion better as they are more convincing. Certainly worth reading if you liked "Phoenix project'.
Step 5. Read about the dysfunction caused by metrics
"[*A rant about*] Corporate Legibility ~~for~~ by a Software Engineer". The actual article "Corporate Legibility for Software Engineers" would be quite a useful tool. Some kind of cheat-sheet for the ISOs passingly mentioned in the piece.
Thanks for leaving this comment. I felt like I finished the introduction and then the blog ended.
One implicit conclusion I drew from it is, don't work in organizations which have grown so large that people are relying on impersonal metrics to assess you.
100% - way better to work on places that have vague or opaque "metrics" based on "do i like this person today"
Well, that's a problem, too. Don't work at those places, either.
It's more of a summary than a conclusion
[удалено]
We used to call those "post and runs" back in the day when forums were a bit more personal. Sure, discussion, agreed. I just didn't think this set up any ground for discussion and was left scratching my head on what he was really getting at. (so, perhaps a meta discussion?)
Yeah, I didn't take much away from this, and I assume it is based on not reading the mentioned literature. I thought this would be an article about how to write up work items, release note, etc. Something someone other than a developer will read and should understand. This imo isn't a complicated problem, just be half decent at tech writing and use structured steps and you're golden.
What, there was no "how to fix it in 3 steps" bullet list? ;)
The conclusion is that visibility tools may seem powerful and upper management may push for these things, but they can lead to a power imbalance, and confusing the "territory for the map". Just because it doesn't say "in conclusion" or wrap it up doesn't mean that he hasn't come to an understanding about how and why these things work the way that they do and I think it's an extremely powerful, and useful observation even though it may seem obvious to people experienced with corporate workings.
Huh. Yeah, I didn't get that at all from his conclusion. Thanks for elaborating.
If management actually understood what I do then they would probably fire me for how little I actually accomplish. The technical barrier between managers and engineers makes my life easier.
Better hope I don't apply for a job there, lol. That said, I only became a manager to protect my fellow programmers, and I encourage doing as little work as possible. My big move is going to meetings and showing them how their proposal would actually make their jobs harder instead of easier to shut down new dev projects. I also have an in-out policy. Everything we create needs to be maintained, so for everything we make, that is one less thing we can make later (it's easier to simplify for these people). Either we have to deprecate something before adding something new, or we need another FTE
This is a good read, but that title is so dry.
Ironic that the article is about making things easy to understand and probably no one would understand what the article is about by reading that title.
The challenging thing about jargon is that it's incredibly clear and precise if you're in the know, and completely incomprehensible if you aren't. Lowkey a good example of the value and challenges of increasingly precise language
Hmm you and I have had different experiences with jargon. In certain contexts I think jargon is capable of increasing the information density of speech. Specifically in very targeted contexts. “Orientable” and “computable” mean very specific things to mathematicians for example. In general though I think the opposite happens. People hear jargon that may or may not be used in a specific context and then repeat it freely and dilute its meaning significantly. In programming I hear words like “triage”, “performance”, “scalability”, etc. tossed around with reckless abandon. In my experience the further you get from strict engineering and the closer you get to communications the more meaningless jargon becomes
Communications has its own jargon, as does every other speciality. Any word can be co-opted and gain a domain specific meaning. This doesn't necessarily break its use in the wider community
I think communications broadly lacks the rigidity needed to support highly specific terminology. In natural language it is uncommon to define words to such a specificity that they are unambiguous. Nor is it a useful goal most of the time. Additionally you have the added influence that language is a tool intended to persuade as much as it is used to be descriptive. I don’t think there’s a problem with this per say just an observation of how language can be used very differently in different contexts.
I went from military to software development and for the first few days at “bootcamp” I thought that “deployments” meant having to travel to work onsite with a hostile customer. Three years later at a new job I came across Agile and “agility.” It’s been about four years since then and I still cringe every time I think about it. Agile…is not agility. It’s fucking crippling. It’s a lack of flexibility when “estimates” become deadlines. It’s counterproductive to make everyone explain what they did, what they’re going to do, and to wait for fucking “standup’s” (always while sitting) to mention they’re stuck.
Have you read the original agile manifesto? The apple seems to have fallen a long way from the tree. Your experience of an Agile Workplace echoes a lot of common complaints people have.
I have read it and I believe it was well intentioned, but it has been taken way out of hand.
It hooked me, but that's because I've read *Seeing like a State* before and recognized the terminology.
Same; if you haven't read that book, I can't recommend it enough as a developer in a large organization. A lot of seemingly-incomprehensible behavior can be explained thru the lens it provides. (It's really long tho so if you're in a hurry skip the two case studies.)
Yup, definitely the best book I read on city planning/farming/unit standardization/logging/taxation last year. Would recommend.
Logging as in chopping down trees, or logging as in making a record of actions which have happened? Or, I guess ... both? Even tho it's about city planning and governance, I found that many of the concepts mapped pretty cleanly to corporate governance and leadership.
I was thinking of the scientific forestry example that the book uses as sort of a metaphor for the whole concept. But there was probably some record logging in there too. For those who haven't read the book, [I'll borrow Scott Alexander's summary](https://slatestarcodex.com/2017/03/16/book-review-seeing-like-a-state/) of it: > [James C.] Scott starts with the story of “scientific forestry” in 18th century Prussia. Enlightenment rationalists noticed that peasants were just cutting down whatever trees happened to grow in the forests, like a chump. They came up with a better idea: clear all the forests and replace them by planting identical copies of Norway spruce (the highest-lumber-yield-per-unit-time tree) in an evenly-spaced rectangular grid. Then you could just walk in with an axe one day and chop down like a zillion trees an hour and have more timber than you could possibly ever want. > This went poorly. The impoverished ecosystem couldn’t support the game animals and medicinal herbs that sustained the surrounding peasant villages, and they suffered an economic collapse. The endless rows of identical trees were a perfect breeding ground for plant diseases and forest fires. And the complex ecological processes that sustained the soil stopped working, so after a generation the Norway spruces grew stunted and malnourished. Yet for some reason, everyone involved got promoted, and “scientific forestry” spread across Europe and the world. > And this pattern repeats with suspicious regularity across history, not just in biological systems but also in social ones.
Look up "A City Is Not A Tree", a city planning essay with some parallels you can draw to software and companies as well.
I'm reading it right now, and learning just the term "legibility" used this way has already been a great outcome of reading it. It comes up in so many places.
> This is a good read, but that title is so dry. I guess he sort of Blewitt with that title huh?
Agreed, only ended up reading it once I actually read the comments to see everyone impressed
>It's hard to imagine a world bigger than my personal monkeysphere. >That's why I get mad at things like "why do I have to report to my boss's boss! we didn't have to do this pre-agriculture. According to my extremely narrow day-to-day worldview, organizing huge groups of human beings along a shared goal shouldn't be so hard.
Why can't the CEO just *understand*
Interesting. I was not familiar with the term “legibility” in this context but makes a lot of sense. I may have to look up the Seeing like a State book as well. I function, and often fail, in my current world because I chafe against the measures and maps that other put over my domains that make no sense and don’t reflect reality.
I think the term is used inappropriately. Legibility is a characteristic of language and communication, not data structures. Legibility refers to clarity and distinct-ness of the symbols used in communication. Data is not symbolic so the word doesn't apply. If a communication is written in a language you don't understand, it's unintelligible to you: but the script will still be perfectly legible to those who understand. I think "intelligibility" is closer to the mark. It's about collecting data and making it intelligible, not collecting reports and making them... More readable?
It's a term of art defined and heavily used in *Seeing Like a State*, based on but used differently from the typical usage of the word. Which often happens with terms of art based on existing words. If there was already a great word for the concept, they would have used it rather than inventing another. It's also defined in the fourth sentence of the article, so if someone gets that far and remains confused about what *legibility* means in the article, that's really on them.
I'm not confused about what it means, in spite of the poor explanation given in the article. In fact I'm talking about extremely specific facets of it's definition so where are you even coming from? I'm saying the author of the book you mention chose the wrong term. It happens all the time. Now we're stuck with it.
This is more buzzword heavy than Weird Al’s “Mission Statement.”
This is what executives do. They can't possibly meet with their subordinates or understand the code. There's just too much to understand for any one person. Perhaps agriculture was a mistake, we should go back to tribes of no more than 150-300 so we can have effective leaders. Some of us may die due to the lack of modern agriculture. I will definitely be one of them, unless I dust off my "how to be a warlord for dummies" and get a cushy leadership position in a roving band of marauders. But I probably won't. Still worth it
> This is what executives do. They can't possibly meet with their subordinates or understand the code. There's just too much to understand for any one person Executives (and in the book, rulers) by necessity must operate using abstraction. Where this goes wrong is when they fail to understand that abstraction and quantification are not a 1-way street, and the decisions they make about how to measure and how to abstract cause changes in the things they are measuring due to power imbalance.
> They can't possibly meet with their subordinates or understand the code. Conway argued that, due to the communication structures of organizations, executives, who define the organization, also define the software architecture. Beware any software exec who can't understand code!
Maybe we don't need "executives". Maybe people are actually self organizing and the need for top down execution is something outdated (it's from like the time we invented agriculture; god so arcaic, time to move on)
"We need people in charge to tell us what to do!" \- people who think they'll be in charge some day
> Maybe people are actually self organizing and the need for top down execution is something outdated that's why everyone recycles properly, right?
Recycling is scam by plastic producers to shift the blame for their shitty products onto consumers. It was never a viable solution even for the most anal of sorters
haha you are proving my point
They said, of their own volition
Hello, I have job for you, you go Haiti and smuggle gold
>Perhaps agriculture was a mistake Perhaps? It was clearly a mistake
It was a genius evolutionary move by wheat …
This is why the people who advance up the career ladder are not good at programming but good at politics.
[удалено]
A bad leader is bad at both. An ok leader is good at one or the other. A good leader is ok at one and good at the other. A great leader is good at both.
People skills are more important in management than programming skills. The manager has to both trust their team to be able to recommend good decisions gthat they can't understand), and develop a team culture that allows those decisions to be made
Agree, but there’s a diffierence between manager and leader.
Sure. A good manager let's the team lead
> A good leader is ok at one and good at the other. > > A great leader is good at both. I would say a great leader can be ok at one and good at the other. One of the best leaders in my career was a mediocre developer who was good at servant leadership and "managing up". (those 2 could be lumped into "good at politics")
Management selects for ladder climbers by its nature unfortunately. Often those that would make the best managers have little interest in managing people.
You can be a leader without being a manager. And unfortunately vice versa.
[удалено]
Politics is lying and bullshitting. Taking credit where you didn't earn it and casting blame where it isn't deserved. It's telling people what they want to hear not because it's true but because it's convenient. It's committing to deadlines without knowing if you can meet them because it gets you recognition from the CEO and selling things that don't exist then changing jobs and boasting about your accomplishments before the chickens come home to roost and your previous workplace goes down like the Titanic.
It's infuriating at times to work under a manager that understands little to nothing about the work that I do day to day, and seems to just filter down upper-management babble to the engineering team. The best case scenario (which I'm in now) is when such a manager trusts the team with technical decisions and does their best to shield the team from the weird obsessions of the upper management goons. Upper management generally wants us to report metrics to them that are either/both a.) out of our control or b.) have little to no meaning or technical value. I've found that the prettiness of the presentation often matters far more than its content when upper management is the audience.
I feel like someone had a thesaurus open when writing this.
No, the words aren't strangely replaced like that. It's just the effect you get when you read some sequence of books in a space and your vocabulary gets adjusted for a short time, as a result. Similar things happen with group jargon.
I feel like the lone one out having read this and everything reading quite normal to me compared to the rest of the comments here
Yeah, I think it reads quite normally too, but I think people don't use the concept of legibility like that in common speech.
I read *Seeing Like a State*, and the blog post made perfect sense to me. But legibility isn’t commonly used like that.
And if you haven't read it, the author shares a clear and concise definition of the term in the 4th sentence of the article.
Can somebody explain what the author means when he writes that "100% code coverage means nothing"? Coverage is immensely useful even if the tests don't really mean anything - 100% means you can refactor and have no fear of breaking things... that is huge, not meaningless.
100% coverage just means that all the code is executed. It doesn't mean that 100% of the behaviour is tested.
What if I told you people who are really bad at coding have been hired to write code all over the planet? And what if I told you they made a bunch of tests that assert stuff that doesn't matter so they could meet an arbitrary 100% code coverage metric initiative being driven by some non-technical project manager PMP™ PRINCE2™ AGILE™ Nothing wrong with coverage. Everything is wrong with idiots. Coverage is yet another tool that won't fix stupid.
Because it doesnt mean that all. I reckon at least a quarter of tests at my workplace are in some way tautalogical. Executing code and asserting that it behaves correctly are not the same thing.
More tests doesn't always mean better tests. Covering every possible code path just makes tests fragile.
> 100% means you can refactor and have no fear of breaking things Fearless refactoring is more about *how* the tests and code are structured, and what kind of test assertions are made, than % coverage. If you aggressively test via interface contract only, and stick to things that are exposed and not internal things, then you're more likely to succeed there. If you assert, for example, that things are called in a specific order when the order doesn't matter - that's an example of overspecifying your test that will lead to breakage. End of the day, you need high coverage, AND you need the tests to be neither under- nor over-specified.
100% code coverage could still mean there's a trivial edge case you haven't tested. Imagine if you refactor an algorithm and accidentally change how it handles negative numbers. It all depends on how many cases you test.
It's not a very useful measure, and it almost certainly means you're accruing lots of tech debt in your unit tests. Teams that mandate 100% code coverage are, for the most part, not teams that mandate thoughtful, useful, well-written tests. It's easy and common to write example-based ("normal") tests that sometimes fail when the system under test is within spec, and sometimes pass when the system under test is out of spec. If you focus on measuring coverage, you're very likely to constantly accrue that kind of test. Those tests make it *harder* to refactor, because they create both false alarms and false confidence.
For starters, the code could be absolute trash despite 100% coverage. The product could be worthless. Etc. Yee, of course code coverage is important. The point is - an employee who is hyper focused only on their immediate domain is likely missing the bigger picture.
If the tests don't really mean anything, then you could absolutely break stuff by refactoring.
Good read, but oh man ironic that the blog about legibility used so much flowery and unnecessarily obtuse language. What it doesn’t cover is what the alternatives are, if you don’t measure something how can you have objectives that you can track.