Ask HN: Reading material on how to be a better software engineer?

The ACM has some interesting work, but is often impractical in day-to-day practice, unless your day-to-day involves constructing databases or researching generative algorithms (for example).

Rather than seeing this as great I see it as... superficial.

There's also a shocking lack of evidence that applying "clean" code rules actually leads to, well, "better" code (more maintainable, or even just more readable). In fact, in some cases, the rules kinda clash.

So in the best case, you read it, think about it, and maybe pick up one or two new things. In the worst case, it leads to pointless zealotry that can be quite toxic, especially when forced onto other people.

In short, save your money. Clean code is a grift, like many self-help books. You do have to give to Uncle Bob, he recognised that in a gold rush it's better to sell shovels (as the saying goes).

This has been linked elsewhere already, but is a better critique than I could do in a comment: https://qntm.org/clean

> Of Ants and Dinosaurs by Liu Cixin

> The Unix O'Reilly Guide

All quick entertaining reads. All written by software engineers. All utterly useless for managing state in your React apps.

- focused on the readability of small functions rather than the readability of the whole program. This gives you unreadable programs containing lots of small readable blocks of code. I argue this is wrong. We care about programs first and foremost.

- arbitrary rules ("ideal function should have zero arguments", "functions should be two to fours lines long"). He hasn't run studies, he hasn't provided any proofs. Nothing scientific, it's just some guy's opinions.

- his code examples speak for themselves, in a bad way. Check out the link posted in a sibling comment. They show a person who's trying to put their ideas in code for the first time (or, at the very least, first time trying to write non-trivial code) and it's becoming obvious that those ideas don't work. But the person persists and publishes the book regardless.

- he hasn't really achieved anything in software apart from selling books and consultancy services. Name one impressive piece of software that he wrote, like a version control system, or a database, or a high performance JSON parser. All he's done is (as far as I can tell) CRUD software. That's not even enough for an "appeal to authority" argument.

In the words of a classic, Robert Martin is a "self-appointed expert". I would be very skeptical about following his advice.

> A few people I respect have told me they got a lot out of it

I don't mean to offend you. If I had to guess, these people you respect work on trivial software, just like me or Robert Martin. It's software you can write using almost any ideas or methodology. It doesn't matter what you use, because the task is so simple. Read data from a frontend, write to a DB, read from a DB, send back to frontend. You can do this using assembly x86, Fortran, OOP (whichever flavour), FP, whatever P.

So when people say "they got a lot out of it", I take it this means "I do things a lot like Robert Martin (as opposed to a mythical idea of > that's meant to make the code unmaintainable), and it seems to work; I deliver features and I get paid". And that's fine, I guess. You can make your life harder by following Robert Martin's advice and still achieve your goal.

The problems begin when you need to start writing "real" code (rather than CRUD/plumbing), like anything that's supposed to have good performance, or actual CS problems like TSP, path finding, and so on. Robert Martin proved he can't write a readable prime number generator even when performance is not an issue.

My advice is to keep respecting the people you respect but focus on the CS and mathematics fundamentals instead. IMO there's little to nothing in Clean Code that will make you a better developer.

Except for the Bob Martin one, which you just shouldn’t read since he is not good at programming and his advice is bad.