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

Books Programmers Don't Really Read (2008)

billthelizard.com

Post reply on HN
Print view View original

151–160 of 169 posts

Re: Books Programmers Don't Really Read (2008)

#151

Post by astrostl »

AJRF wrote: post #88
nanolith wrote: post #23

I've read the books on both of those lists, among many others. Not because these are all required reading, but because I've had a long career and I've fought to continually improve my knowledge in Computer Science. It seems rather arrogant of the author to decree that one list is canon and the other list is not. Each of those books has its use. Does this mean that someone needs to read any of those books to be good a…

"I've read the books on both of those lists, among many others." - I knew this would be the top comment. HN is fast becoming a parody.

In this moment, they are euphoric.

Re: Books Programmers Don't Really Read (2008)

#152

Post by hilop »

tracker1 wrote: post #145
ssalazar wrote: post #128

Earlier quoted context omitted.

> To me the funny thing is the small companies with 2-3 developers hiring like they are google with interviews over the course of weeks, with google/amazon-like gauntlets. Hmm. Arguably small operations need to be more stringent if they are deciding who will make up the next 25%-33% of their engineering workforce. At small companies one bad hire can really poison the well.

True, but they'd probably be better with a hire/fire fast attitude than draw out the interview process... Interviews take time away from the people doing the interviews that can be spent doing other things... do you really want to allocate more than half your company for weeks vs. getting stuff done. I mean, have a trial period of a week or three... That will tell you far more than a gauntlet interview process with a…

A 3 week trial period is a far longer than an Amazon interview sequence.

Re: Books Programmers Don't Really Read (2008)

#153

Post by hilop »

WalterBright wrote: post #92
TickleSteve wrote: post #84

Earlier quoted context omitted.

9. Intel C++ 10. Watcom 11. IAR 12. Commeau etc.

Intel is derived from EDG. Commeau is derived from Cfront. I don't know anything about Watcom C++.

Years ago we had some banned C++ features Because they didn't compiler properly on HP-UX compiler. But maybe that was still part of the g+ umbrella

Re: Books Programmers Don't Really Read (2008)

#154

Post by hilop »

I've read all of 3/10 books on the first list "everyone reads", and 3/5 on the "no one reads" list.

Most of the books on the first list were published after veterans already learned the relevant materials -- the author must be under 30 (so under 25 at the time).

Certainly a weird sample among popular books, the author thinks everyone reads the same arbitrary subset of books he had.

Re: Books Programmers Don't Really Read (2008)

#155

Post by rhapsodic »

InclinedPlane wrote: post #132
rhapsodic wrote: post #126

Earlier quoted context omitted.

> Additionally, the GoF book doesn't make it clear that each design pattern exists to work around specific constraints, and thus doesn't educate the reader when and why the design pattern should be used, and when not. Quite to the contrary. I don't have my copy handy and haven't cracked it open in years, but I recall clearly that they presented design patterns as reusable solutions to commonly occurring problems. And…

I do have my copy at hand. While they do try to get across the concept that not all patterns are suitable for all cases they do a remarkably poor job of it. The "applicability" section of most described patterns is a simple bullet list of 3 or 4 very vaguely worded sentences. This is, as evidence has proven, wholly insufficient. There should have been much more effort into trying to educate readers on the applicabili…

YMMV, I guess. I thought they laid it out all pretty clearly.

Re: Books Programmers Don't Really Read (2008)

#156

Post by tracker1 »

hilop wrote: post #152
tracker1 wrote: post #145

Earlier quoted context omitted.

True, but they'd probably be better with a hire/fire fast attitude than draw out the interview process... Interviews take time away from the people doing the interviews that can be spent doing other things... do you really want to allocate more than half your company for weeks vs. getting stuff done. I mean, have a trial period of a week or three... That will tell you far more than a gauntlet interview process with a…

A 3 week trial period is a far longer than an Amazon interview sequence.

For one person.. not for a few dozen... It's easy enough to pick the apparent best from the available pool much faster.

Also, there's the cost of existing staff in interviews... if you only have 2-3 devs, and you're keeping them all in interviews with multiple candidates, you're not getting work done.

Re: Books Programmers Don't Really Read (2008)

#158

Post by wilbo »

tracker1 wrote: post #145
ssalazar wrote: post #128

Earlier quoted context omitted.

> To me the funny thing is the small companies with 2-3 developers hiring like they are google with interviews over the course of weeks, with google/amazon-like gauntlets. Hmm. Arguably small operations need to be more stringent if they are deciding who will make up the next 25%-33% of their engineering workforce. At small companies one bad hire can really poison the well.

True, but they'd probably be better with a hire/fire fast attitude than draw out the interview process... Interviews take time away from the people doing the interviews that can be spent doing other things... do you really want to allocate more than half your company for weeks vs. getting stuff done. I mean, have a trial period of a week or three... That will tell you far more than a gauntlet interview process with a…

For me, as a CEO, hire/fire fast is definitely more costly than a well-designed interview "gauntlet"

Before starting my own company I was a bar raiser at Amazon. Interviews were not supposed to last weeks (though many did and there were internal metrics aimed at driving interview to offer cycle time down).

I'd much rather spend a few hours per interviewer per candidate getting a solid candidate than hiring, onboarding, training, learning the candidate is a poor fit, and ultimately going through the not-fun-for-anyone firing process.

High turnover isn't worth the lost productivity from other employees or the hit to morale. On top of that, while learning whether or not the candidate will make it through the trial, you're burning precious cash.

Learn how to interview and teach your people how to interview. It will save you heartache and money.

Re: Books Programmers Don't Really Read (2008)

#159

Post by eveningcoffee »

InclinedPlane wrote: post #110
johan_larson wrote: post #28

Earlier quoted context omitted.

The problem with the design patterns books (including the GoF one) is that in the end they didn't have much influence. Think of how few of their patterns have become part of the vernacular of our field: Iterator, Singleton, Factory, Adapter, and maybe one or two more. It's not a long list. If you insist on talking in terms of design patterns, you are going to have to explain nearly all of them to your listeners. Inso…

The GoF design patterns book has two core, very closely related, problems. The first is that it doesn't make enough of an effort to present "design patterns" as a conceptual framework. Can you program without using design patterns? No, you cannot. You are always using design patterns whether you know it or not, you're just using ad hoc design patterns without realizing it when you don't think you're using patterns. T…

I agree with your second paragraph, but I also think that as with every book, you have to understand the context it has been written and it is always good to have a wider picture and know how something can implemented using a different paradigm and how things relate to each other.

I am not sure I can agree with the claim that everything written is following some design pattern. Perhaps it is an known anti-pattern instead or completely ad-hoc solution that is neither but is nonetheless a good design.

Design patterns are architectures that have been distilled from the field experience to be useful to solve certain problems resulting in a good design. Therefore it is also quite natural that they get integrated into language designs over the time.

Re: Books Programmers Don't Really Read (2008)

#160

Post by cruise02 »

bigtunacan wrote: post #64

The whole article just seemed like one silly anecdote. "Well these are the books I actually read so it must be the same for everyone." I think the author's next read should be a good statistics book. Here's my anecdotal evidence. I have read 8 out of 10 from his first list. I have read everything except for TAOCP from the second list. Some of the ones from the second list I have read multiple times and I still go bac…

> Periodically over on Stack Overflow (and in many other programming forums) the question comes up about what books are good for programmers to read. The question has been asked and answered several times, in several different ways. The same group of books always seems to rise to the top...
Post reply on HN