Hacker News new | ask | show | jobs
by pkoird 1289 days ago
So I asked this same question to ChatGPT, here's its response. This thing really does have the potential to be a good recommendation tool for books/resources.

"Here are a few books that may be helpful for improving your skills as a software engineer:

"The Pragmatic Programmer" by Andrew Hunt and David Thomas: This book offers practical advice on a wide range of topics, including how to write clean and maintainable code, how to work effectively with others, and how to manage your time and priorities.

"Clean Code" by Robert C. Martin: This book focuses on the importance of writing code that is easy to read and understand, and provides specific guidance on how to write clean and maintainable code.

"Peopleware" by Tom DeMarco and Timothy Lister: This book discusses the human side of software development, including how to create effective teams and work environments, and how to avoid common pitfalls such as overwork and burnout.

"Agile Software Development" by Alistair Cockburn: This book provides an introduction to agile software development methodologies, which are designed to help teams deliver high-quality software quickly and efficiently.

In addition to these books, there are many excellent blog posts and online resources on these topics. Some websites that may be helpful include the Pragmatic Programmer blog, the Agile Alliance website, and the ACM SIGSOFT Software Engineering Notes journal.

Another helpful resource may be attending conferences and workshops on software engineering and related topics. These can provide opportunities to learn from experts in the field, network with other professionals, and stay up to date on the latest trends and best practices. Many conferences and workshops also offer certification programs, which can be a valuable way to demonstrate your knowledge and expertise to potential employers. Some well-known conferences in the software engineering field include the ACM SIGSOFT International Symposium on the Foundations of Software Engineering (FSE), the ACM SIGCHI Conference on Human-Computer Interaction (CHI), and the International Conference on Software Engineering (ICSE). "

4 comments

And yet, the first two explicitly fail the criteria of the OP.

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.

This answer scares me. Wow
It shouldn't. The fact that it recommended Clean Code goes to show it's literally aggregating a bunch of books that are commonly recommended. Clean Code is really not the way you want people writing code, especially judging by the code examples in the last half of the book.
Can you expand on why you feel that way? A few people I respect have told me they got a lot out of it, so I'm curious to hear what you think is wrong with it.
IMO, the advice is all over the place. Sometimes it's good or almost, but often obvious or accepted (maybe a sign of the times?). Sometimes it's bad or ambiguous. If you can make that call, you are likely experienced enough to not need it. If not, how would you know what to follow, and what to ignore?

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

There's A LOT I could write about Robert Martin and Clean Code, but in short:

- 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 <<spaghetti code>> 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.

Right? This thing is more eloquent with its words than I am with my own.
I aim to ignore this advice and spend the next year figuring out how to leverage LLMs to become a more productive software engineer. Unfortunately there's no books on it yet.
Maybe you could do the experiments and write the book.
Yep, it has recommendations for every single subject!
How did you get that?

Any attempt I do at recommendations or summaries of books is met with a cookie cutter response that it can not do recommendations because it can't access the internet.

Just hit try again. It very often says it can’t do something, then does it on the next try.
How do you go about asking it a question like this? I would like to ask it for recommendations in other genres LOL.