I am glad the author meant the book Clean Code and not the concept.

Clean Code - Robert Martin. <-- this is without a doubt the number one book to read in my opinion

Working With Legacy Code - Michael Feathers

I'm reading Clean Code at the moment.
I don't agree with everything.
I think it would be a mistake to take it on it's every recommendation.

TLDR: Author recommends "A Philosophy of Software Design" over "Clean Code"

Building a Career in Software is a good one I read recently.

Did not finish Clean Code yet but enjoying it so far too.

Yep, read these books and apply the ideas directly to your work as you go: Code Complete (which IMO is more detailed and explanatory than Clean Code) then Clean Architecture.

Clean Code is not a blind religion, Uncle Bob is trying to make a point with the concepts behind the book and teaching you to consider/question if you're falling into bad code traps.

This book was written to make developers think and consider their choices, not a script for good code.

Disagree. There are zillions of worse books than Clean Code to forget first.

What are notable books nowadays? It seems all the books I can cite are from 2005-2010 (Clean Code, JCIP, even the Lean Startup or Tribal Leadership…) but did the market for legendary books vanish in favor of Youtube tutorials? I’m running out of materials I can give to my interns to gobble knowledge into them in bulk.

I never read Clean Code and know nothing about its author so I'm willing to trust you on the first part, but the second paragraph is really uncalled for IMO. The article is long and gives precise examples of its issues with the book. Assuming an ulterior motive is unwarranted.

Yeah, single responsibility principle is the key takeaway from that book. Clean Code is a must for all programmers and I can recommend it as a prequel to CA. It's written by the same author after all.

I have a feeling the OP is looking for a book about software development in a broad sense.

I understand that the people that follow Clean Code religiously are annoying, but the author seems to be doing the same thing in reverse: because some advice is nuanced or doesn't apply all the time then we should stop recommending the book and forget it altogether.

Under-substantiated?! The guy was one of the signers of the original Agile Manifesto, and think what you will about big-A "Agile", the manifesto itself was a revolution in our industry, It may not seem that way now, but only because of how thourgly the ideas of the manifesto have been integrated into our culture. Then he wrote his whole Clean Code series which are generally considered necessary reading for any junior developer. Then after that he's basically been the senior dev at 8th light, which is both a highly successful consultancy and an excellent example of a company creating a structured mentorship program for new developers.

So yeah, feel free to disagree with Uncle Bob, but in no way is he "under-substantiated.

It's directly from the article, and Clean Code was one of the first books I purchased.

Fixed the typo, thanks.

Reading the first ten chapters of Clean Code takes no more than 3 days yet so many programmers fail to do so. There is literary no other way to improve your coding skills and habits that fast.

I am interested in reading books about software development and best practices like Clean Code and The Pragmatic Programmer [0]. I have coded for about eight years, but I would like to do it better. I would like to know your opinion about [0], since Clean Code has been significantly criticized.

[0] https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2...

Honestly Clean Code probably isn't worth recommending anymore. We've taken the good bits and absorbed it into best practice. I think it has been usurped by books like "Software Engineering at Google" and "Building Secure and Reliable Systems".

I don't believe in being prescriptive to anyone about how they write their code, because I think people have different preferences and forcing someone to write small functions when they tend to write large functions well is a unique form of torture. Just leave people alone and let them do their job!

I don't think it is the perfect solution, but a lot of people assert "we can't do better, no point in trying, just write whatever you feel like" and I think that is a degenerate attitude. We CAN find better ways to construct and organize our code, and I don't think we should stop trying because people don't want to update their pull requests.

Robert Martin and his aura always struck me as odd. In part because of how revered he always was at organizations I worked. Senior developers would use his work to end arguments, and many code reviews discussions would be judged by how closely they adhere to Clean Code.

Of course reading Clean Code left me more confused than enlightened due precisely to what he presents as good examples of Code. The author of the article really does hit the nail on the head about Martin's code style - it's borderline unreadable a lot of times.

Who the f. even is Robert Martin?! What has he built? As far as I am able to see he is famous and revered because he is famous and revered.

The Pragmatic Programmer, Refactoring (I'm rereading it after many years with the 2018 edition, opinion not totally formed on this one), Working Effectively With Legacy Code, A Philosophy of Software Design. It's been a long time since I've read Clean Code, I don't quite get the hate from the other thread here today so I'm rereading it now. I figure it'll take me a couple days and worst case I'll agree with the criticism and stop recommending it.

I think one should always be careful not to throw out the baby with the bathwater[0].

Do I force myself to follow every single crazy rule in Clean Code? Heck no. Some of them I don't agree with. But do I find myself to be a better coder because of what I learned from Bob Martin? Heck yes. Most of the points he makes are insightful and I apply them daily in my job.

Being a professional means learning from many sources and knowing that there's something to learn from each of them- and some things to ignore from each of them. It means trying the things the book recommends, and judging the results yourself.

So I'm going to keep recommending Clean Code to new developers, in the hopes that they can learn the good bits, and learn to ignore the bad bits. Because so far, I haven't found a book with more good bits (from my perspective) and fewer bad bits (from my perspective).

[0]https://en.wikipedia.org/wiki/Don%27t_throw_the_baby_out_wit...

I’d say “Stop recommending Clean Code to noobs! It’s dangerous”

Because Clean Code is really a good book once you have enough experience to understand when each idea works and when does not. And why.

And noobs tend to over-engineer, so any book like CC or design patterns give them additional excuse and reason to over engineer and make a mess.

But the problem isn't so much because the book has a mix of good and bad recommendations. We as an evolutionary race have been pretty good at selectively filtering out bad recommendations over the long term.

The problem is that Uncle Bob has a delusional cult following (that he deliberately cultivated), which takes everything he says at face value, and are willing to drown out any dissenting voices with a non-stop barrage of bullshit platitudes.

There are plenty of ideas in Clean Code that are great, and there are plenty that are terrible...but the religiosity of adherence to it prevents of from separating the two.

Aren’t the first 3 or 4 chapters basically what you can find in Google’s own cloud toturials?

Why does the domain-driven-design chapter come after you’ve tied the reader into GCP? I can’t think of a single enterprise business domain where that would make sense from a European GDPR driven perspective.

Why do you think you can cover that many topics in a single book? I mean, part of the reason Clean Code is well liked is because it covers one topic in depth, rather than covering a bunch of different topics without ever giving the reader anything of value on any of them.

Have you considered going the TDD GOAT book route of earning sales?

I’m really sorry that I’m so negative, but your “contents” read like every terrible tech-book I’ve ever opened. Good luck though.

> these things are literally what the Clean Code book advocates for

I'm not sure I understand what you're saying, I might be missing your point. The Clean Code book advocates that the ideal function is a single digit number of lines, double digits at the absolute most.

In my mind, the entire process of writing functions that short involves abstracting almost everything your code does. It involves passing data around all over the place and attaching state to objects that get constructed over multiple methods.

How do you create a low-abstraction, bottom-up codebase when every coroutine you need to write is getting turned into dozens of separate functions? I think this is showcased in the code examples that the article author critiques from Clean Code. They're littered with side effects and state mutations. This stuff looks like it would be a nightmare to maintain, because it's over-abstracted.

Martin is writing one-line functions whose entire purpose is to call exactly one other function passing in a boolean. I don't even know if I would call that top-down programming, it feels like critiquing that kind of code or calling it characteristic of their writing style is almost unfair to top-down programmers.

Eric Evans' Domain-Driven Design. I've heard enough about DDD over the years that I figured I'd just go to the source. Liking it so far, I have some good takeaways but we'll see how effectively I'm able to use the ideas over the next couple years.

Martin Kleppmann's Designing Data-Intensive Applications. Based on the frequent praise it receives here, haven't gotten far yet. I have some project ideas (for personal and professional projects) that could benefit from reading through it.

Martin Fowler's 2018 update to Refactoring. I read the original one a long time ago. In context, we have a work lunch & learn series and I'm interested in doing some presentations on the topic of refactoring (why, how, and when in particular) so it seemed appropriate to refresh my memory on some specific terminology from the book as well as to see if it's an appropriate book to recommend to colleagues. My recollection of the first edition is that I'd recommend it to colleagues, but it's been so long I'd rather read it once more before actually recommending it.

I reread Robert C. Martin's Clean Code based on some recent discussion here where it was rather strongly dismissed by a fair number of people. I didn't recall it being bad, my reread confirmed it is not, in fact, bad. Java-heavy, which is now an unpopular style of OOP, but otherwise a very good book. I'd still recommend it to junior colleagues paired with some caveats about avoiding seeing the world in black & white. There is no singular Way of Programming, but learn various ways and find what works for you and your team.

There are some more, but it's almost 5am and I haven't been able to sleep so I don't recall everything that's in the book stack or ebook queue. These are the ones I'm most interested in at present.

So, in your opinion are Clean Code and Clean Architecture still relevant/updated?
I've come more interested in the way I think about/produce code in the last couple of months and am searching for something that might be a good read on it - considering I'm mainly a JavaScript developer.
I find that most of the concepts of SOLID, for example, are really hard to figure out in most of the code base of the projects I've worked/see online implemented in Node for example. It might be related to my lack of knowledge and understanding of said principles though, but I've seen a youtube video (https://www.youtube.com/watch?v=CnailTcJV_U) some months ago that showed me a "clean architecture" implementation that I've never really seen in any project I've fiddled with.

I often hear that people should read Clean Code and that it is necessary in large projects. I would say that there is no direct correlation between how large and complex the business logic is and the difficulty of understanding and maintaining the code. I have seen small simple applications that are not maintainable because people have followed SOLID to the extreme.

There has been plenty said about the topic. Have you read Clean Code? The Wikipedia page? The Pragmatic Programmer? The depth on the subject has been expanded far more than just “single responsibility”.

Here is Bob responding to OPs link: http://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Releva...

Stating:

“SRP) The Single Responsibility Principle.

Gather together the things that change for the same reasons. Separate things that change for different reasons.”

That’s a pretty clear delineation IMO.

Hey there! As someone with just half the years of experience you have... I'm just gonna leave my one cent here :-)

Clean Code is an excellent book to start going in the direction of what I'd consider "good programmer", in the sense that a good programmer writes code for humans, not for computers!

My opinion of "good programming" is just exactly that, the code is easy to read, easy to glance and figure out at a high level what it is doing.

About OOP, there are a ton of opinions regarding that (I kinda dislike it...) so don't really fret about it, a good programmer writes code that humans can easily read, that human being future you also, since a week later we often have no clue what our code does and need to read it again anyways!

Something that I've been enjoying a lot lately is investing in my tools, which for me right now is learning to use neovim, and even thought I'm not using it professionally (I think I'll never will because that might convert it into "work" and suck all the fun out of it) it has made a huge difference in my side, projects, you know, the code that I'm actually excited about!

I sympathize with you since I didn't took formal programming courses and most of the felt like I was not good, or not up to par with other or whatever... seems like my engineering manager and the previous raises disagree with me! So, don't confuse impostor syndrome with "not good"

As a last thing, I recently came across a couple of articles here in HN regarding building useless stuff[0] and homebrew tools[1], and in doing so I've been finding the joy and fun I used to have back when I was just learning!

So bottom line, don't worry about being good and focus on having fun/enjoying what you do!

[0]https://news.ycombinator.com/item?id=27256867
[1]https://news.ycombinator.com/item?id=27482397

Hey, these are good questions.

> Aren’t the first 3 or 4 chapters basically what you can find in Google’s own cloud toturials?
> Why does the domain-driven-design chapter come after you’ve tied the reader into GCP? I can’t think of a single enterprise business domain where that would make sense from a European GDPR driven perspective.

Our idea was to create a seemingly modern app based on microservices, with full GCP setup and fancy tools used. We then go on to point the issues in the code. We wanted to show how an app that seems well built on surface can have hidden problems that are hard to spot. We don't deep dive into GCP, mostly just describe the setup.

> Why do you think you can cover that many topics in a single book? I mean, part of the reason Clean Code is well liked is because it covers one topic in depth, rather than covering a bunch of different topics without ever giving the reader anything of value on any of them.

I believe you'll find a lot of value on these topics, even if we don't go super-deep into each of them. It should give readers enough ideas on how to approach building complex apps. We base this on our experience, so it's not just bland descriptions of the patterns. Also it's all focused on Go and on a real example project, so it's not abstract.

I bought this book off the back of the referenced discussion trashing Clean Code. Whilst Clean Code has its problems, well articulated in that previous discussion, I am loathe to recommend this book. A large part of it is dedicated to commenting practices and seems a bit out of touch with the way software is developed today. There were some rather dubious claims on TDD as well, suggesting that it aims to 'get features working, rather than finding the best design' which seems to completely ignore the refactoring phase practised in a TDD cycle. A choice quote about comments that I strongly disagreed with: "without comments, you cannot hide complexity". The book also strongly advocates for large classes and considers small ones an anti-pattern called 'classitis'.

I'd say half the book contained good advice, the other half was mediocre or dubious at best.

I'm curious to hear what others think who've read both books.

Now this is usually in my opinion not a good advice (it is like reintroduction of global variables) as unnecessary state certainly makes things more difficult to reason about.

I have read the book (not very recently) and I do not recall this but perhaps I am just immune to such advice.

I like his book about refactoring more than Clean Code but it introduced me to some good principles like SOLID (a good mnemonic), so I found it somewhat useful.

You should expect some pushback on your pull requests, particularly early on. It’s a good opportunity to learn, and a good sign that your team cares about code quality and continuous improvement.

You mention bugs specifically, for which I think the best remedies are good unit tests and careful consideration of edge cases (which often go hand in hand). Other smaller issues such as deviation from framework conventions and performance problems can be helped by getting to know your languages, frameworks and database better, which comes with time. More generally, there are lots of good resources out there to help you improve the readability and structure of your code - Clean Code by Robert Martin (particularly the earlier chapters) and Sandi Metz’s books and talks are both good starting points. Issues with your general approach to solving problems are harder to address, but reviewing others’ code, learning about design patterns and pair programming can all help here.

In terms of actionable advice, I’d encourage you to briefly discuss your intended approach to a problem with a colleague before starting work: this can help expose issues in advance. Even better, pair program on the implementation with another engineer. Just pairing on the review can also help to reduce the back and forth and get code shipped faster.

There's a word, in other comments, that I expected to find: zealots. Zealots aren't sufficiently critical, and they don't want to think for themselves; a reasonable person should be able to, and a professional should be constantly itching to, step back, look at code, and decide whether some refactoring or rewriting is an improvement, taking a book like Clean Code as a source of general principles and good examples, not of rules.

All the "bad" examples discussed in the article are rather context dependent, representing uninspired examples or extreme tastes in the book rather than bad or obsolete ideas.

Shredding medium length meaningful operations into many very small and quite ad hoc functions can reduce redundancy at the expense of readability, which might or might not be an improvement; a little DSL that looks silly if used in a couple of test cases can be readable and efficient if more extensive usage makes it familiar; a function with boolean arguments can be an accretion of special cases, mature for refactoring or a respectable way to organize otherwise repetitive code.

Great, but that's not the reason why obvious comments are bad. They are bad because it's not maintainable. For you this means that the next time a developer refactors the code, you need to check if the comment is still accurate with the refactored intentions. I repeat, this is not maintainable! I love how the book Clean Code described it: "A comment is a failure to express yourself in code." There are situation they are useful, but those are definitely not obvious comments.

Highly recommend starting with "The Pragmatic Programmer". I found "Clean Code" to be much more narrow in its applicability (and I did not enjoy Martin's writing, but that's highly subjective).

The Pragmatic Programmer serves as inspiration for me every time I read it. I know everything in it, but somehow I always come away with at least one "I could totally be solving my current problem with this!" insight from a re-reading.

I’ve read both books. I consider Ousterhout’s to be one of the better recent books on software development, though as mentioned in my other comment, this is more because of the earlier content than the later chapters. I have been critical of Clean Code since before it was cool and I actively recommend against junior developers reading it.

I would have liked to see Ousterhout make a more thorough argument if he was going to criticise TDD. His central criticism — that TDD results in what he calls tactical programming, prioritising the implementation of specific features over good design — is certainly defensible. However, I think he was too superficial in what he actually wrote on the TDD section, and consequently I don’t think he made a particularly convincing connection with the ideas developed earlier in the book.

I think you’re slightly unfairly misrepresenting his position on large or small classes. He makes a solid case that what he calls deep modules are better for managing complexity than shallow ones. He also identifies a correlation with size because small modules tend to be shallow. That’s not the same as arguing for large classes or against small classes just because of their size, though.

It sounds to me like you haven't internalized a lot of the advice in the first half of "Clean Code" and/or the entirety of "The Pragmatic Programmer". Either of those books takes a few weeks to read slowly and a few months-to-years of deliberate practice to internalize and synthesize as your own. The good news is that admitting you have a problem is the first step.

Personally I find I still frequently write pretty atrocious code on the first draft, and it's only by stepping back from the problem after demonstrating to myself I understand it well enough to solve it at all that I can begin to write a more graceful solution. But deadlines and reality being what they are, I think the majority of us are embarrassed by our past code a majority of the time.

So don't be too hard on yourself, but also frankly don't worry about shoe-horning yourself into "A Career" either. They're kind of a recent invention and the whole concept might need a few more iterations. You could spend a few years as a Product Manager, an Engineering Manager, a Highschool Teacher, or a Business Analyst, leveraging your past experience to gain competency in a new niche.

I want to emphasize of self-awareness you have is commendable and not universally present: If you can realistically assess your own current skill level and then apply yourself to improving, you could be an above average software engineer before you know it. And right now it seems like so so many companies just can't get enough software engineers, so it's a pretty safe place to practice learning how to learn while also earning a decent income.

I'm completely with you here. Until I read Clean Code, I could never really figure out why my personal projects were so unreadable a year later but the code I read at work was so much better even though it was 8 years old. Sure, I probably took things too far for a while and made my functions too small, or my classes too small, or was too nitpicky on code reviews. But I started to actually think about where I should break a function. I realized that a good name could eliminate almost all the comments I had been writing before, leaving only comments that were actually needed. And as I learned how to break down my code, I was forced to learn how to use my IDE to navigate around. All of a sudden new files weren't a big deal, and that opened up a whole new set of changes that I could start making.

I see a lot of people in here acting like all the advice in Clean Code is obviously true or obviously false, and they claim to know how to write a better book. But, like you, I will continue to recommend Clean Code to new developers on my team. It's the fastest way (that I've found so far, though I see other suggestions in the comments here) to get someone to transition from writing "homework code" (that never has to be revisited) to writing maintainable code. Obviously, there are bad parts of Clean Code, but if that new dev is on my team, I'll talk through why certain parts are less useful than others.

Syntopic reading can be really rewarding. For example, once you read Thinking Fast and Slow, and a few of Taleb’s books, suddenly you notice implicit and explicit references in virtually every business book published later than those.

A similar effect can be found with Grit, Fogg’s Behavior Model, Superforecasting, and most Gladwel books.

On the coding side, I’ve only noticed this with Pragmatic Programmer, Clean Code, and maybe Phoenix/Unicorn project. Could I don’t read enough of those or they’re too focused on specific technologies instead of broad ideas … or I get too much of my technical reading from blogs and twitter. Those do get repetitive and you quickly find common patterns, but no titles to refer to.

Are there any specific aspects you'd like to improve around your code?

A few classics that focus on improving "general code style" would be:

- "Clean Code" (https://www.oreilly.com/library/view/clean-code-a/9780136083...)

- "The Pragmatic Programmer" (https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2...)

EDIT: Since you are talking about coding like at a top company, one book that has been sitting on my shelf for a while, but I haven't gotten around to reading yet is "Software Engineering at Google: Lessons Learned from Programming Over Time" (https://learning.oreilly.com/library/view/software-engineeri...)

I read Clean Code in 2010 and trying out and applying some of the principles really helped to make my code more maintainable.
Now over 10 years later I have come to realize that you cannot set up too many rules on how to structure and write code. It is like forcing all authors to apply the same writing style or all artists to draw their paintings with the exact same technique.
With that analogy in mind, I think that one of the biggest contributors to messy code is having a lot of developers, all with different preferences, working in the same code base. Just imagine having 100 different writers trying to write a book, this is the challenge we are trying to address.

Here's my rant on Code Complete and Clean Code:

I find that these two books are in many recommended lists, but I found them entirely unforgettable, entirely too long, and without any "meat."

So much of the advice given is trivial things you'll just figure out in the first few months of coding professionally.
Code for more than a week and you'll figure out how to name classes, how to use variables, how scope works, etc.
The code examples are only in C++, Java, and Visual Basic (ha!). Completely ignoring non-OO and dynamic languages.
Some of the advice is just bad (like prefixing global variables with g_) or incredibly outdated (like, "avoid goto"? Thanks 1968!).

Work on a single software project, or any problem ever, and you'll know that you need to define the problem first. It's not exactly sage advice.

These are cherry-picked examples, but overall Code Complete manages to be too large, go into too specific detail in some areas, while giving vague advice in others.

All books are written in a time and a few become timeless. Software books have an especially short half-life. I think Code Complete was a book Software Engineering needed in 2004, but has since dropped in value.

I will say, that Code Complete does have utility as a way to prop up your monitor for increased ergonomics, which is something you should never ignore.

I have similar issues with Clean Code. One is better off just googling "SOLID Principles" and then just programming using small interfaces more often and use fewer subclasses.

A better alternative is (from above) The Pragmatic Programmer (2019), a good style guide, and/or get your code reviewed by literally anyone.