How to choose, motivate & develop a newbie programmer?

Question

Imagine that you need to hire new programmer, however you are 100% sure that there are not experienced (what you need) developers on the local market and you need to work with newbies. A couple of months ago we hired such developer with the clause that he will learn & learn to satisfy the needs of the company however that did not happened and his progress is disappointing. Anyway he is leaving in two weeks and we will need a new one. It is important to mention that we have a policy for 6 months test period which I cannot change.

My idea was to hire not 1 programmer for six months, but 2 programmers for 3 months and make it like a game -- set goals, make a competition, set a final test and choose the better one the other one will leave (in the best scenario we will have 2 good programmers :) -- basically the issue is with the lack of quality programmers we can find on the local market and outsourcing is absolutely not an option, I suffered this before).

Do you have any ideas how to motivate the future programmer to become the greatest one in the universes within 3-6 months? I need quick results in short time or the Director will say "This one is not good enough, we need another one." and everything will start over (which is such a pain).

Answer 1

Programming isn't really a discipline where pure competition works well. You can get much more trying to foster cooperation than competition, so I don't think hiring a couple of people instead of one would do the job here.

If you want to develop newbie programmer you need:

• Right attitude. Generally speaking people don't want to learn, which is sad, but it also means those who do usually really shine. And learning attitude has nothing to do with current skills - it's just attitude. That's something you should look for during interviews.

• Someone to learn from. It may be colleague from the next desk or mentor withing the organization or manager or pretty much anyone who suits the role in a way you wish. Ideally let them work together, but the least you should do is to get a "teacher" enough time to verify work delivered by newbie guy and share some ideas on possible improvements with them regularly.

• Time to learn. Frequent failure in terms of self-development is expecting people would grow and not giving them time to spend on learning. We can't expect people would become rock star programmers when they have virtually no chance to learn anything as they're buried under loads of urgent work.

• Learning sources. Most likely this one is trivial as there's a lot of great stuff on the internet on pretty much any popular technology. However if you think about some very narrow technology with limited user base you may need to support it with other means of training.

• Clear expectations. You shouldn't forget about setting clear expectations either. As long as I'm not told my primary goal is to show decent learning curve I might focus on something else. If I fail at learning you probably want to get rid of me anyway but that's another story. Expectations should be set very clearly.

In short: find the person with right attitude and give them help in their learning effort.

Answer 2

First things first: You need to hire someone valuable. This means somebody who is smart and get things done. No better reference than this article: http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html

After that, you need to invest in his/her learning. If the newbie is all alone after you hired him/her, his/her motivation will not last long. Train him, give him motivating tasks, and not just some junk work, and things should work out just fine.

Answer 3

I believe you are setting out to fail, by putting a great deal of pressure on the poor guy (or girl). If there are no good people locally, this could be for one of a number of reasons:

• There are genuinely no suitable people... without knowing your environment, I can't comment on the likelyihood of this;
• Your organisation is not attracting the right people. This could be reputational, financial, or the industry is not attractive.

Why not consider a completely different approach? - hire a contractor for a few months, and see whether this gets the job done. This isn't outsourcing, at least in my book! If this works out, then you have a technical result that you want - admittedly without a new developer for the future. If it doesn't work out, perhaps you're expecting miracles, and a newbie would have no chance no matter how good he or she was. You're looking to make the new person the "greatest in the universe" in a few months... forgive my bluntness, but that just doesn't seem realistic, and you are doomed to disappointment after disappointment if that's truly what you are expecting.

Answer 4

Pair Programming may help here. Try to pair more experienced people with less experienced.

Answer 5

Pawel has provided a very good answer, but it is missing an important concept: environment. You need to choose newbie characteristics based on the type of environment you're going to place them. If they are going to be thrown into the shark infested deep end of the corporate pool to develop software, you should hire based on survival instincts. If it is a team focused environment, personality often far out weighs skills at least until you get to the bottom quarter of the bell curve.

Developers are not interchangeable widgets. They have a fairly diverse personality set and will react differently based on their personalities and the environment around them.

And, if you are hiring for a competition, insure that personality won't disrupt the rest of the organization of the competition is done. I've found that overly competitive developers tend not to play well with others or tend to focus on the wrong aspects of the project (short term visible goals, not long term strategic paths).

Answer 6

I think it's deeply unfair to the developer that does NOT get the job. I would never take a position where my longevity was dependent on "beating" another coworker in some kind of competition.

Do you really have the time to create a complete curriculum, along with a final test? Is that the best use of your resources?

If you are having trouble finding local candidates, consider telecommuting as a way to expand your pool. If that's not an option, take a long-view approach. Tune your business practices to the long, hit-and-miss process of grooming local newbies. Introspection and understanding your own strengths and weaknesses as an organization will help. If you know what works, and why it works, you can teach it.

Finding those that want to learn (an excellent point by Pawel) is the hard part of building a development team, no matter the location, size, or quality of your hiring pool.

Answer 7

Nothing is a substitute for relevant experience.

This is a quote by Chris Sterling in his book Managing Software Debt: Building for Inevitable Change. His point is that for anyone to be successful in software development, they need to be provided a chance to gain relevant experience (domain, technology, etc.). The people who have that relevant experience need to share it. Six months should be plenty of time.

In a chapter on managing Platform Experience Debt, the author reaffirms your experience that "When the gap between those people who have substantial knowledge about the technology and the domain and those who are novices is too large, pairing alone probably does not suffice”. He proposes that knowledge sharing activities and collaborative team configurations are two ways in which organizations can deal with the type of problem you’re facing.

In terms of knowledge sharing, I think training programs may be the best option for you. I've had good success with a couple different approaches in my organization. The first is Tech Labs where anyone can bring forth a development issue they're facing and have some of the more senior team members consult them on the problem. They do this in a group forum so that other people who come across the issue may learn how to deal with it. This also allows specific examples of issues to be identified as anti-patterns, where appropriate, so that better design patterns can be adopted in the future. The second is the standard Brown Bag session, where people convene over lunch to learn about a topic that’s new to them. The brown bag topics we've held typically focus on principles that the team members can then put into practice.

Team configuration can also have a huge impact on the success of new team members. For example, you may not want to set the expectation with the new person that they are to be generally knowledgeable about the entire application they're building. Instead, you may want to arrange for them to focus on a specific component, providing them an opportunity to gain confidence and incrementally increase their domain knowledge. Other configurations may include:

• Make the new team member an SDET initially so that they have a chance to understand and test code that is being written by others
• Give the new team member a refactoring assignment to gain familiarity with the code base before taking it "head on"
• Stand up a mentor who spends 50% of their time providing hands-on support to new team member
• Stand up a community of practice around certain specialized areas where there isn't a general distribution of knowledge, in which new team members can participate

Answer 8

My opinion is that your method is not adapted for finding promising programmers to enter the program, nor to make newcomers adopt a good learning curve.

1. first, the economic context is good for programmers in most places. (full disclosure : I work as an associate professor in computer science/engineering, and a consultant in PM) Most of my current students (we are in june, they are completing their BsC and MsC in september) already found a job (mostly as programmers for BsC students). In fact we have far more job offers than students. Offering a competition, thus the risk of not being confirmed in the job with probability 50% is not good enough for young programmers in this context.

2. Let's do what a PM should do : let's pretend we are these guys.

When two programmers discuss sufficiently together, they will quickly know who is the most capable amongst them.

Imagine that you are the worst one: why bothering to work hard and learn, you already know it will be a failure: if the other one spent the same time as you do, he will stay above you. The best thing to do is to make your CV and to search for a new place.

Imagine that you are the best one. If the only incentive to have a good learning curve is to be the best, you don't need to do that since you are already this guy.

So in both cases, no need to be competitive...

I think you should find another way to motivate ONE very good potential. To find this guy, spend a lot of time, with the assistance of a tech guy from your organization. Then make sure that the newcomer understand that if he learns quickly in the firt 3 or 6 months, he will be very well rewarded (money, time, responsibilities, interesting projects).

Once this is done, mentoring is the best way to make sure that someone will learn efficiently (the mentor gives orientation in the training, fastening the process by separating the wheat from the chaff - what must be learned from what is not important).