That reference link is a wild ride of unqualified, cartoonish passive-aggression, the cute link to the author's "swag" is the icing on the cake.
Concidentally, I encountered the author's work for the first time only a couple of days ago as a podcast guest, he vouches for the "Dirty Code" approach while straw-manning Uncle Bob's general principles of balancing terseness/efficiency with ergonomics and readability (in most, but not all, cases).
Yes, I have read Uncle Bob. I could agree that the examples in the book leave room for improvement.
Meanwhile, the real-world application of these principles and trial-and-error, collectively within my industry, yields a more accurate picture of it's usefulness.
Even the most click-bait'y criticisms (such as the author I referenced above) involve zooming in on it's most-controversial aspects, in a vacuum, without addressing the core principles and how they're completely necessary for delivering software at scale, warranting it's status as a seminal work.
"...for the obedience of fools, and the guidance of wise men", indeed!
edit - it's the same arc as Agile has endured:
1. a good-faith argument for a better way of doing things is recognised and popularised.
2. It's abused and misused by bad actors/incompetents for years (who would not have done better using a different process)
3. Jaded/opportunistic talking heads tell us it's all garbage while simultaneously explaining that "well, it would be great if it wasn't applied poorly..."
>involve zooming in on it's most-controversial aspects, in a vacuum, without addressing the core principles and how they're completely necessary for delivering software at scale, warranting it's status as a seminal work.
It's not "zooming in" to point out that the first and second rules in Bob's work are "functions should be absurdly tiny, 4 lines or less" and that in the real world that results in unreadable garbage. This isn't digging through and looking for edge cases - all of the rules are fundamentally flawed.
Sure, if you summarize the whole book as "keep things small with a single purpose" that's not an awful message, but that's not the book. Other books have put that point better without all of the problems. The book is full of detailed specific instructions, and almost all of the specifics are garbage that causes more bad than good in the real world.
Clean Code has no nuance, only dogma, and that's a big problem (a point the second article I linked calls out and discusses in depth). There are some good practices in it, but basically all of its code is a mistake that is harmful to a new engineer to read.
>Sure, if you summarize the whole book as "keep things small with a single purpose" that's not an awful message, but that's not the book.
Assuming that you have read the book, I find it odd that you would consider that to be the steel-man a fan of this work would invent, it considers considerably more ground than that:
- Prioritise human-readability
- Use meaningful names
- Consistent formatting
- Quality comments
- Be DRY, stop copy-pasting
- Test
- SOLID
All aspects of programming, to this day, I routinely see done lazily and poorly. This rarely correlates with experience, and usually with aptitude.
>Clean Code has no nuance, only dogma, and that's a big problem (a point the second article I linked calls out and discusses in depth)
It's opinionated and takes it's line of reason to the Nth degree. We can all agree that the application of the rules require nuance and intelligence. The second article you linked is a lot more forgiving and pragmatic than your characterisation of the issue.
I would expect the entire industry to do a better job of picking apart and contextualising the work, after it made an impact on the industry, than the author himself could or ever will be capable of.
My main problem is the inanity of reactionary criticism which doesn't engage with the ideas. Is Clean Code responsible for a net negative effect on our profession, directly or indirectly? Are we correlating a negative trend in ability with the influence of this work? What exactly are "Dirty Code" mug salesmen proposing as an alternative; what are they even proposing as being the problem, other than the examples in CC are bad and it's easy to misapply it's principles?
>We can all agree that the application of the rules require nuance and intelligence
Except Uncle Bob, it seems, as evidenced by his code samples and his presentations in the years since that book came out. That's my objection. Many others have presented Bob's ideas better in the last 19 years. The book was good at the time, but we're a decade past when we should have stopped recommending it. Have folks go read Ousterhout instead - shorter, better, more durable.
When someone says to me "Can you pass me my tea?", my mind instantly builds a simulated model of the past, present, and future which takes a massive amount of information, going far beyond merely understanding the syntax and intent of the request:
>I am aware of the steaming mug on the table
>I instantly calculate that yes, in fact, I am capable of passing it
>I understand that it is an implied request
>I run a threat assessment
>I am running simulated fluid mechanics to predict the correct speed and momentum to use to avoid harm, visualising several failure conditions I want to avoid (if I'm focused and present)
>I am aware of the consequences of boiling water on skin (I am particularly averse to this because of an early childhood experience, an advantage in my career as a line cook)
>my hands are shaky so I decide to stabilise with my other hand, but I'll have to use the leathery tips of my guitar-playing left hand only, and not for too long, otherwise I'll be scalded
>(enumerable other simulated, predictive processes running in parallel, in the blink of an eye)
Very interesting, cognitive atrophy is a serious concern that is simply being handwaved away. Assuming the apparent trend of diminishing returns continues, and LLMs retain the same abilities and limitations we see today, there's a considerable chance that they will eventually achieve the same poor reputation as smartphones and "iPad kids". "Chewing gum for the mind".
Children increasingly speak in a dialect I can only describe as "YouTube voice", it's horrifying to imagine a generation of humans adopting any of the stereotypical properties of LLM reasoning and argumentation. The most insidious part is how the big player models react when one comes within range of a topic it considers unworthy or unsafe for discussion. The thought of humans being in any way conditioned to become such brick walls is frightening.
Apologies for repeating myself but this directly addresses a question I posed in a sub-comment: of the total population, at the time, what proportion were considered working class?
The reason being, class distinction would only count if non-working classes were very statistically significant. Having never examined this before, I'm having a hard time getting solid information, and it appears superfically that the class distinctions of today may not quite apply.
I'm operating under the hypothesis that the vast majority of the population would have been considered "working class", probably with a variety of sub-strata within (think hobo who occassionaly works vs. prosperous sustenance farm who's a pillar of the community).
Was there an excess of places in officer school for middle class+, or did they have to compete for their place? If they couldn't break in, was it socially acceptable to choose not to fight with the troops?
A lower standard would apply across the board, not only to the Irish. For your comment to make sense, forces would have to be majority Irish to begin with.
Otherwise, Irish are vastly overpresented for selfless and superior bravery on the field of battle.
No doubt that is true but it doesn't seem to account for the discrepancy, at least not without acquiring more data.
Google's LLM is spitting out ~250K immigrant and first-generation Irish fighting in the Civil War, sitting roughly at 10% of the total.
That doesn't account for second-generation and older, so I would be interested to see what social mobility was like for those more-established Irish-Americans: were they languishing in the working class, or did they exit from the middle class to go fight in wars disproportionately?
edit: how significant is the class factor, anyway? Does that model really apply, and how many citizens would be considered middle or upper class; enough to make a large statistical impact?
Yes, I made sure to highlight that this was the (unreliable) source, consider it an invitation for the history buffs to chime in.
Food for thought: if I had posted the very first source available on Google as authorative, with no actual knowledge of my own to make the claim, that could be more misleading on aggregate, right?
Agreed, it's not so much where you find the source, but the source itself. Unquestioningly taking "first result" is just as bad as taking anything from an LLM and representing it as a factual answer. Also, kagi generally has higher quality search results (that can be checked).
Also we're not talking about the proportion of the entire nation that was Irish, we're discussing the fighting-age lower class population of the Union side only.
This is a narrative I've heard many times, with very little evidence to back it up.
An alternative and more accurate view is that, as the world came online, people became exposed to the very low-effort scams, representative of criminal elements from around the world, which befuddled most due to their child-like naivety.
None of those confused individuals would fall for it but they require an explanation. Someone came up with a theory that it's actually a stroke of 4D genius and it stuck.
edit: ok, I bothered to look this up: Microsoft had a guy do a study on nigerian scams, the guys who wrote Freakonomics did a sequel referencing that study and drew absurb unfounded conclusions, which have been repeated over and over. Business as usual for the fig-leaf salesmen.
I would frame this slightly differently: managers care about delivery above all else, not necessarily productivity or efficiency.
Their goal is to attach their name to as many features/initatives as possible, owning the successes and orphaning failures, to impress their bosses. Another related goal is to have as many reports as possible. Delivery is relative to the average velocity: often, it's preferable to have a slow, inefficient operation so you can sandbag your bosses AND increase your headcount.
When it comes to improving processes and tools, managers prefer low-risk, iterative improvements which they can (somewhat) grasp. They also enjoy one-off prototypes and half-baked hacker projects which use new and shiny technology. Both categories make great fodder for PowerPoint presentations in front of shirts.
When it comes to larger, fundamental shifts which they cannot grok nor plausibly attach their name to, many managers will actively impede such efforts, as this risks upsetting the status quo which is (probably) working for them. The exceptions are usually the smart middle-managers looking to create a rising tide.
I've worked at a company that had dozens upon dozens of teams working on precisely the same problems (standard build->deploy->test->release fare), using many of the same tools, each with their own half-baked and poorly maintained configuration, plugins, dependencies, and custom libraries (sometimes, they even wrote a few tests!).
You can probably guess the majority of the proposal I put together, it's foundational stuff. It was presented and discussed among our senior+ engineers, and with managers.
>"You know... maybe there's value in letting teams be innovative..."
More precisely about benefit derived from the delivery. Best case scenario is the team is part of the benefit thinking but that is not a given. Also the layer above may engineer a situation where team and manager benefits from delivery are in conflict.
Distinction without difference: one would have to actually explain how surveillance is applied and leveraged differently across jurisdictions, allowing us to sub-divide into "good surveillance" and "bad surveillance", two different things.
Otherwise, we're talking about the inherit good-or-bad nature of surveillance as a whole and, thus, using the character of those applying it is irrelevant and contradictory.
The fact that many contradictory ideas are widely held or, at least, broadcast from the tallest proverbial hills, doesn't change the fact that they are contradictory. One thing all living generations seem to agree on is that politicians talk out of both sides of their mouth.
> one would have to actually explain how surveillance is applied and leveraged differently across jurisdictions, allowing us to sub-divide into "good surveillance" and "bad surveillance", two different things.
You mean like... having laws written down by elected leaders and then having judges who are accountable to the electorate to evaluate specific instances...?
I mean examples in-practice of such a system being used for anything other than mass surveillance of citizens which flouts their constitutional and human rights.
>having laws written down by elected leaders
The EU commission is not elected by public vote.
>judges who are accountable to the electorate
Judges are not elected by public vote.
edit: neither are the think tanks, NGOs, and array of well-paid experts who tend to both guide legislation and/or justify it to the public. This discussion can go in circles indefinitely as long as you continue to ignore reality and defer back to abstract principles and the _stated_ values & goals of the regime.
True, though there is much emphasis placed on the link between language and thought in the book. As the parent comment suggests, there is a lot of tacit differentiation-without-distinction when it comes to issues of privacy, censorship, and governance.
I guess double-think is nothing more than an extreme form of cognitive dissonance being accepted by the masses, the interesting part is how this achieve in the book. Again, language & propaganda come first, then information control, followed by swift and brutal violence for dissidents.
The following quote is taken from the CrowdStrike blog post linked in the article:
>Based on the testing performed before the initial deployment of the Template Type (on March 05, 2024), trust in the checks performed in the Content Validator, and previous successful IPC Template Instance deployments, these instances were deployed into production.
I'm having a difficult time identifying the bottom line. They describe the high-level makeup of their software's components, making several allusions to the breaking change being "stress tested".
Given that this update borks the OS immediately, I have to assume that this micro-update was NOT deployed to a Windows system during testing.
It's not clear if their Content Validator had a bug introduced during preparation and testing of this release, or if it was an existing, unknown issue.
I hope someone with a keener eye than myself can see through the noise and provide some clarity. I hope, for their company's sake, that internal discussions are far more concise and clear as to what the actual problem is.
Concidentally, I encountered the author's work for the first time only a couple of days ago as a podcast guest, he vouches for the "Dirty Code" approach while straw-manning Uncle Bob's general principles of balancing terseness/efficiency with ergonomics and readability (in most, but not all, cases).
I guess this stuff sells t-shirts and mugs /rant