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

161–169 of 169 posts

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

#161

Post by cruise02 »

perrygeo wrote: post #6

> I've read all of these books myself, so I have no difficulty believing that many moderately competent programmers have read them as well. If you're interested enough in programming that you're reading this blog, you've probably read most, if not all of the books in this list That is some gross arrogance on full display right there. If you're as good as me, surely you've read all these books. Any other books... flaw…

It isn't arrogant to assume other people are at least as well read as you are. It would be arrogant to assume that they aren't.

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

#162

Post by pkroll »

gozur88 wrote: post #45
nchelluri wrote: post #32

Is Code Complete still worth reading for a working developer?

I didn't think it was ever worth reading. Steve Maguire's "Writing Solid Code" was much better, though TBH it's been so long I have no idea how it holds up.

I've read both, and while Code Complete covers a LOT of ground, I like Maguire's style and his practical information. I wouldn't want to be without Code Complete, but Writing Solid Code (and his followup, Debugging the Development Process) has plenty of decent info. And some dated.

Much of Maquire's coverage is VERY C++ centered, so people using anything else are going to skip a bunch. It's a short book, 250 or so pages, and an easy read.

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

#163

Post by OskarS »

damontal wrote: post #114
OskarS wrote: post #108

Earlier quoted context omitted.

I read most of both of TAOCP and CLRS when I was in my late teens and early twenties. I couldn't follow the most difficult mathematical bits, but I don't think it's THAT unusual to have worked through most of both of them.

TAOCP has four volumes. Its not just a single book. Did you work through all four volumes?

The first three. Fourth wasn't out back then.

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

#164

Post by sytelus »

zodiac wrote: post #106
sytelus wrote: post #42

I've read CLRS page-to-page 3 times and doing pretty significant chunk of exercises. It takes on average about 4-8 months with 2 hours each day. I still think the title is accurate, i.e., its just "introduction". These days at work I frequently bump in to algorithms that would be qualified as advanced and CLRS content now looks fairly introductory to me. In fact book hasn't even scratched 10% of the stuff that we use…

I'm curious, what do you do at work and what kinds of algorithms do you bump into?

computer vision, machine learning, control software and things around that.

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

#165

Post by FroshKiller »

nchelluri wrote: post #32

Is Code Complete still worth reading for a working developer?

I'm a working developer who has read Code Complete. It's definitely worth reading. It's the only book on my bookshelf at work that isn't internal documentation or my own notebooks.

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

#166

Post by mafribe »

wtetzner wrote: post #146
mafribe wrote: post #109

Earlier quoted context omitted.

I'm pretty sure it's the hardest language to implement Harder than languages that require JIT compilers to achieve reasonable performance? Even scalac and ghc are pretty complex beasts in order to Scala and Haskell reasonably speedy.

I read the comment as saying C++ is the hardest language to implement, not the hardest language to make fast.

Speed and type-inference are the two hard things in compilation in my experience.

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

#167

Post by mafribe »

WalterBright wrote: post #147
mafribe wrote: post #109

Earlier quoted context omitted.

I'm pretty sure it's the hardest language to implement Harder than languages that require JIT compilers to achieve reasonable performance? Even scalac and ghc are pretty complex beasts in order to Scala and Haskell reasonably speedy.

I've written a Java compiler, and a friend of mine (Steve Russell) wrote the JIT for it (for Symantec). It was the first JITting Java compiler, and took only a few months to complete. Of course, I should have said "front end". Working on the optimizer/codegen is an endless process.

Yes, C++ has a baroque syntax, and I wish lexing/parsing C++ on nobody.

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

#168

Post by marme »

all 5 of the books mentioned that programmers dont read were required reading for my CS degree. Did I read them cover to cover? no but i did read enough to say which are useful to read and which are not. I would guess the majority of programmers who have completed a CS degree have only read those books because they were required reading, does that make the books less important or useful?

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

#169

Post by tracker1 »

wilbo wrote: post #158
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…

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, onboardin…

But do whiteboard exercises that consist of concepts that someone is unlikely to ever touch really count for the quality of code one is likely to output?

Especially when many of those concepts necessitate code that is less than discoverable, well documented and easy to follow?

Post reply on HN