Live data from Hacker News

Ask HN: What books should I read to improve as a software engineer?

news.ycombinator.com

81–90 of 127 posts

Re: Ask HN: What books should I read to improve as a software engineer?

#82

"A Philosophy of Software Design" by Stanford's John Ousterhout is excellent. It is quite concise (about 190 pages), but in my opinion, it includes all the essential information that the other books in that category would teach you. It leaves out a lot of cruft that over the years turned out to be non-issues (code styling, problems that come with object oriented programming, etc.) but occasionally - when the topic is…

If you want something a bit more elaborate: "The Pragmatic Programmer" has a 20th Anniversary Edition. It is a timeless classic, worth reading at any rate.

I haven't read the original The Pragmatic Programmer, but picked up the 20th Anniversary Edition. Maybe it's because the original was so influential, but I didn't enjoy the 20th Anniversary Edition at all, it just full of boring platitudes.

Re: Ask HN: What books should I read to improve as a software engineer?

#83

Earlier quoted context omitted.

You sort of have to marinate yourself in the ideas of the book. But the big one is that you should have a very limited API. And each API function should do a lot of things. So a very narrow set of deep APIs make for the best programs. The other thing was indirection. Try avoiding it as much as possible. Languages which allow easy access to functions or lambdas or blocks being pass around, usually end up with 4 - 5 le…

and which book are you talking about?

Deep APIs were mentioned in "A Philosophy of Software Design" (John Ousterhout)

Re: Ask HN: What books should I read to improve as a software engineer?

#85
post #17

Earlier quoted context omitted.

I keep seeing this online. Why? Clean Code was instrumental in my improvement as an engineer. Is there a reason why this is the opinion nowadays?

I also love Clean Code and think it unfairly gets a bad rap, but here's a great, sometimes hostile, conversation with the author that touches on the issues: https://github.com/unclebob/cmuratori-discussion/blob/main/c... The linked video is also a good watch.

Thank you for posting that!

Just for context, this was posted to Github by the author of Clean Code himself, Robert C. Martin, while exchanging messages with Casey Muratory [0]. They talk about performance, about testing, and maybe other stuff (I'm at less than half of it)

[0] of Handmade Hero fame, https://www.youtube.com/watch?v=A2dxjOjWHxQ

Re: Ask HN: What books should I read to improve as a software engineer?

#86
post #17

It's probably useful to un-read Clean Code, though I don't really have a recommendation for a good replacement. The replacement is something like "Make a lot of mistakes and develop good taste based on your experience." If you're interested in performance, you can read https://algorithmica.org/ and https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

I keep seeing this online. Why? Clean Code was instrumental in my improvement as an engineer. Is there a reason why this is the opinion nowadays?

I think that some of the advice hasn't aged well into modern language features and computer power, similar to the GoF Design Patterns book. Rather than an entry level book, this would be better for a budding intermediate who can parse what is good and bad about it.

But, even then, other resources are better IMO. (Metz, Ousterhout, Kay, PragProg, language-specific design patterns books, etc.)

The experience of doing things wrong is valuable, but I think you also don't want to get quagmired there. It just depends on how voraciously/quickly you read and seek out better patterns.

(Also, elephant in the room, Uncle Bob has been very vocal and opinionated on the internet about various things and it hasn't endeared many to him because of it)

Re: Ask HN: What books should I read to improve as a software engineer?

#87
post #36

Earlier quoted context omitted.

it is not either or. You can do both. I'm sure a swimmer who reads books about swimming in addition to swimming is better all else being equal than a swimmer who just swims.

> who reads books about swimming Can you show me such a book? Ie a book that teaches one to swim (different strokes etc) aimed at a professional swimmer (athlete).

I think your point makes sense, but the comparison of programming to swimming loses the thread of thought a bit. Swimming is not my forte, but there are books by professional marathoners on how to train for marathons, for example, that are valuable to read for forming proper training plans as opposed to "just figuring it out".

I think your opinion on OSS/large codebases makes sense, but I don't think it's an either/or situation: reading should _support_ actual coding, similar to how studying a grammar textbook for a foreign language is there to support actually speaking/listening/communicating in that language.

Re: Ask HN: What books should I read to improve as a software engineer?

#89

Controversial take: reading books to get better at software is like reading books to get better at swimming. Like people don't get better at math by reading books about math... So you should go read code. But reading code is boring if you're not also writing code (same goes for math) so my real recommendation is to go find a big OSS project in an area you're interested in and start contributing. If you don't know how…

It's like reading books in order to get better at writing them... sure it kinda works but not really. You get better at SWE by building things!!

The field has a lot of gurus who trick newcomers into falacies like 'clean code' when, instead, they should be out there banging together rocks like a JavaScript caveman seeking fire (Lisps).

Re: Ask HN: What books should I read to improve as a software engineer?

#90
Here are the subjects where I see both beginner and experienced developers fail and yet what separates the children from the adults in the room. So read absolutely any (multiple) books on these subjects:

* measuring things (evidence gathering, performance, comparisons, stats, research). Most developers cannot do this on any level and yet have the balls (stupidity) to advocate so boldly for their opinions.

* data structures. There is a very old best practice: composition over inheritance. That advice runs far deeper than it sounds because all aspects of a good application should be interchangeable and extensible structures. That applies to both theory like functional programming as well as practical like interfaces, APIs, and data in transport.

* writing. Programming, in the brain, is no different than writing an essay in natural language. It requires executive planning, expression, organization, and refactoring. The better you get at writing prose, articles, and proposals the easier it gets to write the first draft of an original application. It’s so much more than just writing documentation and most programmers struggle with all of this.

* transmission. Read the protocol RFCs and attempt to write original implementations. Most programmers cannot do this and yet a deeper understanding of data in movement will provide capabilities you, and your competition, can never before imagine.

Post reply on HN