>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?
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..."
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).
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?
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?
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?
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.
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..."
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.
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.
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.
>This has been debated to death on guitar forums, but some would argue that digital is now undistinguishable from the tubes.
I find that it's impossible for the average listener to identify the difference in recorded music, especially if there's a lot of distortion in play, but I can entertain the idea that it's a detectable difference.
As someone who moved from solid-state and digital amps to tube amps I find there to be a huge difference in terms of dynamics and response, which massively influences the way I and others play. I can't imagine Jeff Beck or Gary Moore getting the same results with non-tube amps, since their playing relies so much on dynamics and physically feeling and moving air in the room.
edit: for live touring, though, it's so much more efficient to use digital or solid-state options for size, weight and reliability, if it doesn't directly impact the artist's ability to perform
>I don't think I can name a single one known to play solid state amps.
Dimebag Darrell and Buckethead are two names who come to mind, favouring the even response of solid state over the more-dynamic valve amps.
If we include pre-amplification such as guitar pedals, solid state is everywhere - a DS1 or a Rat gives that even response for big gnarly cold distortions.
Then there's the Boss HM pedal which spawned a whole genre of it's own when players used it as a pre-amp for that unique "chainsaw" sound.
So, you're right that most players opt for valves at the amplification stage, but solid state is all over guitar music.
This downvoting is ridiculous, your comment is entirely reasonable, objective as can be, and should serve as a starting point (for those already versed in Rubin's career and careerism) for this entire debate.
The engineers invovled would certainly be responsible for this, Rubin himself has little-to-no technical ability or involvement with the actual process of creating music, instead he provides commentary, veto, and direction towards a high-level objective for the product being produced.
But, he almost-certainly was the guy who told Slayer "yeah... that... playing really fast and loud, all the time... keep doing that..." and we all owe him for that!
I think this is truly is Rubin's defining contribution and achievement: the industry leaders had an appetite to expand the hip-hop market to the mainstream and, judging by the general low-effort nature of the "Walk this Way" mashup, I can only assume almost any ol' crap would have gotten the airtime and juice to get over the top.
But Rick himself was the guy who could broker these deals with the artists', not some older label suit, but a guy who presented himself more as an artist and collaborator. A guy like that is huge value for stakeholders looking to steer the consumer towards a new product or a cultural trend.
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?