On the shoulders of the giants | Hacker News Reader

On the shoulders of the giants

lpalmieri.com

397 pointsLukeMathWalker58 comments

I’ll second designing data intensive applications as one of the most interesting, readable, and relevant technical books I’ve ever read.

Working Effectively with Legacy Code was also impressive, I think I just read it too early before I was good enough to really understand and use it.

TDD is also worth reading (and it’s short) to get a sense of tests if like me, it’s something you’d never really done before when learning.

If you like soul of a new machine, you’d probably like Halt and Catch Fire on Netflix. I’d also recommend the Phoenix project and the dev ops handbook.

Code by Charles Petzold is one of my favorites to recommend, something every CS student should read.

I’ll have to check out the others on this list too.

Halt and Catch Fire is SO underated! It's fun. I try and describe it as if the team that made Mad Men created Silicon Valley.

It's fun, nostalgic, and shows a fairly accurate few of the devil-may-care and slightly-charlatan approach to early (and some current) startups.

Sigh, moving house soon, the kids are gone so it's smaller, we're not going to have a dedicated library, choosing which textbooks to keep and which to toss today has been brutal ... half haven't aged well and are going

Culling collections intelligently promotes an archive to a library.

Snap a photo of the covers and box 'em up.

In the vein of working effectively with legacy code, "Reading Code" by Spinelli taught me a lot when I was a younger engineer https://www.amazon.com/Code-Reading-Open-Source-Perspective/...

(Amazon says I bought it 14 years ago!)

15 years ago, one of the "soft questions" I liked to ask in phone interviews was "If I were to look at your bookshelf right now, what books would I see there?"

Nowadays, I keep nearly all my books electronically; I still have a sizable bookshelf, but the books are gathering dust.

I don't like electronic technical books. I find it too hard to find what I'm looking for in them. I find it's hard to beat being able to quickly flip through a physical book.

I even like to print out a lot of technical documentation. For instance, I’ve printed the Tutorial from the Python documentation, as well as the regular expressions module. It was really handy to be able to look through it wherever I wanted, mark it up, and reference it easily.

One of my biggest gripes is when documentation does not have a PDF.

On the one hand, I prefer the feel of a physical book but I find myself reading them less because I can't read them quite as easily for fun (i.e. trying reading Misner, Thorne, and Wheeler while lying down without breaking your nose or arms)

On the other hand, I enjoy having electronic versions of technical books because I can search for things in them.

Yes, plus you often get updates nowadays, which, depending on the domain of the book, can be pretty important.

> I find it too hard to find what I'm looking for in them.

That’s how I feel about physical books…

> I find it's hard to beat being able to quickly flip through a physical book.

I find it hard to beat Ctrl+F.

When conducting interviews in the U.S., I'm very careful when asking soft questions like that.

If a candidate's answer included a book that touched on a topic from some legally-protected class (e.g., race, religion, or sexuality) and that person didn't get hired, it could be one more piece of ammunition in a hiring-discrimination lawsuit. (I do wonder if I'm being overly cautious on this.)

I'd probably rework the question to something like, "Have you found any good books, websites, etc. that you've found useful for growing the skills this position requires?"

Not to sound like a jerk, but that sounds a little paranoid to me.

You’re entitled to your opinion, but what GP is saying is factually correct.

Not offense taken. It's hard to know if it's overly cautious or not.

Company legal and HR advice seems very conservative considering how rarely I hear about such lawsuits actually happening.

But I'm hiring on behalf of the company, so I let the people above me choose their risk tolerance.

It's their job to be defensive. Given the low frequency of incidents, it can appear paranoid because they appear to be defending against something that never happens from a individual point of view.

I too would much prefer to read a paper book, but after going through a major move between metro areas I realized how many of these physical books just spent most of their time sitting there, unused.

I so dislike questions like that. In my opinion, a job interview shouldn't attempt to judge someone as a whole person. It should measure their ability to perform the job, nothing more. If a lizard showed up and demonstrated that it can perform the job, I'd hire the lizard.

Yes and no. Such a question tells whether, how and what the person is learning.

Lots of people can do the job. Is this person a learner? And what kind of learner. Learn on the job? Learn in your free time? And what does this person like to learn?

Giving someone a work task and seeing if they can complete it is unbiased and non gameable. Using kitchen psychology to deduce "are they a learner" gives your biases a free pass and is super gameable once candidates catch on.

You can game the work task too right? Someone posts the question on glassdoor before you realize...

Here's the thing though. I don't want to work with an engineer who hasn't read anything technical in the last year. Don't care how good of a problem solver they are, if they don't teach themselves things they probably aren't very passionate about the profession.

I think as a society, we shouldn't require people to be passionate about their jobs to put food on the table. Jobs should be just jobs. The days when the internet was a beacon of light are long gone, today expecting "passion" about CRUD apps or ad-tech is just fake corporate mentality.

Yeah but not every job is like that.

For a tech job, learning isn't really about passion (necessarily). It's part of the job requirements, because you'll almost certainly need to use technologies you aren't familiar with. This doesn't require you to have a shelf full of tech books of course.

> I don't want to work with an engineer who hasn't read anything technical in the last year.

Last year I took a year-long sabbatical and went to New Zealand. I spent half of that time offline. During that, I read 4 technical books. I really enjoyed that.

Before and after that I don't really have the time to read through a book in a meaningful way. After work my brain is to tired to focus more than a few pages. I still read relevant blog posts that are usually more dense and short so I don't loose focus while reading.

Yeah you definitely need to moderate how much energy you give your job if you want to have a life and also make investments in yourself.

Tell me some truly objective methods to find out if someone is skilled.

There is always a subjective reason why someone can fail.

Whiteboards? Some don't perform well with those. Take-home assignments? People can lookup solutions. Everything can be used.

Asking someone: what did you learn in the last year? How? And what did you gain out of it?

These don't seem hard and unfair questions to ask.

That doesn't sound right to me.

You are saying loud and clear you assess how good an engineer is fit for a role literally judging part of personal life based on your own (100% unbiased, right?) inference process.

No I didn't say anything like that, and to be honest, I don't generally ask such a question. However, in some cases, for example if you are a Junior, it's interesting to know how you learn, what drives you, etc. A book, a course, whatever, can give an idea. I mean, sure you can lie, you can fake all the certificates you want, but then eventually you'll join the company and there is the probation period. If you are not someone that likes to learn, it comes up relatively quickly. I think it's a fair question to ask, nothing to base the entire decision on.

I find it funny that I received a lot of criticism for this, when companies out there are still giving people BS riddles and "find the leaf with the value 'x' in a binary tree in O(logn)", or whatever crap they ask, to assess how good an engineer is, however, asking for how someone learns, how updated someone is, etc., is a something you should not take into account, while I find this very important, because it shows an important aspect of the person's attitude.

I think that we should stop hiring coders, and we should start hiring people. And people have interests, such as reading, fishing, etc.

That approach might work best when hiring a solo contractor to write the firmware for an outer space probe.

In my line of work, we operate in sizable teams, and write software that evolves continuously over several years. Under such circumstances, factors other than being able to solve a coding problem in isolation inevitably come into play.

Another concern is that we don't want to hire somebody just for being able to solve today's problems, today, but somebody we expect to solve, down the line, problems we don't even know exist yet. Learning styles matter in that context.

That said, the concerns you and others in this thread have raised about the subjectivity of evaluating answers to such a question are not without merit. But now that I'm asking more coding questions, I would argue that there is plenty of subjectivity in evaluating the answers to those as well.

The DDD books are such a godsend when approaching complex business domains and how to build software for them. I wish they taught that stuff back at college rather than all the curriculum stuffers.

It was so alien when I was not in this kind of business though, that I thought it was a bunch of completely outdated ideas from the 90s.

The greatest technical book I’ve ever read is PBRT. It’s a computer graphics book, but is a phenomenal achievement.

Awesome list. Thank you for sharing!

I agree!

I've only read one of the books on the list (Accelerate), and it was such a delight to have claims referencing sources in publically available empirical data/studies to corroborate said claims! Not to mention that their observations and inferences (based on the empirical data) make a lot of sense when you ponder a little while!

(As opposed to the many "this-is-how-we-feel-the-truth-should-be-represented-after-our-experiences" presently available in countless blog posts and conference videos on the same subjects/themes as the Accelerate book touches upon).

No TAOCP or even The Mythical Man-Month?

TAOCP is a wonderful coffee table book, but I don't think I've ever seen somebody use it on a day to day basis.

It isn't really the kind of book you use on a day-to-day basis; you consume it in small doses (after crossing the initial cliff of notation, et cetera), like vitamin supplements. That doesn't make it any less useful, however.

Today having physical copy of TAOCP is mostly only useful as the coffee table/conference room artifact. All the stuff in there is either well known because it is part of basic CS curriculum, better analyzed by subsequent works or mostly irrelevant.

My personal experience is that anything in TAOCP can be found elsewhere in a more accessible format.

That's interesting; my personal experience is the opposite: for most things in TAOCP, it is written more clearly than its source material, especially as it gets to the more advanced topics within each section (often only published in papers, not yet in books). For example, Section 7.1.4 on Binary Decision Diagrams, aka BDDs and ZDDs (pages 202–280 of Volume 4A, draft online: http://www.cs.utsa.edu/~wagner/knuth/fasc1b.pdf) is not something I've seen explained to that level of clarity and detail anywhere else. Plus there are a lot of Knuth's original ideas in the books; his innovation is not restricted to summarizing and teaching.

TAOCP = The Art of Computer Programming by Donald E. Knuth

Sorry, I don't understand: could you clarify why you're telling me this? Was there anything in my comment that seemed like it was talking about something else?

I think the parent comment was trying to be helpful for other readers who might not know what TAOCP stood for, since it wasn't defined from the beginning of the comment branch.

For what it's worth, I appreciated your defense of the book, that there's genuine value in reading it, rather than as a "coffee table book" (I guess social signalling); that Knuth explains things clearly and in detail, with unique approach and insights.

Ah that makes sense, thank you. Always good to explain acronyms; it just didn't occur to me that it was a reply to the whole subtree of comments, so I was confused how to respond.

Back in the day, we had to write floating point routines before there was 80387. We had the appropriate chapter of TAOCP open during the whole project.

Also, if you read Programmers at work, it was the knowledge of the one rarely taken step in the long division algorithm that enabled one of the subjects to debug a process that had no tools.

I'd pick SICP over those 2

Just wondering, why is TAOCP or SICP (as mentioned in a child) essential? I've always considered reading them since I hear about them all of the time but I could never really relate it to the work that I do (around distributed systems and storage). I'm sure the material in the books is useful, but are these books must-reads?

In databases, there is Readings in Database Systems (http://www.redbook.io/). I wouldn't recommend it as an essential to all engineers and researchers, because one would be better off spending their time learning practical skills that apply to their job (relevant tools, protocols, etc.), gaining a broader understanding of CS, and exploring general topics (work/career, teamwork, enjoying life, etc.).

In the same vein, it feels like SCIP and TAOCP go too far in-depth into topics that aren't that important to everyone. I rarely see the topics in these books pop up in the research papers that I read (though I mainly read systems ones). I definitely don't see them when I'm building REST services or Javascript frontends. When I check on the Table of Contents in these books, I never feel like reading a chapter in the book would have saved me a ton of time in the past.

As a result, I've concluded that they a good intro/intermediate CS reference for people who'd be interested in the research/theory side of things. Still, I've seen them recommended so much that it bothers me. Have you all seen anything in these books that truly makes them required readings?

There are other “sacred” books:

  - SICP,

  - Concepts, Techniques, and Models of Computer Programming,

  - Paradigms of AI Programming:
 Case Studies in Common Lisp,

  - Elements of Programming.

I got them all at some point in my career in order to become a top notch engineer. I have not finished any of them yet, 10 years later. I think they are great and you can learn from them a lot, particularly I found CTMCP to be very informative.

Problem is they require dedication, and I think one gets the most from them by consuming them sip by sip meanwhile coding a lot and integrating new techniques and mental models.

EDT: formatting

"In computing, we mostly stand on each other's feet."

-Richard Hamming

"If I have not seen as far as others, it is because giants were standing on my toes."

"my shoulders" actually.

From Hal Abelson, who attributes this thought to his Princeton roommate Jeff Goll

This reminds me of a Neil deGrasse Tyson quote to the effect of:

"Walk into a bookstore and look at the number of books on a topic. The more books on a topic you see, the less we understand about the topic."

There's a lot of clashing perspectives on computing and modern software architectures so I'd say Hamming is on the dot.

Hamming is the compression guy right? I feel theres some extra connection seen here in being able to compress down the redundant info in that section of the bookstore

Don't most SV types believe they've picked themselves up by their own bootstrapped?

Is there any reason to believe Hamming said this? https://wiki.c2.com/?ShouldersOfGiants kind of implies no.

As far as standing-on-giants jokes go, when Stekel defended himself to Freud with "a dwarf standing on a giant sees a little further", Freud replied "a louse on an astronomer does not".

https://books.google.com/books?id=wmB9AAAAMAAJ&q=louse+intit...

Reply on news.ycombinator.com