I have new junior programmers (new graduates) who just joined my team, some of them do not know much about algorithms and design patterns. I am not sure which one should I teach them first?
|
migrated from stackoverflow.com Jun 15 '11 at 6:52
My vote goes for Algorithms. Because algorithm is the main logic of a functionality once you know the algorithm you can easily apply that logic in any design pattern. Main logic is independent from design pattern. |
|||||||||
|
Let me be the odd one out and say design patterns. They should have SOME programming knowledge I'd say, and specific algorithms can be taught when they are needed, or discussed with seniors. Knowing some design patters (especially the ones you are using in your team!) would stop them from making expensive mistakes that a lot of beginners would (for instance: a lot of procedural code, messing up your MVC-patter, etc etc). Explain them some basic logic about patterns, what you use and the specifics of the most used patterns. Then see if there are any algorithms that come to mind. Don't go mindlessly teaching them how to make binary trees. There is ofcourse a difference in situations, but I'm assuming a junior is not in the position to do the very most crucial things. In the beginning any algorithm work might need brushing up, but they can pick it up as they go along. An algorithm can be 'bad' but fixing that and in the process teaching what you should've done is possible. On the other hand, if you work in an environment where strict patterns are used a novice can -even when adding a simple feature, or cleaning something up- seriously damage the structure by adding stuff in the wrong place and messing up the concept of one of your used patterns. This would not only mean a rewrite of his/hers work, but also trouble for other programmers as their work gets harder. I do wonder what they did actually learn from their graduation? I want to add that if you dislike patterns etc, especially in the case of novices overdoing them, you definately need to teach them correct use (aka: when not to use or how not to use) patterns first. Before you know it you have half a pattern-design book implemented while you didn't want it. You still need to teach them patterns first (not "this is pattern A, this is pattern B" maybe, but the subject is still patterns) before you go starting to mindlessly teach them algorithms. |
|||||
|
Depends upon what you are trying to do, and what tools you are using to do it. For instance, for a basic web application using a high-level language like Java and a prebuilt web-framework like Spring, then in-depth knowledge about algorithms is not generally required (want to sort something efficiently, just call But if you're building a multimedia processing application in C then algorithms may be at least as important as design patterns. |
|||
|
More basic than either. Coding style. I would start them off with Code Complete and go from there. |
|||
|
It really depends on the nature of the work they'll do. If it was a general question I'd say Algorithms, though. |
|||
|
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> |
|||||
|
AlgorithmsMy 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. |
|||
|
They're two separate things. Algorithms are low-level theory, design patterns are high-level practices. They don't intersect much. |
|||||||||
|
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. |
|||||||
|
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. |
|||
|
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. |
|||
|