Live data from Hacker News

Books that changed my career as a software engineer

julianogtz.github.io

281–290 of 295 posts

Re: Books that changed my career as a software engineer

#281

Earlier quoted context omitted.

You don’t need to read these books end to end. The a builds on b builds on c style of learning is only one way of learning things, and in many cases, the foundations (a, b) serve you no real value. Just jump to the sections that interest you (c) and go back to previous sections if you feel like you’ve lost track of what they’re talking about. For example, the first 20 pages of ‘Remote’ cover why remote working is goo…

Books have been written on how to read a book. Often, it’s some variant of starting with studying the table of contents then doing a fast first pass of the text. That’s usually a pretty good way of figuring out where to start.

> doing a fast first pass of the text

Does that mean reading it end to end?

Re: Books that changed my career as a software engineer

#282
post #275

Earlier quoted context omitted.

Thanks for sharing that. It makes me angry; just hearing this, thirdhand, and a decade later. I was a manager at a company that paid “competitive” (i.e. “low”) salaries. A significant part of my job was identifying “diamonds in the rough,” and helping to train and nurture them; then, encourage them to stay. I feel that I did fairly well, here. When they finally shut down our team, the person with the least seniority…

As a young kid on one of those "competitive" jobs, I've always wondered about this. Do you genuinely encourage them to stay, or do you secretly wish them to move on to better work as well? Surely getting stuck there for a decade isn't the best thing for their career.

Yes, and no. A few did move on, and had well-paying careers, but it took them a long time to find happiness, and they tell me that they never found a situation that was as comfortable as when they worked in my team. The final team members have moved on to do fairly well, although it took a while. They are brilliant engineers, and will be a credit to any organization that hires them.

The pay wasn’t awful, but I was a good manager, and worked hard to accommodate things like family obligations, and, in a couple of cases, serious medical issues. The company had its flaws, but, for the most part, treated its employees well. As time went on, that became less and less. By the time I left, I felt as if the company had become quite rapacious, in its HR policies, and that made me sad.

The pay may not have been that great, but the work was very interesting. We were a marquee brand imaging corporation (which is why they felt they could get away with mediocre pay), and the technology was pretty awesome. We regularly worked with some of the top engineers and scientists in the world. It was an excellent line in your CV.

I have come to learn that money isn’t everything. There’s a tremendous amount of cynicism in our industry, and that is really pretty discouraging. Money has been quite corrosive to the joy of software development, in my opinion. Real damoclean sword.

Re: Books that changed my career as a software engineer

#283
post #260

Earlier quoted context omitted.

> Clean code... To this day I cringe when I see methods/functions over 20 lines long.. Or when I see commented code blocks in one function.. To this day I cringe when I see dogmatic opinions of a fraud taken like an absolute truth.

Clean Code was the first book I read that suggested (with concrete examples and rules!) that I should use code as a communication medium to other programmers first and foremost, the orders you give to the computer comes second. It is an opinionated book and there are some dumb rules in it but it did way more good than harm to the dev community. Definitely not a fraud...

"I read it there first" != "the idea came from there"

Uncle Bob puts forth a couple of good ideas from time to time, but none of those good ideas are his.

Re: Books that changed my career as a software engineer

#284

Earlier quoted context omitted.

Books have been written on how to read a book. Often, it’s some variant of starting with studying the table of contents then doing a fast first pass of the text. That’s usually a pretty good way of figuring out where to start.

> doing a fast first pass of the text Does that mean reading it end to end?

Sometimes yes but not always. It depends on the book.

Re: Books that changed my career as a software engineer

#285

Clean code... To this day I cringe when I see methods/functions over 20 lines long.. Or when I see commented code blocks in one function.. Other have mentioned The Mythical Man Month, and I'd say it's a great book. Sadly, more often than not, it's something I wish I could staple to managements foreheads. "read this now before our next planning session" The Rspec book was a great book, that helped me fully embrace TDD…

There is a cost to indirection, a long function can often be way more understandable than a bunch of short, overly decomposed ones.

Re: Books that changed my career as a software engineer

#286

Earlier quoted context omitted.

Found out that I have ADHD. Never managed to read any books about programming, after a few pages my brain starts making up excuses to do other things and I start rereading the same paragraph over and over again. No issues doing the actual programming, could sit for hours on end without any issues. One nifty thing about my ADHD is that something that was super interesting can become dull as hell. For no apparent reaso…

Those concentration drugs that you hear about, do they work? I've heard that a lot of students use them, but I'm a little bit wary of using something like that.

They can work, they work wonders for me. There's also no "magic pill" and they have their downsides. For me, the pros vastly outweigh the cons, and I've tried several times to make a happy life without support of medication and it's just not as good. (Even with trying a more alternative lifestyle, not being in an environment where I need to sit and focus all the time, etc.)

But also, every body and mind are different. Consult a specialist. There's many different types of ADHD medication out there now.

Re: Books that changed my career as a software engineer

#287

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…

I cannot second this enough. Uncle Bob et all have done imeasurable bad to a lot past and future devs generations. Advocating for a perverted cloudy way of overengineered sw that builds cvs and horrible enterprise sw. There are much better ppl to read out there. Anyone actually writing long lived sw. Linus, sam neal, anyone actually DOING it rather than living off self indulgent books.

Would you mind linking to something written by Sam Neal? Not familiar with the name.

Re: Books that changed my career as a software engineer

#288
post #260

Earlier quoted context omitted.

Clean Code was the first book I read that suggested (with concrete examples and rules!) that I should use code as a communication medium to other programmers first and foremost, the orders you give to the computer comes second. It is an opinionated book and there are some dumb rules in it but it did way more good than harm to the dev community. Definitely not a fraud...

"I read it there first" != "the idea came from there" Uncle Bob puts forth a couple of good ideas from time to time, but none of those good ideas are his.

I never argued who thought about this idea first it's just where I met it. There is value in gathering good ideas. Could you please point me to the books about clean code before Uncle Bob? I'm interested.

Re: Books that changed my career as a software engineer

#289
I think this book would be great addition to any software engineer . I think book captured the recent modern practices ( last 10 years?) in one place .

The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact

Effective Engineer - Notes : https://gist.github.com/rondy/af1dee1d28c02e9a225ae55da2674a...

https://www.amazon.com/Effective-Engineer-Engineering-Dispro...

Re: Books that changed my career as a software engineer

#290

Earlier quoted context omitted.

agree. I’ve inherited codebases from new “architects” who seemingly have just read GoF.

Haha I remember my first designs as a Jr Engineer after I had crammed the book into my brain before starting. I’m pretty sure the other devs just threw those classes into the trash when I wasn’t looking. For about a year I thought everything had to be a design pattern and making a vanilla class was a faux pas. 14 years later I don’t think I use any of the patterns anymore. Maybe facade if I’m refactoring a complete m…

My thought about this is that patterns are something I recognize in the completed code, not something I bake into my code. A useful tool for refactoring at best. But re-factoring, not factoring. :)
Post reply on HN