You just need to work on one project built by someone that implemented Uncle Bob recommendations blindly when the books came out to know how much they are worth. There were some low hanging fruits to pick at the time regarding trying to be better at software engineering and he generated some text about them.
Full of terrible advices, he never wrote anything significant (in scope and notoriety) during his time as a software engineer like many other prominent authors at the beginning of the agile era. The success is only the result of a wave of junior devs searching for some sort of guidance, something that there is a never-ending need for.
Horrible recommendations that produced a lot of code that is a pain to work on with the abundant amount of indirection it has. Really painful guys.
> The success is only the result of a wave of junior devs searching for some sort of guidance, something that there is a never-ending need for.
The issue is that, some never grown out of it.
I interviewed with companies where they give the book to any new intern/junior.
Then, during the hiring process, they don't even ask if you read it, they straight up ask questions about your knowledge of it.
Like "What does Uncle Bob says about X in his book Clean Code?".
And they constantly refers to it.
Some people go as far as quoting it in PR.
The worst part being that once they leave their company, since they don't know anything else, they'll apply the same stuff elsewhere & convert their new company to it.
It's important to note that Kent Beck is not one of those people, as he shipped the first unit testing library, as well as a bunch of ones in other languages later.
Like, I personally prefer the bare assert style of testing (like pytest), but the junit style is basically everywhere now.
Kent Beck is just as bad as Uncle Bob! He drank his own proverbial Kool-Aid and went all in on the crazy XP programming fad he started (... which contains brilliance like requiring pair programming for every line of code written).
Look, both authors are very smart people who have great insights into development that we can all learn from ... but both also have the failing of being way too in love with their own ideas.
It blinds them to the flaws in those ideas, and makes it so when you read their work you have to be skeptical and evaluate each individual idea on their own.
to come up with and advocate for paired programming before the concept existed _is_ pretty brilliant. And you also don't understand how much those practices improved software engineering, presumably because when you started programming they were already entrenched ideas, and so all you see are their shortcomings.
Those ideas do have flaws, and most of us are looking to improve how we right code. So if you aren't blind to those flaws, please, write a book or a blog or whatever on the best ways to write software so that we can all learn.
Force it on people, you'll see how much it works. Getting another pair of eyes on the code that you wrote is useful, but it's not free (effort, tolerance) and it's not for everyone. Just do proper code reviews. Middle ground.
IME code reviews are a bullshit half-measure that ends up as the worst of all worlds. It's tragic that so many companies settle on them as a compromise position.
> Getting another pair of eyes on the code that you wrote is useful, but it's not free (effort, tolerance) and it's not for everyone.
Yeah, but to be fair I would argue that in the limit, real code reviews end up looking a lot like pair programming, and you can avoid a bunch of back and forth by both people being present during development.
Obviously you still need code review (for regulatory reasons in a lot of cases), but the amount of times I've ended up on a Zoom talking through mine and others PRs makes me believe that pair programming would help here.
> and you can avoid a bunch of back and forth by both people being present during development.
I don't like pair programming for personal and cultural reasons (eg: I am uncomfortable with the _process_, but not the results), but the people in the pro-pair-programming camp will say the quoted bit above is one of its strengths. You back/forth and fix or change things early in the process.
Doing a code review is "too late", since these early decisions that could have been made differently/better effect all the code that follows it into a further less-optimal space.
Thanks for the correction, my opinion on the lack of credentials is that in the early days you just didn't need them to become popular, so little content that no one checked. I bit like it's happening nowadays with the anime profile pic twitter accounts acting like they invented AI, with zero code or achievements being shown.
The main issue with all of these files is that there is quite a bit of boilerplate code, but that's Java's fault, not the code's fault.
I'm sorry, but I disagree. Looking for the most substantial pieces of code that I could find, and they look really good. I'm sure there are some little utils or something that look strange out of context, but I would be thrilled if I were called to work on legacy code and it was this nice.
If I win the lottery, I don't want a building named after me I want to donate a copy of that book to every university computer science[1] student and make it required reading
1: I'm aware it's a software engineering book, but since there are very few B.S. Software Engineering programs out there, You Know What I Mean ™
Clean code, design patterns etc. were also picked up by teachers, professors and course instructors.
I think these paradigms and patterns often operate on the wrong layer of abstraction, while mostly ignoring the things that matter the most, like efficiency, error handling and debugging.
But getting good at these things requires a lot more blood, sweat and tears, so there's no easily teachable recipe for that.
Clean Code is trying to operate at a layer far more important than efficiency: code maintenance. In the vast majority of cases computers are fast enough that you don't need to worry about efficiency. (part of this is any modern language provides all the common algorithms that are already highly optimized and easier to use than the writing them by hand and so the common places where you would want to worry are already efficient).
Of course error handling and debugging are part of maintenance. However there is a lot more than those two that need to be considered as well.
There is reason to hate Clean Code, but the worst adherents to the rules are still producing far better code than some of the impossible stuff that happened before. "Goto considered harmful" is one of the early steps in fixing all the bad things programmers used to do (and some still do), but you can follow the "rules" of goto considered harmful and still produce really bad code so we need more.
From personal experience, the most time consuming maintenance issues arise because of the following things:
- third party dependencies, compatibility issues, breaking changes
- code that is bloated with abstractions and indirection
- performance issues, especially when worked around via caching etc.
- bad error handling
- inconsistent data
Simpler code that can be followed and stepped through in a straight forward manner avoids 3/5 of these from the get go. Patterns and abstractions that emerge over time are sometimes beneficial. Legacy code or third party code that overuses abstractions is really more of a hindrance and significantly slows down how fast I can understand, own and fix things.
IME the most time consuming maintenance issues are due to inconsistent code, which is usually a result of trying to avoid "abstractions and indirection" and keep it straightforward. A bunch of classes that just call each other is annoying, but trying to solve that by inlining the code results in something worse.
I agree. But here are other ways of accretion of code inconsistencies:
- Premature abstractions that are subsequently worked around around the edges.
- Automation built on top of wishful thinking instead of how people actually prefer to work.
- Inconsistent naming and file structure.
- Adopting many advanced or hyperspecific styles and techniques instead of leaning on more basic ones that already solve a problem.
I find it way easier, to go from more primitive, consistent, "inlined" code to more sophisticated abstractions that clearly solve emergent problems at a later point in time, than changing the direction of already factored, high level code.
To me it's a matter of mental capacity and friction as well. This stuff is hard, time consuming and requires deliberate effort. I rather accept that code goes through different phases of maturity and that using and maintaining the actual programs over time, gives me a much clearer path forward than applying patterns and principles in advance on an abstract level.
A caveat here is that many of these inconsistency factors come from adopting third party dependencies. In my experience this is the largest chunk of liability or tech debt.
---
However, a large factor that is often overlooked in these discussions, is also organizational scale. When you have to own and understand things from A-Z you can get away with different things than if you are one part of a much larger team and vice versa.
I'm firmly in the former category, so I have to optimize for being able to take a much larger slice of responsibility. But I can also get away with leaving code in a more raw state for longer. I assume this balance looks different the more people you add to a project or organization.
I think we need to take this into consideration in these public discussions. It's ultimately a trade off and programmers from different backgrounds will have different sensibilities.
> I find it way easier, to go from more primitive, consistent, "inlined" code to more sophisticated abstractions that clearly solve emergent problems at a later point in time, than changing the direction of already factored, high level code.
Depends. If you reach the codebase at the point where it's already accumulated subtle differences between codepaths that should be the same, that's far harder than inlining and rearranging something that's been factored badly, IME.
> A caveat here is that many of these inconsistency factors come from adopting third party dependencies.
I find the exact opposite. Developing too much internally creates a lot of inconsistency. If you hit an incompatible change in a third party dependency, odds are a lot of other people have hit the same thing and can tell you what to do.
Full of terrible advices, he never wrote anything significant (in scope and notoriety) during his time as a software engineer like many other prominent authors at the beginning of the agile era. The success is only the result of a wave of junior devs searching for some sort of guidance, something that there is a never-ending need for.
Horrible recommendations that produced a lot of code that is a pain to work on with the abundant amount of indirection it has. Really painful guys.