Back when I was still studying computer science, I lost interest when we started working on algorithm analysis. It wasn't that the material was difficult but that I was too busy ****ing around to spend the time studying it.

What I wanna ask though, is how important is it to the everyday programmer? Do you use it often or is it concept that gets embedded into your programming habits without real thought towards it? Any comments would be appreciate as I wanna get back into programming but don't know where exactly to start.

Algorithm complexity and "big O" notation are pretty important to know about if you are doing any real programming (possibly not so much if you are just gluing bits of GUI together or something basic like that though).

It can be the difference between having something totally unusable taking minutes/hours to run and knowing (or being able to devise) a clever O(log n) or O(n log n) method of doing the same thing taking seconds / real-time. Same goes for memory consumption (although that is less important than it used to be).

Also, having some understanding will help you avoid common noob pitfalls at the design stage like trying to solve a variant of the Travelling Salesman Problem, wasting a few days writing your code, and then wondering why it's taking forever and/or just never terminates.

There is a lot of other theory and discrete maths that you'll learn in the first year of your Comp Sci degree which will never actually be any use (to a programmer at least), but a decent "arsenal" of algorithms and knowing something about algorithm complexity is essential IMO.

Juk

When interviewing developers we always made sure they understood the concepts of runtime analysis - but didn't care that much about knowing correct terms or analyzing super complex functions.

Complex algorithm analysis is rarely that useful in writing actual code. The reality is that its often easier to just implement something correctly and simply and not worry about the performance of the algorithm. If performance is a problem profiling the entire system is usually much more efficient than trying to find algorithms and come up with optimal algorithms.

Edit: To be clear, I'm talking about complex analysis. If you've got a developer nesting loops everywhere because they don't understand anything about how to measure efficiency - you've got a big problem.

Our last upgrade had run about 24 hours when the engineers started looking for optimizations, one fix and the run time dropped to about 10 minutes... The biggest cause was probably moving from a couple hundred users to 15,000 which hid the lack of index using during the upgrade...

Disclaimer: I never learned algorithms or analysis during college

I have picked up a little bit along the way, although I'd surely embarrass myself if I tried discussing it with someone educated on the subject. It's my feeling that it's more important to understand what kinds of things will cause problems (ie, nested loops), and if you see such a situation coming, figure out a way to avoid it. It's also, in most cases, better to solve the problem and then optimize if there's a problem

Disclaimer two: I don't do "real" programming, I'm only a web programmer that glues bits of UI to a database

These are the most dangerous programmers.

I need this inventory browser to be fast and reflect each user's permissions - I'll just load every item we sell, filtered by permissions, into the user's session whenever they log in. Brilliant!

A real-life example from my job. We have a reports system (obviously). It also pages, 100 lines per page (less obvious, but it's an Ajax app, so it needs to be somewhat responsive). When we filtered the reports, we loaded the 100 items from the database, and THEN applied the filter, leaving a random number of items per page.

No, I did not code that. Yes, I fixed it.

Thanks for the information guys. Any useful reading you can recommend?

http://www.amazon.com/Algorithms-4th...tt_at_ep_dpi_1

Juk

Agreed - one of the big benefits of learning how to analyse algorithms is so that you know not to make certain poor decisions in your everyday coding.

I helped optimize someone's web script that had a nested SQL query that was looping thousands of times. With a background in analysis, you just won't make that sort of decision in the first place.

I'm an algorithms researcher applying for jobs right now. There are plenty of companies hiring algorithms people almost entirely because of their ability to create clever algorithms and understand their run times. I don't think it is too critical for most programming jobs though.

Basically...it depends on what you want to do as far as how comfortable you should be in the analysis of algorithms.

I am not a developer (though I am technically a Lead Developer at a company). I am best at solving algorithmic problems. The day I learned to look at everything as a language-agnostic algorithm first and a product/service second is the day I became a reasonably competent developer.

Your mileage may vary, but that's how I approach development now.