31–40 of 127 posts
As a software engineer, staying up-to-date with the latest developments and best practices is essential for growth. One of my favorite (and what I feel is overlooked) methods for growth is reading books. We spend a large part of our day reading Stack Overflow...
Why did you repeat the first 1.5 sentences of the article?
> “Software Engineering at Google: Lessons Learned from Programming Over Time” Isn't Google's software engineering culture kind of a joke right now? I've spoken to multiple ex-Googlers and they tell me they leave because everything moves at a snail's pace. From the outside looking in, it seems like absolutely nothing is being done in Google and I would not want to replicate their engineering culture in any company. P…
Google's reality is basically not like any other company (except maybe 2-3).
Google's engineering culture, at least a few years back, was insanely good given that reality.
But you have to be pretty careful when you say things are a "must" since that's... pretty hard to prove (and can just make people feel bad). And the proof has already been pointed out as not true in this thread. Unless we all want to start evaluating eachother's programming ability virtually.
Again, lists and reading is great! And it's probably better to (try to) read any of these books than not.
But for the folks who try the books and can't get through them (like me and SICP), I'd say don't worry about it.
I have my own [0] list of books I think devs should read but I just try not to say "must read".
[0] https://notes.eatonphil.com/books-developers-should-read.htm...
> “Software Engineering at Google: Lessons Learned from Programming Over Time” Isn't Google's software engineering culture kind of a joke right now? I've spoken to multiple ex-Googlers and they tell me they leave because everything moves at a snail's pace. From the outside looking in, it seems like absolutely nothing is being done in Google and I would not want to replicate their engineering culture in any company. P…
Many things move at snails pace because when you generate 10's of billions of $$ every qtr, the first thing you want to do is not screw that up. Google's reality is basically not like any other company (except maybe 2-3). Google's engineering culture, at least a few years back, was insanely good given that reality.
On the other hand, The Little Schemer which has a lot of the important ideas from SICP might be on a list such as this. But it’s too accessible to warrant much respect.
> “Software Engineering at Google: Lessons Learned from Programming Over Time” Isn't Google's software engineering culture kind of a joke right now? I've spoken to multiple ex-Googlers and they tell me they leave because everything moves at a snail's pace. From the outside looking in, it seems like absolutely nothing is being done in Google and I would not want to replicate their engineering culture in any company. P…
Many things move at snails pace because when you generate 10's of billions of $$ every qtr, the first thing you want to do is not screw that up. Google's reality is basically not like any other company (except maybe 2-3). Google's engineering culture, at least a few years back, was insanely good given that reality.
If by "a few years" you mean 4-5, I have to strongly disagree. I witnessed extremely sloppy and incorrect general logic, even worse pathologies around concurrency, and disagreement between:
1. tech team gatekeepers 2. language police gatekeepers 3. mandated framework gatekeepers
when 1+2+3 all disagree and decide to block approvals, it's just comical. Especially since everybody is so sure they know "the right way". The high horse on which many devs at Google sit appears to be purely misdirected/unwarranted ego stroking from many people's point of view who are just trying to make practical, every-day decisions.
“This book is a must-read for any serious software engineer.” This isn’t necessarily wrong but it always reminds me of the era when I had severe impostor syndrome. I haven’t read any of these books and I’m doing very well. I guess I’m just not serious enough. :)
I read two of these last year and I'd recomend both, but I wanted to give my two cents on them. The Phoenix Project: I really enjoyed reading this, but it's told as a story about fictional characters working at a fictional company, which I didn't expect. Because of the way it's written, some other people I know who read it found it a bit too fluffy. Also, from what I've heard, it's pretty much an IT focused version o…
I thought The Goal was more generally applicable. Its core idea ("theory of constraints") is described in terms of a factory floor where different workstations have different throughputs/latencies/reliability; you could apply that to a diagram of a distributed system [0], CPU [1] or server [2]. Examples: [0] https://d1.awsstatic.com/architecture-diagrams/ArchitectureD... [1] https://chipsandcheese.com/2022/11/05/amds…
I've found lots of value in looking at all kinds of systems with this lens, though, like all things, it helps to not overdo it.
SICP shouldn’t be on this list. Few people actually read it and most just worship it unread like a bible. It was Hilfinger’s assigned text in 61A at Berkeley but without any assigned readings. On the other hand, The Little Schemer which has a lot of the important ideas from SICP might be on a list such as this. But it’s too accessible to warrant much respect.
.
.
.
.
The whole The Little|Seasoned|Reasoned Schemer plus its other variants The Little ML'er|Java|Prover|Typer are some of the most mind bending books that you will ever read ever. And it is not the just the end result. Reading these books well will teach you socratic method of teaching/learning, which is great in itself. And will help you teach yourself a wide variety of concepts.
Only real problem is many people struggle to adopt to that socratic approach and for somebody who is not into it will just not get it. Have seen this time and again, while I had my jaw on the floor reading them, some of my colleagues could barely progress beyond the first few pages. So they aren't exactly accessible to everyone.
.
.
.
.
.
.
.
NOW GO CONS SOME CAKE ONTO YOUR MOUTH.
I read two of these last year and I'd recomend both, but I wanted to give my two cents on them. The Phoenix Project: I really enjoyed reading this, but it's told as a story about fictional characters working at a fictional company, which I didn't expect. Because of the way it's written, some other people I know who read it found it a bit too fluffy. Also, from what I've heard, it's pretty much an IT focused version o…
I thought The Goal was more generally applicable. Its core idea ("theory of constraints") is described in terms of a factory floor where different workstations have different throughputs/latencies/reliability; you could apply that to a diagram of a distributed system [0], CPU [1] or server [2]. Examples: [0] https://d1.awsstatic.com/architecture-diagrams/ArchitectureD... [1] https://chipsandcheese.com/2022/11/05/amds…