Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Possible Duplicate:
Should I keep investing into data structures and algorithms?
I'm a CS student. I want to become a really great programmer, what do I need to do to be come a great programmer? Other then writing lots of code, I've heard that studying algorithms and theory (logic!) is help. What do you recommend to become the best? What do I need to read? What do I need to study?
Programming is as vast and diverse as there are programs. You could have a very fruitful career without ever having to worry about algorithmic complexity. I have been developing database type applications that help save lives everyday yet never had to compute the BigO notation of anything I produced.
This said, algorithmic is an important part of the domain and can be a good asset if you learn it. Learning it will open your mind to certain problems you could encounter, on how to measure it and it will teach you some common patterns you can use to solve them.
So yes, the study of algorithmic will make you a better programmer this I am certain of.
I think a more important question you should ask yourself at this point is what kind of problems you want to solve as a career. Knowing this will help you getting the right tools to give you a head start. Algorithmic is an important theoretical tool to have, but so is cognitive ergonomics, architectural patterns, information theory. There are also many down to earth knowledge such as learning the different patterns in the Software development process that are often frowned upon as boring and uninteresting while learning the trade yet play a crucial role when creating software in the industry.
This was by no means a comprehensive list but all are, in my experience, equally valuable in making you a great programmer. It all depends on the problems you wish to solve with programming and the approach you wish to use to solve them.
--- EDIT --- As Earlz mentioned in the comments after you learned the skills they remain with you all the way. So even though I never did a complete in depth bigO analysis of a system the knowledge remains available, I guess it gives you a supplementary sense by which get a feel for a system. I once came across a simple logging system whose implementation ran in factorial order. I think had the programmer learned about algorithmic complexity he would have noticed that and coded away from it instead I got the old rhetoric "it's just logging, it does not affect the runtime". Of course he was not the one that had to tell the customer they had to wait approximately 6.4 billion years before their data import would complete.
This would be true for pretty much all of such fundamental body on knowledge. Even though you do not actively use it the knowledge gained remains and influence your daily tasks. Learning a specific language, methodology or system is good for the short term but is doomed by obsolescence before you even opened the book.
To become a real programmer, you definitely need to study algorithms to at least some degree. There's a lot there that isn't crucial to programming, but without at least a reasonable amount of knowledge, you're pretty much sunk.
There are a number of classics in the field, most obviously:
Personally, I tend to prefer Knuth, but both are entirely adequate, and the other covers more in the way of newer algorithms (though the newer edition of Knuth is undoubtedly better in that respect as well -- I haven't updated my copies since I bought them somewhere around 30 years ago.
Absolutely essential. Central. Nothing matters more.
Some people claim that they never make use of the junk they learned in Algorithms class.
Yet, weirdly, they seem to know when to avoid nested loops and make use of pointers.
So, they can claim they never made use of it. But it clearly influences their coding.
Study data structures. Knowing the right data structures is a great help in knowing how to organize a program, and the applicable algorithms tend to follow from them.
E.g., learn to understand from specifications (of a single function or an entire program) if you can keep data in an array or whether you need a hash table, tree, etc.
Also, know your libraries; modern programming languages tend to organize their libraries around data structures such as arrays/vector, sets, maps, etc. You may never have to implement a red-black tree yourself, but know when you need it and which part of the standard library implement one (or a similar structure in terms of performance).
Depends on what you mean by "great programmer." I'd (arbitrarily) divide greatness into three equally bins:
Ideally, we'd all like to be all types, but that's not generally possible. The place where algorithms and theory will really help is the first sort. As a computer science researcher, I use that all the time, type 2 expertise less often than I'd like, and type 3 rarely at all.
As for a reference: The CLR algorithms textbook is a classic, and a good read. There's probably some class uses of it online that present well --- try MIT OpenCourseWare. The most important thing, IMHO, is to get a strong intuition for asymptotic complexity. If you do so following the path laid down in a text like CLR, you'll also end up with a basic literacy of data structures and algorithms that will serve you well.
How is a great programmer measured? How do you want to be measured?
The answers you give for these questions might help influence you today, but they will continue to come up again throughout your career.
Having technical proficiency will certainly be fundamental to achieving success. However, in order to distinguish yourself, there are options. There is often more than one path to nearly any destination. Perhaps becoming a great programmer can be achieved by a superior ability to dissect and digest a domain and a cross study of a particular domain now might help. Perhaps it can be achieved in a less specific manner, through an indispensible ability to identify user intent through an understanding of psychology and sociology. Perhaps instead it comes knowing more about business: being effective at marketing so that you know what people want before they are even aware that it can exist, and then convinving them they not just want it, but depend on it. Perhaps it is something else.
The advice I would give is that while programming might be a craft you hone, don't purposefully omit a deeper study of other fields where you have a natural talent or interest.
This is a little difficult question to answer, especially as we get more and more powerful abstraction/libraries there will be little need to learn these things.
Phase I:
Thousands of business executives can continue to program on a tool called Microsoft excel even without knowing they are actually programming. They can continue to define a work flow(heuristic), sort data, manage data, query data. Automate their tasks and what not even without knowing a word of programming. Excel figures out what the right algorithms are for them when they sort and search.
Now how do you sell the idea of algorithms to them?
Phase II:
Back in the day, do you remember it would be impossible to implement any decent application without actually remembering the API. You had to either remember them or keep looking them up in the manual. Ctrl-space in eclipse has largely eliminated the need for any such thing today.
Phase III:
In the near future IDE's and tools will have intelligence to suggest what solution(algorithmically) would be more appropriately for you based on inputs you give to it. Or there might be functions like sort() et al. Which will intelligently workout what algorithm you would need looking at the time and space complexity.
Water bed theory of complexity:
Abstractions are winning big time, you need not have to worry about a level of complexity which is already handled by the library or the language. Everytime a abstraction is invented their is lesser need to have a look at the complexity below it.
