Live data from Hacker News

Books that changed my career as a software engineer

julianogtz.github.io

221–230 of 295 posts

Re: Books that changed my career as a software engineer

#221
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 read novels just to reduce the pace of my brain.

Maybe your brain does not need to work like that.

Re: Books that changed my career as a software engineer

#222

The one thing that I find is not helpful, is the “litmus test” approach. i.e. “You are a bad programmer/engineer/scientist/person, because you did not read this book, or know this technique.” Thing. I see this frequently. As a [mostly] self-taught software developer, I’ve been on the receiving end of a lot of this behavior. In my case, I have a real “Oh yeah? I’ll show you!” streak. I became expert at stuff, simply b…

> "A new idea is delicate. It can be killed by a sneer or a yawn; it can be stabbed to death by a joke or worried to death by a frown on the right person's brow." -Charles Browder

Not just ideas, people have lost their careers to unkind jibes. Here's English Cricketer Monty Panesar explaining the unexpected course his life took after a retort by Australian cricketer Shane Warne that "Panesar hasn't played 33 matches, but the same match 33 times" in a damning indictment of his uninventiveness and inadaptability: https://www.theguardian.com/sport/2021/nov/28/monty-panesar-...

A relevant comment from a thread on CalyxOS: https://news.ycombinator.com/item?id=28101853

Re: Books that changed my career as a software engineer

#223
post #49

The thing that changed my career as a software engineer, in terms of seniority & remuneration by time and effort, was by changing my efforts from learning arbitrary tech to learning the domain I worked in. Asking useful domain-related questions gets you noticed in stand ups and helps you write the right code. I work in fintech so the best bang for my buck I’ve had was reading an entry level cert in investment finance…

And it's one of the rare good advice. Communication failure (or even slow) is so expensive, being the guy who can translate ideas clean and fast will make a lot of things better.

Re: Books that changed my career as a software engineer

#224
post #92

As a self taught dev, the books that helped me most are: Code: The Hidden Language of Computer Hardware and Software The Design of the UNIX Operating System Designing Data-Intensive Applications They taught me that there is no magic. Everything is logical and comprehensible.

As another self taught, my favorites would currently be something like (from low- to high-level): - The Elements of Computing Systems: Building a Modern Compiler from First Principles - Operating Systems: Three Easy Pieces - Systems Performance: Enterprise and the Cloud - Exercises in Programming Style - The Little Typer - Conceptual Mathematics: A First Introduction to Categories

I liked the `little` series. It's a bit slow if you already know enough circular lispiness but they really manage to make a full theory emerge from tiny innocent questions. Brilliant.

I could add Queinnec's Lisp in small pieces (for the gradual derivation of fancier and fancier interpreters, the continuation one in CLOS was cool, and the bytecode part also very very cool)

Bratko's Prolog book was nice.

I'm tempted to mention the dragon book but I only read 40%.

Re: Books that changed my career as a software engineer

#225

There seems to be a lot of criticism of the books mentioned in the blog and the comments. I am aware that expecting that some books are going to revolutionize a person's skills as an engineer is naive at best, but some people are even going as far as saying that following some principles/books can even be destructive. Ofc following anything dogmatically is dangerous, but is that the only concern? Just keep in mind th…

Understand that most of the books are born from experience. But they represent what that author(s) learned, which may or may not have been the right lesson in every case and, almost always, is not a true universal lesson.

Some views have to be considered in context. If OO means Smalltalk to one author and C with Classes to another their statements on “OOP” will actually be about two different things, learn from them both but don’t misapply the lessons from one to the other (happens a lot).

With that in your head, read the books and question them. Experiment with their ideas where you can or run thought exercises, “What if…?”

Also, read “The Psychology kf Computer Programming” by Weinberg. He presents many different case studies (though briefly) and commentary. One of the few books where it is clear his prescription is, “Study people and their behavior” not “Do what I say and you’ll make perfect code.”

Re: Books that changed my career as a software engineer

#226
post #104

If they didn't allow you to start your own website/service or become independent then they did not change your career.

What a narrow minded way of looking at things. You don't know other people's stories, or what their priorities are, or what situation they're in.

Re: Books that changed my career as a software engineer

#227

Earlier quoted context omitted.

The gordon-ramsey (army coach, sports coach, theatre director, ballet director...) school of "encouragement" prescribes the opposite. That is: if you arent passionate enough to overcome discouragement, you arent passionate enough to excel. Of course, we dont need excellent programmers en-mass. However, it is interesting to observe that this "egotistic troupe leader" is a fairly common form of small-group excellence-s…

Well, it also has a lot to do with whether or not you want good teams , or good individuals . The "Marine Bootcamp" methodology is hundreds, if not thousands, of years old, and is how we make good teams. Teams are how we make awesome stuff, but individuals are how we conceptualize awesome stuff. I've found that the best products come from hybrids of the two.

I think this is a really helpful remark.

If you look at where this works, the team simply needs to execute -- largely not think creatively. I can see, then, why this is a comparatively rare form of organisation in programming teams.

I wonder if there's room for it in programming training. Imagine being drilled to produce the same algorithm in a variety of languages over-and-over. Would this be useful? (I use to drill myself in writing dynamic dispatch MVC frameworks as a teenager; I could produce a whole framework and app in a 1hr technical interview -- is this useful? I dont know).

I raise this because I've become increasingly interested in rationalising the Ramsey-esq autocrat, as its always been a part of myself I have been most self-critical of; because I am at once very sensitive to upsetting people but also "brutally attentive" to their (and my own) failure.

I have recently been asking myself: is this brutality actually useful? How much? Does it really require the humiliation a Ramsey or drill-sarg engages in?

Recent western cultural mores are aimed at ameliorating ego-injuries. Is there value in causing ego-injuries? Is there value in humiliation? Clearly there is -- it works in some cases.

Its a weird question to ask though: our culture is so preoccupied with preventing ego-injury... it seems immoral and absurd to suggest causing them.

Re: Books that changed my career as a software engineer

#228

The one thing that I find is not helpful, is the “litmus test” approach. i.e. “You are a bad programmer/engineer/scientist/person, because you did not read this book, or know this technique.” Thing. I see this frequently. As a [mostly] self-taught software developer, I’ve been on the receiving end of a lot of this behavior. In my case, I have a real “Oh yeah? I’ll show you!” streak. I became expert at stuff, simply b…

> "A new idea is delicate. It can be killed by a sneer or a yawn; it can be stabbed to death by a joke or worried to death by a frown on the right person's brow." -Charles Browder Not just ideas, people have lost their careers to unkind jibes. Here's English Cricketer Monty Panesar explaining the unexpected course his life took after a retort by Australian cricketer Shane Warne that "Panesar hasn't played 33 matches,…

"I fear not the man who has practiced 10000 kicks once, but I fear the man who has practiced one kick 10000 times." - Bruce Lee

So now I'm thoroughly confused, which one is better?

Re: Books that changed my career as a software engineer

#229

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.

I would recommend trying something like l-theanine, or other any of the other supplements which have purported effects on focus.

Re: Books that changed my career as a software engineer

#230

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…

What the hell is GoF
Post reply on HN