Helping junior programmers get past their shortcomings?

Question

What are your common gripes about junior developers that join your team or whom you have to work with? Obviously they are inexperienced so you can't expect them to know everything, but what skills are often inexplicably missing -- and how, specifically, can we help them build up these missing skills?

I don't mean inter-personal skills like 'listening to advice,' I mean technical matters like (if applicable):

• 'you've never done SQL?'

• 'you've never written a unit test?'

• 'you don't know how to use a Unix command line?'

Things which you do expect - I'd like to hear your observations and techniques for teaching new programmers to get past these specific shortcomings.

Answer 1

Not knowing what version control is, or how to use it properly.

One of the junior developers who has been at my company for several months recently had to get taught the very very basics of Subversion. It really made me cringe... she's been checking in code to live projects the whole time... and had no idea what she was doing...?

Answer 2

Not asking enough questions

I know they're juniors, I expect that they will make mistakes and just not know things. So many royal f**k ups could have been avoided by just asking a question instead of assuming something. Honestly, I can't be pestered enough.

I had TONNES of questions when I started out - asking them saved my arse on a number of occasions. Hell, I still do have lots of questions... I just like to think they're better questions now.

Answer 3

Believing you're the first to encounter a situation.

Every programming problem you face has been faced by others, in some general form. There is so much to learn from experienced programmers. I'm old enough to remember programming before Google, and it sucked. It was even worse when we had search engines, but there just wasn't that much good information on the web yet. Programming now is so much more productive because you have access to global knowledge in seconds. People who don't use it are ignoring it at their peril.

Edit:

Just to be clear, I'm not advocating copy/paste programming. I'm certain, however, that you need to review the existing knowledge before you can make good decisions yourself.

Answer 4

Copy paste and trial and error instead of seeking to understand the underlying fundamentals

Many junior developers will copy code that looks close, then almost randomly try different permutations of modifications by brute force until they hit on one that works. If you don't know why it works, chances are you are introducing bugs in the boundary cases that someone who does understand it will have to clean up later.

Keeping their "first draft" of code

When an experienced developer writes a new function of a certain complexity, they start out with a stub that does nothing but compile, then rewrite to add high-level pseudo-code comments for the overall algorithm, then rewrite those comments one at a time with actual code, adding and removing dummy code as needed for testing, then rewrite to remove redundancy that emerged during the implementation, and so on in a series of successive and incremental improvements.

Junior developers have a tendency to write it in one big chunk, then do massive brute force debugging. They don't like to delete a line of code once it is typed into the editor, and are so happy they finally got it to work that they are loathe to rewrite for non-functional improvements, but they are the ones who need to do so the most.

Answer 5

Thinking that they know everything.

I had a jr. intern who tried to solve everything with javascript. Tried to explain several concepts, but he always thought he could do it better. Now he quit and im reworking a major program he built for print output using HTML instead of a print ready technology like PDF. Not to mention a pile of other major problems.

Lesson is to ask seniors for major overarching guidance early in a project, dont go off architecting without help. You can write the code and details alone, but make sure you at least use the right technology.

Answer 6

I rarely get annoyed when juniors don't know the basics, they are not taught industry skills such as SCC in University. It's the senior devs job to teach them. I only get annoyed by personality clashes. But I get most annoyed by senior devs who don't know the basics.

Answer 7

Not wanting to advance their knowledge -- taking the path of least resistance instead.

The other day an intern along with the graphics designer (who is surprisingly skilled in programming) asked for help because they ran into trouble implementing something in jQuery -- closure can be painful if you can't see it coming.

I sat down with the intern and explained exactly what was going wrong and why. We fixed the bug, then I pointed out several additional improvements that could be made ("since I 'm here") and we ended up rewriting the guilty function in 10 lines instead of 20 and without bugs. After answering any questions, satisfied that everything was OK in the world once more, I left.

The next day, the intern came with a question that revealed he "um, wanted to make some changes and rewrote the function my way because I found it hard to understand" (for the most part undoing my improvements).

He could either have tried harder instead (asking additional questions, reading up on the concepts I mentioned) -- code so short cannot ever be that hard to understand -- or take the easy way out. It saddens me every time I see someone do the latter.

Answer 8

Not understanding OOP. Sadly this is way more common than most of us probably realize.

Knowing how to create a class, abstract class, interface, or even knowing polymorphism is one thing; understanding how to properly use them to the benefit of your program is another.

---

If you want to avoid this one, I found these questions and the answers to them enlightening:

• Code Smell: Inheritance Abuse — The perils of inheritance
• Where does this concept of "favor composition over inheritance" come from? — The perils of mantras about avoiding inheritance

Answer 9

Not knowing what you don't know, and in ignorance thinking you know everything.

(And its close cousin, not wanting to ask.)

Partly this is an organisational thing - an appropriate incoming induction would go a long way to preventing some of these things becoming issues. But very few companies have time or people available for an incoming induction - something that should take anywhere from a few days to a few weeks and takes developers off their work. So we have to put out the fires instead.

Answer 10

I'm amazed at how many junior programmers relatively fresh out of a CS program are weak with algorithms. Poor algorithm choice may not really stand out in line of business applications, but when processing billions of web service requests a day, it really does matter.

Here's an interview question I use that almost all Junior programmers miss that highlights the issue:

Write code that calculates the Nth Fibonacci number.

They almost always go for the most write the obvious-but-inefficient

int Fib(int n)
{
    if (n == 0) return 0;
    if (n == 1) return 1;
    return Fib(n-2) + Fib(n-1);
}

When asked to comment on the algorithmic complexity, I usually get "it's worse than O(N)... uhm... O(N logN)". It's actually (much) worse than that...

Answer 11

Doing backwards code indentation!

Of course it's not very "typical". I could never believe it was even possible, but what a normal developer would write like

try {
    switch(action){
        case case1:
            ...
            break;
        case case2:
            ...
            break;
        default:
            break;
    }
}
catch(Exception e) {
    e.printStackTrace();
}

she would write like (God, it still seems impossible to me!)

            try {
        switch(action){
    case case1:
...
break;
    case case2:
...
break;
    default:
break;
        }
            }

Frustrating isn't it?