Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

closed as not constructive by Mark Trapp, Pemdas, Jonathan Khoo, ChrisF Apr 8 '11 at 9:19

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

13  
Single most irritating thing: constantly asking about what's irritating. :-) –  Jerry Coffin Apr 8 '11 at 0:06
11  
I don't think you should be irritated when people don't know things you'd expect them to know. What's important is that they're willing to learn =) –  koenmetsu Apr 8 '11 at 7:20
7  
I don't like this question, it has the wrong mentality for a developer. WE WAS ALL ONCE that newbie, and everyday we are a newbie at something. I would NEVER get irritated over someone who does not know something. This feels that there is too much arrogance involved.... –  Darknight Apr 8 '11 at 8:06
1  
+1 Darknight. I agree. –  Joset Apr 8 '11 at 9:18
3  
Oh, closed, BRAVO. I read the six guidelines consstructive subjective questions and this fulfills all of them. Frankly the nonconstructive part is busybodies closing a thread that 13 people have already answered, just because they misunderstood the question. It is simply a reality that senior developers will sometimes be disappointed in the abilities of junior developers, this question only seeks to find any patterns in this disappointment so we can better avoid difficulties. Ignoring legitimate complaints and criticism doesn't benefit anyone and it's got nothing to do with arrogance. –  Andrew M Apr 8 '11 at 9:38

11 Answers 11

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...?

share|improve this answer
4  
Cringe? She's lucky she still has a job. –  Rein Henrichs Apr 7 '11 at 23:15
2  
This seems like it's more a matter of "not knowing what you don't know" or "not admitting what you don't know." Had she asked for help from the start, would it have been a big deal at all? –  Michael McGowan Apr 8 '11 at 0:24
1  
ouch, it sounded like me haha, we didn't implement version control until lately, and I joined the company as fresh grad, I did learn a bit of version control and subversion kind of thing in University, but never implementing it before. –  Phelios Apr 8 '11 at 1:17
1  
"That's the tool for backup isn't it ? You use it to save your code every evening ?" –  David Apr 8 '11 at 6:50
2  
It is one big thing that they nearly never teach you in school –  Elijah Saounkine Apr 8 '11 at 7:40

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.

share|improve this answer
    
Gee... almost the same answer I posted, you go in about 5 seconds before. –  quickly_now Apr 8 '11 at 1:41
2  
"you are annoying !! I'm busy here, can't you think by yourself?" if you are unlucky!! haha –  Phelios Apr 8 '11 at 1:56
4  
+1 - A subcase of this is not asking back after an explanation. It did really piss me off when I explained some task to a junior, he nodded, I thought he got it and would get to the job, then two weeks later he comes back, asks the same questions again, nods again, then another two weeks later... Fair enough, it was not a trivial task, but for God's sake don't pretend you understand it if you don't. And if you think you understood something, make notes so that you remember it two weeks later. –  Péter Török Apr 8 '11 at 7:41
1  
Some people, on the other hand, ask too many questions (on Stack Overflow). –  BoltClock Apr 8 '11 at 12:01
1  
@SnOrfus: Those unqualified ones are who I'm referring to :P –  BoltClock Jun 8 '11 at 4:43

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.

share|improve this answer
1  
+1 - Many sr's make this mistake too. –  P.Brian.Mackey Apr 8 '11 at 1:41
1  
Well, also you don't want the developer to copy-paste all of the code from some doubtful resources from the Web. Searching is good to get some ideas, maybe solve some fundamental understanding issues, but never to get ready solutions. It also makes the developer dumber; maybe it makes him a good collector, but not an inventor. –  Elijah Saounkine Apr 8 '11 at 7:39
    
I agree at some point with Elijah, copy-pasting code without making time to learn what it does, doesn't accelerate your programming skills. Worst, it will take over and become a bad habit. –  Joset Apr 8 '11 at 9:34
1  
Sure, but @Scott didn't say anything about copying and pasting code, he just said don't assume you're the first to encounter a situation i.e., realize that there may be some information and experience out there you can benefit from. Example: I want to know if two strings are similar. Is there already a known algorithm to solve this problem? Imagine if a developer just decided to start rolling their own without even being aware that answers already exist. –  David Conrad Apr 8 '11 at 11:44
    
@David Conrad that's right, point taken, we are on the same page here. –  Elijah Saounkine Apr 8 '11 at 12:24

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.

share|improve this answer
1  
+1 for "copy and paste instead of seeking to understand", although of course this is not a problem unique to new programmers, just to bad ones. New programmers at least have a chance of growing out of it - the guys i work with who have been programmers for decades and still do this don't. –  Tom Anderson Jul 10 '11 at 9:46

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.

share|improve this answer

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.

share|improve this answer
1  
@Graig is right many things which annoy us seasoned developers regarding juniors are things we had to learn not at a university but in a commerical environment. –  Nickz Apr 8 '11 at 3:31

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.

share|improve this answer
    
Interesting, I do wonder though if possibly you did make it allot harder to read. I remember my first project manager doing this a couple of times (and me being guilty of changing it back also) While I'm sure in retrospect his approach was better I was simply not advanced enough at the time to understand why and how it worked. –  Maxim Gershkovich Sep 27 '12 at 7:22

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:

share|improve this answer
    
Like on a basic level, they don't know what you mean by creating objects, classes and inheretence? Or more advanced stuff like using the design patterns (you've got to admit, the GoF book is quite abstruse, although there are of course other books/guides) –  Andrew M Apr 7 '11 at 23:05
    
@Andrew I've expanded the answer a bit. –  NickC Apr 7 '11 at 23:08
1  
And I see the converse: not knowing how to write plain old procedural code in C because of only being taught OOP. Then again, don't get me going about people who are not taught to write parsers any more because they are told all those problems can be solved using lex and yacc. –  quickly_now Apr 8 '11 at 1:38
1  
@quickly_now That's a good point, though writing code other ways than OOP and writing bad OOP are two totally different things. The first, I don't have a problem with. –  NickC Apr 8 '11 at 3:53
    
Most universities do not teach object oriented design. Also many work places work like silos even with junior developers...or have "senior" developers who do not know object oriented programming is. There are "senior" developers who got the title from working x years and senior developers who know their stuff.... –  Cervo Jul 10 '11 at 14:33

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.

share|improve this answer

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...

share|improve this answer
1  
to answer your question about compleixty, one shouldknow that formula to calculate fibonacci numbers without recursion, which he would use instead of recursion in the first place. –  Pavel Shved Apr 8 '11 at 7:02
1  
@Pavel: There's an O(n) and an O(1) solution... in fact Like every sequence defined by linear recurrence, the Fibonacci numbers have a closed-form solution. en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression –  Eric J. Apr 8 '11 at 20:48
1  
I'm not saying that the solution you posted is perfect. I'm just questioning the relevance of your follow-up question to such a solution, the question about complexity. What do you want to achieve by asking it, and—most importantly—why do you expect that what you wanted will be achieved given the answer to the previous question? (Did I make my point?) –  Pavel Shved Apr 8 '11 at 21:05
    
to make my point more clear, I'd suggest you asking about how the code could be improved instead of asking to estimate the complexity. I'm sure that some CS graduates would propose memoization, or say that they know the formula but didn't want to show it at once because you'd think they're smartasses. –  Pavel Shved Apr 8 '11 at 21: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?

share|improve this answer
    
What in the name of... –  billynomates Apr 8 '11 at 9:12
1  
It's very amazing!!! –  javanna Apr 10 '11 at 22:26

Not the answer you're looking for? Browse other questions tagged or ask your own question.