Live data from Hacker News

Books that changed my career as a software engineer

julianogtz.github.io

71–80 of 295 posts

Re: Books that changed my career as a software engineer

#71
post #62

Earlier quoted context omitted.

I love the Mythical Man-Month, but it’s one of those books that only software engineers seem to read, and they already know what’s in it.

Ah, but bad management likes to -claim- to have read it. Sometimes just having the reference can be leverage, i.e., "Well, as per the Mythical Man Month, not all tasks can be parallelized. We can't take three women and complete a pregnancy in 3 months, 3x as fast, after all. This is one of those cases - we won't speed things up by adding people, but we might make things worse"

Sometimes I can't believe that as an industry we've failed to internalize things we've known about for almost half a century.

It'd be one thing if there were managers out there actively disputing the ideas in the book, but I don't really ever see that. Like you say, more often I find managers that claim to have read it and agree. But still, shit like "let's flag if this project is late so we can try to add more people to it" gets said all the fucking time.

I think with a lot of managers, trusting downwards just isn't a thing they're able to do, and so the only move they think they have is to view engineers as miners chipping away at "man-months" of software work. Sometimes I almost think it doesn't matter to them if it actually works or not, it's just the only move they see so it's the only thing they'll do.

Re: Books that changed my career as a software engineer

#72
post #61

Is it just me or do other people struggle to read these kinds of very technical books? It's not that I don't comprehend, it's that my brain finds it boring and hard to focus. I think I have trained my brain so much on rapid skimming of websites for useful info, while throwing away most of the content, that I tend to do the same with books, which really doesn't work well. Has anyone found alternative ways to consume t…

I agree that many of these books are hard and super boring to read. That's why I always recommend books that are written in easy and accessible style, such as The Little Schemer, The New Turning Omnibus, and Programming Pearls (not Perl but Pearls by Jon Bentley). Or, books that are written in problem-hint-solution style, such as The Little Book of Semaphores and To Mock a Mockingbird. These are so fun and easy to read.

Re: Books that changed my career as a software engineer

#73
post #71

Earlier quoted context omitted.

Ah, but bad management likes to -claim- to have read it. Sometimes just having the reference can be leverage, i.e., "Well, as per the Mythical Man Month, not all tasks can be parallelized. We can't take three women and complete a pregnancy in 3 months, 3x as fast, after all. This is one of those cases - we won't speed things up by adding people, but we might make things worse"

Sometimes I can't believe that as an industry we've failed to internalize things we've known about for almost half a century. It'd be one thing if there were managers out there actively disputing the ideas in the book, but I don't really ever see that. Like you say, more often I find managers that claim to have read it and agree. But still, shit like "let's flag if this project is late so we can try to add more peopl…

Well, speaking as a manager, I can tell you a LOT of that is coming from above middle management too, and the optics of adding people and failing is better than not adding people and failing.

Heck, I stepped away from my last job in part because the environment was that (really, 'leadership' was just generally so bad, and this was but one of its manifestations of suck). I kept having status meetings as we neared a due date (that had been set by product, not engineering, and which our velocity said we would not make) asking us if we'd make the date. To which I replied "Data says no; gut says maybe. If I say we're not going to make the date, what are we going to do differently?", and to which they had no answer -except- "pull people from other projects and put them on this one". Nevermind that the whole difficulty was learning the integrative aspects, i.e., communication, NOT implementation (and that was why gut said maybe; we had learned a lot already, which is what took a lot of time; we were still facing both known and unknown unknowns).

Meanwhile, the teams that were getting kudos were the ones where managers were just like "yep, we're floundering; give us more people". If they succeed, they were brilliant and knew to ask for help. If they failed, well, it was doomed, but at least they knew to ask for help. Nevermind if more people were actually helpful, and derailing other projects just to get them was worthwhile. Clearly, I was a bad cultural fit; I cared more about getting things done efficiently.

The Mythical Man Month reference there was helpful for not derailing things by having more people thrown in the mix; it wasn't helpful for avoiding blame.

Re: Books that changed my career as a software engineer

#75
post #61

Is it just me or do other people struggle to read these kinds of very technical books? It's not that I don't comprehend, it's that my brain finds it boring and hard to focus. I think I have trained my brain so much on rapid skimming of websites for useful info, while throwing away most of the content, that I tend to do the same with books, which really doesn't work well. Has anyone found alternative ways to consume t…

I tend to gravitate to pen and paper when I’m not zoning into a book and either draw charts on a notebook or write small notes into post-its I stick to the book.

Re: Books that changed my career as a software engineer

#76
I have a terrible problem with people recommending books that „changed their whatever”. And sometimes I think that it comes from an arrogant place where people being „influenced” by books is a bad place. But I do understand that sometimes books can change the way one thinks about things, and it makes sense to make a list of those.

For me, there are books that had a negative impact on my work. The GoF book is one such book, and its impact on my development is so distructive I can't even begin to explain. It's not only because it tries to codify coding as a sum of recipes, but people reading it end up with the scary idea that there is only one way of doing things, and that one way has a clear name, and a single possibility for implementation. The GoF buffs are those that keep stressing the most autoerotic interview question: „describe me one design pattern, other than Singleton”.

Now worse than people who read the GoF book are people who dove deeper into the issue and learned about more design patterns from other books. One such people screwed my career development for 7 years because at one internal interview he asked me out of nothing about the „half sync half async pattern”, that solves a problem that he wasn't able to describe to me. And since I failed, I was forever on their s*t list.

I think there are good books that can influence your life in a positive manner, but those are incremental changes, things that add a few things here and there. I would expect to see on lists that „changed careers” books on programming languages, like Kernighan & Ritchie on C, or Stroustrup's or Alexandrescu's books on C++. Or books on fundamentals, like Hennessy and Patterson, like Tannenbaum's Network or Operating systems, Knuth, or Cormen&al on Algorithms. But since I rarely do...

Re: Books that changed my career as a software engineer

#77
post #48
post #33

Earlier quoted context omitted.

Exactly, why are you chasing promotions? Isn't it ok to be happy with where you are and have satisfaction? My title is Sr Software Engineer. My boss keeps bringing up in our 1 on 1s about what we should do to carve out a path for a promotion to "Principal Engineer" but I don't care. The small amount of pay bump is just not worth the added responsibility (not to mention the hoops they make you jump for the promotion).

This is a great mindset to have. I would especially recommend that you avoid management for as long as possible. The joy of building software is hard to replace once you hang it up and start attending meetings for a living.

Exactly. For many people senior software engineer is a stepping stone to something more, for me, there is nothing greater. If I wanted to be more ambitious I’d start a business.

Re: Books that changed my career as a software engineer

#78
post #62
post #9

Huh. Mine would be: * The Mythical Man-Month, Brooks * Rapid Development, McConnell * Extreme Programming Explained, Beck, et al * Test-Driven Development by Example, Beck * Domain-Driven Design, Evans And something that wasn't a book but made a huge impact was Eric Ries's blog, Startup Lessons Learned, circa 2009. He correctly spotted that things like Extreme Programming are generic software development processes, b…

I love the Mythical Man-Month, but it’s one of those books that only software engineers seem to read, and they already know what’s in it.

When I met Fred Brooks, I had no idea who he was. He was just another grandparent of a student in a club I was volunteering with. Spent some time with him on a road trip even. Such a humble and kind man.

It wasn’t until our 3rd or 4th interaction that I put two and two together. The result was a very nicely signed and personalized copy of the MMM.

Re: Books that changed my career as a software engineer

#79

I have a terrible problem with people recommending books that „changed their whatever”. And sometimes I think that it comes from an arrogant place where people being „influenced” by books is a bad place. But I do understand that sometimes books can change the way one thinks about things, and it makes sense to make a list of those. For me, there are books that had a negative impact on my work. The GoF book is one such…

> One such people screwed my career development for 7 years because at one internal interview he asked me out of nothing about the „half sync half async pattern”, that solves a problem that he wasn't able to describe to me. And since I failed, I was forever on their s*t list.

This is a sign, that in order to solve the problem, you must move on to a job that isn't the problem.

Re: Books that changed my career as a software engineer

#80

Earlier quoted context omitted.

I don't think you meant this to be as absolute as it sounds, but as someone currently reading it, I find the asides, especially ones that focus on the nuances of a word's definition, such as "atomic", "consistent", etc. to be tedious while simultaneously lacking in clarity. I hope if Kleppmann ever does a 2nd edition that strips out some of this stuff and adds more examples, because most of his sales are probably fro…

I did. And it is. There is no such book out there that covers breadth and sufficient depth at the expense of minor pedantry (that you're alluding to) without losing much meaning. For most engineers, being familiar with pros and cons of technology is far more important than nuances of terminology. They can and should investigate each topic more deeply when time comes. I repeat with emphasis: It is exceptional in every…

I felt like parent first time I was reading and abandoned after a couple chapters. Went back recently and read it through. Wow. Agree with you. One of the best books I’ve read, could be improved but it’s definitely in a tier beyond the majority of books in our field.
Post reply on HN