Hacker News Reader

Comment by swalsh | Hacker News Reader

I was going to agree with you, 98% of my career has been "google for a library, then use or tweak". It's RARE we ever actually do anything "new". However there ARE companies that do, and every once in a while YOU may have to do something new. In those cases it's good to make sure you have a foundation to build on.

I have 4 books in the "The art of computer programming" series on my desk. They've been more or less decoration for several years, until I ran into a problem I couldn't google. Since I read them, I had an idea of where to start, and I used it as inspiration to craft a new solution tweaked from one of these foundational algorithms.

That said, not everyone is strong in algorithm development, and you can be a kick ass programmer without that skill. I'd only ask these questions if I needed someone with that skill on my team.

View on HN

In that 2% of the cases where you have to come up with something new, I don't really think that knowing pretty much any of this would help. You are storing a lot of information that will probably never be used. On the other hand, knowing how to come up with the solution. Knowing where to ask, what books to read or what people to ask, seems like a more important skill.

You are OK with not knowing how to invent, innovate, push the envelope, etc because you don't need to in order to collect your paycheck? Seems sad! Where is your passion for the craft?

That's not what he said.

You misunderstood me. Of course I love to invent and innovate. That's why I don't like memorizing solution to coding challenges. But just because I don't know them by hearth doesn't mean I don't know where to find the solution. Which is the more important skill.

I think we should strive more to be just more than code monkeys that glue stuff from stack overflow... because that makes you or I replaceable.

Even if something represents 2% of your cases, if no one at a company or on the team has algorithmic problem solving skills it will represent more than 2% of your development time.

If you don't know what is the difference between O(n) and O(n^2) and how to make a data structure that allows you to keep the data sorted in particular way, you can get by using ready-made things up to some point. When that point comes, your "where to ask" would be "take a course in algorithms design and data structures and/or read a fat and quite dense book". Which is a completely OK way to advance your knowledge - except that some employers may prefer to hire people that already did that, and not wait with the task at hand until they do.

I tend to place engineers in one of two buckets-- those who make tools and those who use the tools. Most people fall into the latter bucket and can get by without hardcore CS knowledge.

Googling for a library is all well and good, but if you can't evaluate whether it's well designed and well written then you might as well rephrase it as "Google for someone else's problems to add to my own."

The background knowledge to understand what you're looking for and looking at is really important in these cases. You mention having and having read TAOCP, that already puts you ahead of >99.99% of the people doing programming out there - 95% of whom couldn't tell you who Knuth is, what he's written, or what Drofnats refers to.

Reply on news.ycombinator.com