Live data from Hacker News

Books for Software Engineers in 2023

grantisom.com

111–120 of 127 posts

Re: Books for Software Engineers in 2023

#111
post #61

I see SICP listed on every list but I really feel its becoming Knuth-esque. I mean, I didn't learn through that specific book, but after going through it a couple of years ago I found that its kinda alright, but I don't really get this legendary status it has. I've also seen this opinion shared with many seasoned vets throughout my career, just feels overrated.

Maybe it depends on where you are in your journey when you came across it? For me, I came across it in the early 90s, as it was the first text for my CS class in college. I devoured it and it still holds a special place in my heart. If I read it for the time now, would it be the same? Possibly not. (To wit, I read _The Catcher in the Rye_ for the first time in my 40s. I found it "meh" but can understand how reading i…

Definitely, the journey is a meeting of inner state with exterior environment. I read Catcher in the Rye in my teens (but almost 50 years after first being published, in the 90s) and also found it meh.

Re: Books for Software Engineers in 2023

#112

I'd also read the books from Teach Yourself CS ( https://teachyourselfcs.com ): - Structure and Interpretation of Computer Programs - Computer Systems: A Programmer's Perspective - The Algorithm Design Manual - Mathematics for Computer Science - Operating Systems: Three Easy Pieces - Computer Networking: A Top-Down Approach - Readings in Database Systems - Crafting Interpreters - Designing Data-Intensive Applications…

A word of warning to anyone reading "The Algorithm Design Manual", there is an error on nearly every other page. https://www3.cs.stonybrook.edu/~skiena/algorist/book/errata https://www3.cs.stonybrook.edu/~skiena/algorist/book/errata-...

Can you recommend an alternative?

Re: Books for Software Engineers in 2023

#113

I recommend "Developer Hegemony". Coming from a career in FAANG, it's helped put words to what bothers me about the power dynamics and management practices. The book also presents a picture of what a healthier and more empowered "software engineering" role/world could look like (one of my 2023 goals is making significant career moves in that direction)

I really didn't like that book. The author has some good points, but they are already mostly discussed on his blog.

Meanwhile, much of the book is the author pretending to be an economic historian and talking (in a very shallow way) about medieval guilds or something.

Re: Books for Software Engineers in 2023

#114
post #84

Earlier quoted context omitted.

Well I'm guessing you haven't read the book yet. Basically all throughout the book(s), they authors use food names as variable, function names etc. It is indeed a nice idea because people do tend to associate good memories with delicious food. Especially if the food is greasy or sweet! That quote This space is reserved for Jelly Bean stains is basically a filler sentence at the end of a chapter on a page, which happe…

I'm not taking a position on whether or not the infantilism is appropriate, so whether or not I have read the book is neither here nor there. The previous commenter characterised the text as needlessly infantile. It seemed clear enough to me that they were referring to the jokes about jelly bean stains. I am confused why you interpreted their challenge as being about some approach to problem solving. > Its is possibl…

Yes, I was talking about the jelly bean stain stuff and the cartoons. I don’t see the point.

(I do also think the format of these books is pretentious and not actually that sound didactically, but that wasn’t what I was referring to when I said “infantilizing”.)

Re: Books for Software Engineers in 2023

#115

Earlier quoted context omitted.

How does the space reserved for jellybean stains guide the reader towards the desired problem-solving approach?

I've always seen a sense of humor as an essential component of problem solving. Stressy, serious, businesslike modes tend to get stuck in the weeds and miss the forest etc

It isn’t an essential part of problem solving. I think the fact that you think any technical material that isn’t humorous is automatically “stressy” may mostly say something about you… :\

For what it’s worth, I do have a sense of humor. Harvey Birdman is one of my favorite shows. The Sebben and Sebben employee orientation video is on another level.

Re: Books for Software Engineers in 2023

#116

Earlier quoted context omitted.

I've always seen a sense of humor as an essential component of problem solving. Stressy, serious, businesslike modes tend to get stuck in the weeds and miss the forest etc

It isn’t an essential part of problem solving. I think the fact that you think any technical material that isn’t humorous is automatically “stressy” may mostly say something about you… :\ For what it’s worth, I do have a sense of humor. Harvey Birdman is one of my favorite shows. The Sebben and Sebben employee orientation video is on another level.

I'm afraid I wasn't communicating effectively. I have no problem with non-humorous technical material - the parent comment asked

>How does the space reserved for jellybean stains guide the reader towards the desired problem-solving approach?

... and I was suggesting that perhaps the authors were using the medium as the message - I find that being relaxed helps with debugging, typically.

Re: Books for Software Engineers in 2023

#117
post #82
post #69

Earlier quoted context omitted.

Really great to see a mention of "Developer Hegemony" here. The author compares software engineers to doctors or lawyers. In a law firm, the partners call the shots and the rest of the staff is there to support them. In tech companies, the structure is inverted. The engineers are at the bottom of the power hierarchy, even though it's the engineers that generate the most value. The author suggests that developers shou…

I've recently read Developer Hegemony. While I agree with their critique of the status quo, I don't think their alternative approach works for software engineering in settings other than agency work for non-tech clients. Law firms are a way of organizing game animals. Two zebras have no need to compete over eating from the same patch of grass. One zebra just moves over by a few meters. There's enough grass for everyo…

Just a nit: as a dev turned lawyer, I would say law firms don't need to be organized as they are. That's a whole topic, and I don't think it impairs your main point, just saying: don't assume anything in law is optimal, balanced, or rational.

Re: Books for Software Engineers in 2023

#118
I wonder if it's time to prioritize newer books with mysterious titles such as "Transfer Learning for Natural Language Processing" over traditional SE books. I imagine this year we'll see some "Programming in chatGPT" ones too. Are we experiencing a revolution in code generation or is it mostly hype still?

Re: Books for Software Engineers in 2023

#119

I'd also read the books from Teach Yourself CS ( https://teachyourselfcs.com ): - Structure and Interpretation of Computer Programs - Computer Systems: A Programmer's Perspective - The Algorithm Design Manual - Mathematics for Computer Science - Operating Systems: Three Easy Pieces - Computer Networking: A Top-Down Approach - Readings in Database Systems - Crafting Interpreters - Designing Data-Intensive Applications…

If "Readings in Database Systems" is your cup of tea you should probably consider

* Database Internals (https://www.oreilly.com/library/view/database-internals/9781...) - very recent and of manageable size

* Database System Concepts (https://www.amazon.com/Database-Concepts-Abraham-Silberschat...) - specifically, the chapters on storage and query processing, it's a huge volume otherwise. Also, "Database Systems: The Complete Book" is basically an older version of it.

Re: Books for Software Engineers in 2023

#120
post #82
post #69

Earlier quoted context omitted.

Really great to see a mention of "Developer Hegemony" here. The author compares software engineers to doctors or lawyers. In a law firm, the partners call the shots and the rest of the staff is there to support them. In tech companies, the structure is inverted. The engineers are at the bottom of the power hierarchy, even though it's the engineers that generate the most value. The author suggests that developers shou…

I've recently read Developer Hegemony. While I agree with their critique of the status quo, I don't think their alternative approach works for software engineering in settings other than agency work for non-tech clients. Law firms are a way of organizing game animals. Two zebras have no need to compete over eating from the same patch of grass. One zebra just moves over by a few meters. There's enough grass for everyo…

If I understand you correctly, you're saying that lawyers are primarily solitary and software projects require a team? Do I have that right? Law firms still have a hierarchy: there are senior partners, junior partners, articling students, etc. From my lay understanding the business is still organized around "a lawyer" being the top of the food chain.

> Similarly, law firms are organized very differently from tech companies and it's a function of their products / markets / business models / stakeholders / general situations.

It's hard to disagree there, purely from a historical perspective. Google was started by a bunch of developers and it looks like a traditional corporation now with layers and layers of middle management. Perhaps this is the most efficient type of an organization for a large software maker. One interesting alternative are tech coops [0]:

> Worker-owned cooperatives are business enterprises that are owned and governed by their employees. All worker cooperatives have two common characteristics: 1) member-owners invest in and own the business together, and share the enterprise’s profits, and 2) decision-making is democratic, with each member having one vote.

[0]: https://github.com/hng/tech-coops

Post reply on HN