Live data from Hacker News

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

news.ycombinator.com

71–80 of 127 posts

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

#71

Wondering what people's opinion on the _Domain Driven Design_ book is.

It's a nice system but far too complicated for the world we live in, where most tech companies, especially banks, are filled with imported labor or outsourced globally.

DDD requires a certain discipline and dedication I just haven't seen in my career across many companies.

Good luck getting more than a handful of people to not only digest the big books but also structure all their code and company around practicing it.

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

#72

Earlier quoted context omitted.

I went on a long email back and forth with the author because this was the one book that opened my eyes so much that I did't know why the Ruby community (of which I was a part of then, but am no longer) would break so many of the principles of the book. Maybe the only book that has actual made me a better programmer that I can objectively measure.

Would you mind clarifying which one you found so helpful? The parent commenter mentioned two books

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 levels of function calls to get anything done. That makes things really complected together and makes it hard to reason about later.

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

#73

Earlier quoted context omitted.

I went on a long email back and forth with the author because this was the one book that opened my eyes so much that I did't know why the Ruby community (of which I was a part of then, but am no longer) would break so many of the principles of the book. Maybe the only book that has actual made me a better programmer that I can objectively measure.

Can you say more about how the ruby community is breaking these principles? Was that part of the reason you left the community?

So around the TDD phase of Rails and Ruby, there was this huge push to make methods 5 lines or really short and dependency inject everything. It would make changes incredible hard to make because which the open closed principle talks about how things like this should be easy to change, you end up with a lot of subtle bugs because your individual dependencies drift from each other. I think the Ruby community has gotten much better now with more experience but ya that time it was crazy. And Ruby allows you to really take the metaprogramming and block passing madness to the next level.

I didn't leave the community because of it. I left it because Ruby was slow as molasses, dynamic typing is a failed experiment (imo) and people would love magic and be proud of it. Which meant systems would break in production more times than I could take and I have done so many on call rotations because someone thought some magic was a fun way of doing it.

For personal projects I used Steel Bank Common Lisp because there the dynamic nature of the language actually has benefits such as programming through the REPL which is much more reliable than typing dynamic code in an editor to build programs.

Once I had to hire people I moved to Go but then again moved to Rust because I want to write programs which do not break, is fast as possible and doesn't take my users' memory and cpu for granted. Who am I to burn their electric bill or data plan while delivering broken buggy software to them. Plus I cannot stand null pointer exceptions and Go due to their ideological drive of remaining "simple" has null pointer exceptions in 2024.

Also the other meta thing I realized was because Rust is harder to get into, the discourse, libraries, tutorials, community is much higher quality compared to anything else I have seen so far so I really enjoy it. Plus Rust has some really cool things like high level maps and functional code while them compiling down to the same Assembly as for loops and other such zero cost abstractions that I like.

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

#75
I have what might be considered an unpopular opinion here. What you’ve read already is more than enough. And most of the books that are recommended here are going to be a massive waste of time over what you’ve already read. What you’ll be better off doing is read code available in your domain of interest.

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

#77

Earlier quoted context omitted.

Can you say more about how the ruby community is breaking these principles? Was that part of the reason you left the community?

So around the TDD phase of Rails and Ruby, there was this huge push to make methods 5 lines or really short and dependency inject everything. It would make changes incredible hard to make because which the open closed principle talks about how things like this should be easy to change, you end up with a lot of subtle bugs because your individual dependencies drift from each other. I think the Ruby community has gotte…

Funny, I spent the last decade working in a strongly typed natively compiled language (OCaml) and for fun I’m venturing into Ruby more and more, so kinda opposite of what you did :)

I’d agree that I wouldn’t like to support a large Ruby codebase commercially but in team of 1-4 devs and codebase not much larger than 10k lines it’s very productive (numbers pulled from thin air ofc).

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

#79

Earlier quoted context omitted.

Would you mind clarifying which one you found so helpful? The parent commenter mentioned two books

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?
Post reply on HN