What should a programmer learn first: Algorithms or Design Patterns? [closed]

Build a smart team that gets things done

Quoting one of Joel's books a little, I would advice to have the new team members solve a task together, to build kind of tool that you may need internally anyway. This is an achieveable task and if it really goes wrong, the risk is limited.

After that, you do a post mortem review togehter and discuss all the things where they are strong and the things where there are weaknesses. Analyze and develop an action plan from it, what they need to learn now, and later.

Follow-up regularly to make sure they are making progress and to adjust the course of action.

Neither.

First you teach them how to program by making them understand what their code does and how to execute it in their head. You teach them a specific programming language with simple examples. This is analogous to basic vocabulary in a spoken language.

Next you teach them how to design. How to split things up into functions and composable units. Make them create lots and lots of interfaces and figure out which break and why and which don't. This is like grammar, it is a bit fuzzy and there are exceptions to almost any rule but you still need to get a general feel for what works and what doesn't.

Algorithms in most cases are solutions to very specific problems. "If you want insert and remove in O(1) use a list not an array." This can help you speed up your program and although it is sometimes necessary to get a useful program at all mostly it is an optimization. I enjoy algorithms but I almost never need them for my job as an application programmer. If you do, this site quickly helps you find what you need. ;)

Design patterns on the other hand are solutions to quite common problems. They are like proverbs: "Don't poop where you eat." You can analyze it and figure out a couple of reasons of why they may make sense but they are basically guidelines. Things that worked for people. They can be quite useful in providing a common vocabulary for ideas and giving you starting points for piecing together your designs.

So if I had to pick I would probably go with design patterns. :) They are guidelines for what is, to me, the harder and more influential part of programming: Design, Architecture... I say more influential because if you have decent modularity changing an algorithm is much easier than changing the architecture.

I know this is a cop out, but ....

It Depends

If your company is producing custom line-of-business software, CMS/Website development, and related things, Design Patterns will be the most useful. I rarely have to implement anything close to the algorithms learned in school in my work life (but its good to know them, plus learning to implement them is extremely valuable in helping you break down everyday problems). Yes, teaching a junior programmer Design Patterns will most likely casue them to start overusing them, but if you are reviewing their code on a regular basis (you should be) then hopefully you'll be able to nip the worst problems in the bud before they become a real issue in your code base. Plus, the Design Patterns flow well into helping them write testable code and the SOLID principles that are foundational to maintainable code, which is what is really important.

Now, if you are implementing Financial Trading code, scientific code, logisitics routing code, Algorithms are probably more useful, as these fields are much more dependent on the basic Computer Science knowledge to be productive, unlike business code which feeds off more of the Software Engineering side of profession.

The most important is to start building a team. Develop coding style that vocabulary that makes you understand each other. Then move to programming principles that will make your code maintainable (simple and clear). When you reach that point you will know their potential and you will be able to guide them according to their skills. They should know both algorithms and design patterns with emphasis to the one that they will need more. Large scale design requires patterns while specific problem solving requires algorithms. Whatever you do I insist in the creation of a real team. It is the method I use and it never failed yet.

Algorithms

My personal opinion is that you should not dive into design patterns before accumulating some experience with programming in general first. To get design patters you need to have a first-hand experience of the problems they will help you solve (someone who has never needed a fire will find it hard to understand the usefulness of matches).

Algorithm (i.e., how to think in code) training is a good way to train in problem solving, and you need to have that experience in order to harness the power of design patterns.

Design patterns

Any time! Design patterns are fundamental in not only how we structure our programs but they affect the ways we actually think and discuss solutions. The earlier someone can get started with design patterns they faster they can become "fluent"

Algorithms are nice but let's face it, you can do ha helluva lot programming without ever having to implement an algorithm from scratch yourself. Knowing what algorithms are available and what they're appropriate for is a good first step for a junior programmer but I'd still say design patterns are far more important for daily work.

Algorithms tend to have far more programming "cred" then design patterns. Designing and learning sophisticated algorithms is the "cool" thing to do. In some areas you do need design and implement sophisticated algorithms but they're fewer then you think.

<rant>

I have a pet theory that algorithms vs design patterns is right-brain thinking vs left-brain thinking. Many programmers come mainly from the left-brain side of things with a deep interests in maths, science and engineering, it's very natural that they'd find algorithms more exciting. Heavy left-brain thinkers are typically stronger at a method level then overall architecture.

On the other hand we have the right-brain thinkers with a stronger aptitude for language, arts, and patterns. They might not be as strong on the method (algorithm) level but they're strong when it comes to overall architecture.

If you're going to be a good general programmer it's important that you master both left and right brain thinking

</rant>

More basic than either. Coding style.

I would start them off with Code Complete and go from there.

First, common problems.

Second, common solutions to these problems.

If your junior programmers know their language: definitely design patterns (and even before that: coding style rules ;) ).

From my very personal view: For 95% of all problems we can find excellent and performant algorithms (sorting, selecting, hashing, ...), so it's more productive to know when to use them (and which variant) then trying to reimplement the wheel.

Make them understand the basic patterns and why to use patterns. You'll have to tell them that class xy shall get notifications of state changes on class yz and they have to know, that you want them to implement an Observer Pattern and they'll have to be able to do it without further guidance.

If you have a very special algorithm, then you usually have some senior software engineer or an architect that will design the algorithm and hand it over for implementation.