Ask HN: How has knowing data structures and algorithms been useful to you?

Learning anything is never a bad investment. It might detract you from an immediate goal but in the long run, learning always helps even if not directly related. In your case, I say go ahead and learn data structures/algorithms as you are fascinated by them. If something fascinates you, go figure out why.

To give you a specific example, around 2003 (wow a decade ago) when I was still in college, we had an assignment in CS class to build a web browser in Java and Swing. It was a fun project and I enjoyed doing it. Guess how I implemented the History functionality? I used linked lists to store the links that I visited. Not because that was the best way (probably not) but that's what I knew at the time. It was fun and I still have the source code btw :). Nothing like the real browsers of course.

Coming from someone who started doing self-taught web development myself...knowing algorithms and data structures doesn't stunt creativity anymore than knowing perspective would for a painter.

They are tools that let you get a job done efficiently and a great deal of creativity can be used in figuring out how to apply and combine them. It further allows more opportunity for creativity because they allow you to operate on a higher level. Most algorithm and data structure knowledge in web development isn't so much, "now I have to implement algorithm x" but is instead, "Algorithm x would be helpful, oh look, there's a library for that."

In all honesty though, in web development enough of these things are baked into the language that your code probably won't actually change very much. The languages and libraries are suited to the problem and all of the typical tasks are taken care of, in that regard. In my experience the day to day is not very changed in practice (though you do think of things differently), but occasionally you run into a problem that in the past would have seemed intractable or just not worth the trouble and realize it's actually not too bad. If you want to be a master in your field it is necessary, but like most aspects of true mastery, isn't needed for the most common utility work.

I do web development, and I think in terms of Big-O notation almost every day.

I remember talking with a colleague once who had written some really slow code. He needed to test whether a specific foo was part of a collection of foos, and his collection was an array. Well, that test is O(n), which means it gets slower and slower as your array grows. I said it should be a set or hash, to make the operation O(1), and he had no idea those had different performance behavior. I was shocked. This is about the simplest application of time complexity imaginable, and he had a degree and 5 years of experience.

You should study data structures not so you can implement a linked list (though you ought to do that in your studies), but so you can reason about what your code will do when you have 1000 products/users/whatevers, 100,000, 10,000,000, etc.

As an aside, an interview question I once heard: You have a program that stores the full text of books. Each book is stored in memory as a binary tree of pages. For a book of n pages, what is the time complexity to print all the pages?

I was a CS major in college, and went on to become an Enterprise Security Architect at a moderately sized and well-known financial services company. I've spent a good bit of my time writing or analyzing code, both for enterprise systems, as well as mobile devices (that, in turn, called those backend enterprise systems).

Have I ever once had to implement a B-Tree? Has the specific knowledge of how to write an effective sorting algorithm ever been directly applied during my work day? No. Not even once. However, it's often important to understand these topics. These days, the tools are already there for you. Java, .Net, and nearly every other modern programming language already has the most common data structures and algorithms available to you, either in the language itself or via a well-respected 3rd party library.

So, while you may not ever find yourself actually writing the code for these items yourself, it's important to understand how they work and the implications of choosing one over the other. Given a piece of data, how do you best store it in memory? On disk? Is a linked list sufficient? Perhaps. But what if your piece of data grows to billions of records? What about scalability? What about performance? Memory usage? Lookup and seek times? This is where an understanding of these principles comes into play. I've never had to write an encryption algorithm from scratch (nor should you. EVER.) but I can tell you there have been numerous times where I needed to know the difference between ECB, CBC, and other cipher modes and why the difference was important for a given scenario.

Learning data structures and algorithms is not about the destination. It's about the journey. It's about understanding the deeper reasons and rationale behind how these items operate, so that you can gain a better understanding of computing in general.

It's good because if you don't know data structures, algorithms and how OS manages memory, files, IO and so on... you are just a web developer who knows how to use your tool.

You can't discuss with people over performance, or why memcached has better performance than redis in some special cases and know why by your knowledge, not some random article you've read explaining why on the web, you can't build the tools you use if you had to. You can't explain much of the ruby, PHP or any language you use's internals. You may grasp what is a garbage collector but can't really reason about it.

Plain horrible, if you ask me. I think it's worth it if you love it.

Otherwise just focus on getting a project manager job or some sort of job you don't need it.

It's beneficial to learn algorithms and data structures although you may or may not need them in your projects. Choosing the right data structures and algorithms help with writing clean code that's also more maintainable than a messy algorithm.

I think this knowledge even makes you more creative in coming up with algorithms. There's usually a brute force algorithm that's easy to come up with but it's not very good. By knowing more algorithmic techniques you can come up with better algorithms. Your algorithm x might do the job but in case it doesn't you're possibly lacking the techniques to make it better. By studying many different types of algorithms you get a better feel on how to approach a problem.

Excellent point. I had not thought of it like that. The way you put it makes it seem akin to learning new mathematical techniques, which is almost always beneficial in that it facilitates more possibilities when approaching a problem.

I approach the issue with the assumption that learning basic sorting algorithms and the like has very little to do with them perse'. It has to do with imbuing you with the mind frame to think along those lines - which takes time to master. As a confidence booster I've been prepping myself to internalize the material in the link below. These are all computer science concepts written in Javascript. This should blend well with your web background if you're interested.

http://www.nczonline.net/blog/tag/sorting/

Almost all of my data structure or algorithms use has been in the following three cases:

- Programming interviews

- Programming contests

- Exams

Doing well in those things is desirable to me, so knowing data structures and algorithms has been useful in those cases.

sometimes its useful for optimisation or understanding programmer motivation. (as well as interviews and tests, which are easily the most common use cases)

TL;DR - having this kind of knowledge is a double edged sword

one case that sticks in my mind was optimising come code by swapping a list for an array - the original author was perplexed because insertion and deletion were the common operations on that data structure which should be 'O(1)' (constant time) operations on a linked list and 'O(n)' (time scales based on number of elements) on an array.

my reasoning was that the list implementation stored the nodes in an array and the corresponding inserts and deletes did those same array operations underneath - hence rendering that particular list data structure useless - it had all of the worst case characteristics of both the list and the array, and none of the benefits of either.

i might have been able to work all that out without knowledge, but knowing the ideal performance characteristics of arrays and lists made it trivial to debug and optimise.

its worth noting that the same kind of knowledge is what motivated the original author of the code to use the list data structure.

also worth noting that a lack of such knowledge is what allowed such a useless implementation of a list to begin with.

Data Structures and Algorithms are like fundamentals in basketball. Everyone loves Michael Jordan when he's changing direction mid-air, drawing the foul, and laying it in. But the reason he was such a threat is that he had absolute mastery of the fundamentals which freed him up to be creative.

With no formal background in CS and a C compiler, you'll run into data structures soon enough.

I wouldn't worry about creativity and discovery. I found that writing a double linked list was damn entertaining, I thought it was a lot like knitting. I'm looking into hash-browns and trees next.

Much thanks to everyone for the insights! You have definitely given me some good reasons to go ahead and learn it.

Source: CS major with 10 years experience in enterprise development, support and systems architecture consulting.

While it's always possible to be a development autodidact, and in fact to be quite productive this way, there's a reason why the theory and practice underpinning good software have been codified in the study of algorithms. Shortly said they are knowing your tools, knowing when to use them, knowing why to use them, and recognizing their strengths and weaknesses. And finally knowing these things instinctively, not just casually, so you can diganose complex issues in terms of understanding their larger moving parts, and not just the low level details.

Knowing your tools: Anyone who has debugged code where some critical component is based on nested arrays or other representation with similarly poor scaling characteristics, and banged their head on the desk on reading the code, will understand this one. If you aren't even aware of a possible range of workable, if not optimal, solutions for a given problem space, then you are unlikely to come up with a stable and high performing solution.

Knowing when to use them: On a practical level, it's important to know the proper use of the tools available to you (and how to recognize when one is not well suited to the task at hand). Having a clear picture of the applications where X versus Y representation or approach will perform better is critical to being able to accomplish the 'big picture" task effectively (whatever that may be). Recall that nearly all mathematical and CS proofs will refer to other, more well-known concepts in establishing newer concepts; in the general case the proof of any given algorithm's workability can be expressed in terms of its reduction to another well known, well understood solution. The same is true of your code using a well known library that implements any one of these.

Knowing why: Similar to "when", but a little more nuanced. On a philosophical level, it's useful to separate the problem-solving aspect of the job from the creative aspect, and avoiding re-inventing-the-wheel when it's not needed to solve your unique problem (hint: it's probably not that unique). In other words, if you have a finite budget of mental effort to expend upon a given programming task, you'd be better served by ensuring you meet the low level requirements of its implementation with an algorithm that you understand intimately, than laboring through a hand made solution for a problem whose details you might not know anyhow. (Of course, see also "if your only tool is a hammer" -- laziness is useful, but only to a point.)

Instinct: Experience goes further than simple knowledge, because the units in which you "think" are constantly changing. In the same way that a chess master sees more possibilities and nuances in the opening moves of a chess game than a novice can see in individual pieces, a novice or even skilled autodidact can not bring to bear the same skills as an experienced programmer with intimate working knowledge (if not extreme detail) of a wide range of possible approaches to a given solution.

Finally, consider that nothing I've written above precludes "creativity" -- it simply provides you a tool kit that moves the bulk of mental effort to a higher level of execution.