Those who know, know.
I should get to work on my opus, “Dirty Code”
Inside I’ll reveal all my secrets like: not writing tests, not documenting anything, putting the whole app into a single python file, object-disoriented relational mapping, obscure SQL tricks, unobscure no-sql tricks, and more!
object-disoriented
I’ll steal this to shit talk about code; until git blame points to my past self
Github, but it’s afraid of commitment, it just wants to spoon.
Just make sure the first chapter is dedicated to spaghetti, and contains various GOTO statements telling where the reader where to go shove it and other obscenities.
I like “how to build APIs you won’t hate”.
I read a book like this once! It was like, “how to code badly.”
It was actually kinda fun.
I’m of the opinion that Uncle Bob did some massive damage to software development as a whole with that book.
With that said, this is genuinely funny.Agreed. I found that many developers, in the pursuit of clean code, lost slight of some of the fundamentals principles of good code. I found that people were eschewing readability and modularity and calling it clean code.
Clean code became the target, not the underlying principles and the reason why we needed clean code in the first place. It became an entirely new thing that aided in producing some of the worst code I’ve read.
Oftentimes, when devs talk about “clean code” it’s a red flag for me in hiring. Some of the worst devs I’ve worked with have been clean code evangelists.
lol
New edition is just an incoherent rant about the “woke mind virus” trying to destroy him for “just saying what everyone is thinking”.
This! Uncle Bob is a garbage person. Used to really respect him, but F that guy.
I didn’t knew anything about him but I respect everyone who doesn’t shut up in front of the woke agenda and propaganda.
Dude fuck off
And what would you say is that “woke agenda and propaganda”?
“Code optimization is a cultural Marxist conspiracy!”
I’m a programmer since the 80s, who is this guy?
He wrote for example the books Clean Code and Clean Architecture which are IMO opinion really good books although I don’t agree with every point he makes.
Some really good points he makes are for example:
- Functions that only do one job
- Testing makes refactoring easier
- The standard SOLID OOP stuff.
- Tech debt is bad
- Abstraction and encapsulation is good and allows developers to interact with the code on a higher level in terms of actions instead of writing verbose stuff. Essentially saying less code leads to less bugs
- Insulate yourself from change
- Duplication is bad
- Two use cases that are very similar is not duplication and common code shouldn’t be factored out.
- Don’t mix high level code with low level.
- Build solid Entity classes to model the data and their interactions.
- Don’t write multithreaded code if you don’t have to.
- If you have to do your best to write it so they don’t share memory.
Those comes with examples. He’s a tad bit overly idealistic in my opinion. These books fail to mention a couple of things:
- Refactoring is expensive and the cost is often not justified.
- Premature abstraction is the absolute devil
- You don’t need to insulate from things that are very unlikely to change (like going from SQL to Document DB)
- Less changes also lead to less bugs.
- Too much emphasis on functions being few lines of code instead of just being simple.
All in all though, very solid books. I read Clean Code in university and Clean Architecture in my first job and it really helped me wrap my head around different ways to solve the same problem. Excellent ideas but it’s not the holy truth. The only reason I remember all of these points is that I encountered all of them on the job and saw the benefit.
In my opinion new programmers should read it and take inspiration. Craftsman level developers should criticise and maybe pick up a few brain concepts to sort some concepts out in their brain. Experts will get little benefit though.
The consultancy I used to work for in the late 90s would have crucified any developer that didn’t write “a data abstraction layer that allows you to pop off the original db and substitute a different one later”.
How many times in my 25 year career have I swapped out the database (and been thankful for such an abstraction layer)? 0 times.
I am literally in the middle of swapping DynamoDB for a RDBMS.
The idea that you can abstract away such fundamentally different data stores is silly. While I hate doing it now, reworking the code to use relational models properly makes for a better product later.
I’m going to suggest not using an ORM. I used three so far and it really likes to tell you what you can and can’t do when query builders can do the same thing by creating the SQL string for you. SQL is also very nice and easy (just parameterise all inputs to avoid the SQL injection)
While he advocates for it, that’s also a point that Martin brings up multiple times when he talks about his project “fitnesse”.
Basically saying that they left it open how stuff can be saved, but the need has never arisen to actually pivot to a different system.
I generally agree with the idea that code should be as simple as it can be to accomplish the goal of the code… I just haven’t been convinced that Clean Code is the way to get there, necessarily. The book does contain some good advice , to be sure, but I wouldn’t call it universal by any means.
I also think TDD is a very optimistic strategy that just doesn’t match up with reality terribly often.
Actually, I think that’s what confuses me the most about all of Uncle Bob’s books. I’ve read a couple of them and thought, “All this sounds great but real world development just doesn’t seem to work that way.” Like, all of his advice is for best case scenarios that I certainly haven’t encountered in my career.
I say confusing, because surely he’s been in the profession long enough to have seen the disconnect between what he’s preaching and real life, right???
Yeah, I 100% agree. For small projects most of the principles don’t matter as much because the complexity is just not there. For big projects you actually need to take a big ass tech debt loan to actually get things done on time and on budget.
The testing aspect I’m not as sold on either. I enjoy tests sometimes but they also come with increased development and maintenance cost. He emphasises unit tests but I’ve found that a few integration tests that use API calls to simulate a use case gets you most of the way there.
That being said I’ve seen raw HTML email string with hardcoded values in a 2000 line method that relies heavily on if statements. That one method probably breaks around 10 of his rules and I absolutely hate it. Very hard to add features to if you can imagine and incredibly noisy and hard to debug. Shouldn’t be like that but it is. I wouldn’t apply all of Bob’s rules but I would refactor it into a service with clear boundaries so I don’t have to deal with the function having “local globals” if you know what I’m getting at.
Wrote a couple famous books about Clean Code, Architecture, Test Driven Development, OOP, and Agile.
he’s a programmer since the 70s
Robert C. Martin
Your long lost son, perhaps
There’s a multi-part talk on YouTube if you want to hear all about it.
I was a big Uncle Bob fan and still really like the Clean Code book. But he trashed his public reputation so I doubt this 2nd edition will do very well.
Is there a TL;DR if I don’t know who this is?
Basically he is an old man/ software engineer who’s famous for his philosophy of coding.
I am also a big fan of his books, especially Clean Code. His (far-)right opinions are bad, but should be (to some extent) viewed separately from his technical standpoints. However, even then a new edition would not perform well, there are too many people hating Clean Code (without really understanding its message/just ranting without having read it). But I was very surprised that ThePrimeagen recently interviewed his “opponent”, it was very nice to watch.
Working in Ruby did 10x more to help me write clean code than reading Clean Code ever did.
Many of the lessons drilled into me with Ruby (keep a consistent style, tests are cheap, keep your methods relatively small where possible, reduce nesting where possible) carry over nicely into other languages without needing to go through any OO bullshit.
IMO, the best lesson around Clean Code is this: you’re not clever, write obvious code that works with as few tricks as possible.
I find this to be true for every new language I try out. Since every language has a different way of doing things and gives me a new perspective, in the long run they all end up improving my programming style as a whole. I always end up integrating the best parts of each into my next project when possible.
Experience will always be more valuable than any set of rules these kind of books tout as “the way things are meant to be done”.
oh no somebody stop please him
Ooh la la 😏
Cleaner Code.
Waiting for him to finish the trilogy with Cleanest Code
cleanerer code. gotta leave room for a fourth book: clean code and the crystal skull
Clean Code With a Vengeance.
Glad I didn’t read it.
There are no inherent “rules” in software development. These books are useless and a waste of time. They offer nothing but CS Dogma and are actually against freedom of expression.
CS often requires working in teams, and working it teams is often more efficient if you have some shared approaches.
There are no inherent “rules” to language, either, but when you don’t followthemthingsgetmessyandyou’reannoyingforeveryoneelese.
Those of you who red and liked clean code (I did too), what’s your next best recommendation as a book? The pragmatic programmer?
Is this a cute joke or is he being serious and oblivious?
Isn’t that the guy who caused the whole Factorio Kovarex controversy?
What kovarex controversy? Link? Context?
Don’t ask his opinions about the term “statutory rape”!
Yes. I never looked at kovarex the same since.
Thanks for the warning
He must have been waiting for me to buy a copy.
