Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programmers Don't Read Books – But You Should (2008)

blog.codinghorror.com

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Programmers Don't Read Books – But You Should (2008)

#41

Post by 2OEH8eoCRo0 »

RealityVoid wrote: post #40
2OEH8eoCRo0 wrote: post #20

Earlier quoted context omitted.

It's funny because at the end of the day it's still all just instructions on a CPU. Computers essentially haven't changed in half a century. What the biggest change between then and now? Multi-core processors?

I'd say the computer architecture can vary _greatly_ and there are a bunch of cores in modern SOC's that kind of break the assumption of how a computer works. I recently listened to this: https://youtu.be/36myc8wQhLo?si=sWdKyW3w2vln93SP Cache coherence, accelerators, various takes on pipelining, ISA extensions. There are many many things that change all the time. Not even touching the SW glue stuff that changes. I do…

We are talking about programming computers. What the CPU does once it gets instructions is mostly irrelevant to the programmer. The act of programming is still just building big lists of instructions to feed to a CPU so why has the programming stack grown to such a massive precarious bloated pile of abstraction that gets in my way? Every fancy schmancy language you can think of still just comes down to feeding the same instructions to a hungry CPU.

Re: Programmers Don't Read Books – But You Should (2008)

#42

Post by smusamashah »

jbs789 wrote: post #29
smusamashah wrote: post #15

" The Design of Everyday Things" is a great non-programming book that programmers should read. It tells you why/how you should make things more usable for your users. If you find yourself failing to use something properly, it's not you being stupid, it's the design. Design of doors is famously known example from this book.

I often think about the idea that a good design takes information from the world (or the users head) and puts it into the system, reducing cognitive load. So if a door needs to be pushed, put a push plate on it, rather than requiring the user to remember to push the handle. Think about it when labelling buttons quite a bit, for example. Or workflows.

Or even when writing code, think about whoever is going to read or use your code.

Another idea was about suggestive nature of design. If top of a small wall is flat, practically it's asking you to put your empty can on it.

Re: Programmers Don't Read Books – But You Should (2008)

#43

Post by yimmothathird »

minkles wrote: post #2

I don't read programming books any more because they are mostly shit or expensive or expensive and shit. The hit rate of finding a good one is so low it's easier to just fudge your way around a problem using some idiom you're already experienced with. Just ambling around the book store earlier I saw a 3 inch think tome around Go programming called Pro Go or something. I opened it and it was a whole book of instructio…

I saw an HN thread a while back where someone recommended a comprehensive book on some networking subject. I'm sure it was a good book, I was floored when I saw physical copies being sold fucking $700.

Unfortunately, a lot of the technical books I wish to read fall into this grift of academic texts.

Re: Programmers Don't Read Books – But You Should (2008)

#44

Post by RealityVoid »

2OEH8eoCRo0 wrote: post #41
RealityVoid wrote: post #40

Earlier quoted context omitted.

I'd say the computer architecture can vary _greatly_ and there are a bunch of cores in modern SOC's that kind of break the assumption of how a computer works. I recently listened to this: https://youtu.be/36myc8wQhLo?si=sWdKyW3w2vln93SP Cache coherence, accelerators, various takes on pipelining, ISA extensions. There are many many things that change all the time. Not even touching the SW glue stuff that changes. I do…

We are talking about programming computers. What the CPU does once it gets instructions is mostly irrelevant to the programmer. The act of programming is still just building big lists of instructions to feed to a CPU so why has the programming stack grown to such a massive precarious bloated pile of abstraction that gets in my way? Every fancy schmancy language you can think of still just comes down to feeding the sa…

That's the thing, you have layers upon layers of stuff that run on the computer. You have a runtime of the language, many many abstractions of interacting with the various capability of the system, a ABI to the OS, an ISA. These things vary and you need to account somehow for these variation. And the changes in the lowest layers percolate through.

Not to mention that the computer is actually very very different than what you imagine.

I say this not to make excuses for react, again I don't know that ecosystem. I spend most of my time writing firmware and low level drivers. And I see during my work the wide array of capabilities and approaches these systems have. They are not an homogeneous bunch.

Re: Programmers Don't Read Books – But You Should (2008)

#45

Post by vsuperpower2021 »

johncessna wrote: post #27
vsuperpower2021 wrote: post #12

Earlier quoted context omitted.

Design Patterns is your suggestion of a book that isn't shit? Even the list of "a-ha" books has random landmines tossed in.

The Gof book should be on the list, but I agree that it suffers from similar problems that a lot of first-of-their-kinds do. There are iterations on it that are a much better read.

This also isn't a programming book. It's a business methodology book that is probably more harmful than beneficial.

Re: Programmers Don't Read Books – But You Should (2008)

#46

Post by dkwr »

minkles wrote: post #2

I don't read programming books any more because they are mostly shit or expensive or expensive and shit. The hit rate of finding a good one is so low it's easier to just fudge your way around a problem using some idiom you're already experienced with. Just ambling around the book store earlier I saw a 3 inch think tome around Go programming called Pro Go or something. I opened it and it was a whole book of instructio…

And then you also have the books which cost 60€ and aren't even printed in color. I mean it makes sense for ecological reasons, but I can get books for 19€ that are colorized. It would be a much better reading experience if some boxes would actually show colorized instead of different shades of grey.

Re: Programmers Don't Read Books – But You Should (2008)

#47

Post by rrishi »

jonbodner wrote: post #19
latexr wrote: post #3

Earlier quoted context omitted.

> I don't read programming books any more because they are mostly shit or expensive or expensive and shit. That’s consistent with the first reason given in the article: > I lay part of the blame squarely at the feet of the technical book publishing industry: > Most programming books suck. The barrier to being a book author, as near as I can tell, is virtually nonexistent. The signal to noise of book publishing is arg…

I’m the author of Learning Go from O’Reilly, so I might be a bit biased. What I’ve found is that different publishers put different amount of effort into producing good content. O’Reilly is almost always excellent. Others are less so. It’s hard to find a dev who is willing to invest a year of their life to write a book that is likely to make almost no money. It’s doubly hard to find devs who write well. Given these f…

what a coincidence!

i am reading your book now and thoroughly enjoying it!

Learning Go's quite good to get dangerous with Go quickly, so good job!

Re: Programmers Don't Read Books – But You Should (2008)

#48

Post by johnchristopher »

vsuperpower2021 wrote: post #45
johncessna wrote: post #27

Earlier quoted context omitted.

The Gof book should be on the list, but I agree that it suffers from similar problems that a lot of first-of-their-kinds do. There are iterations on it that are a much better read.

This also isn't a programming book. It's a business methodology book that is probably more harmful than beneficial.

None of you I proposing better alternatives though nor what is wrong with it though.
Post reply on HN