How to include rookie developers into your project?

Question

We're considering teaching some employees who have either zero or general hobbyist level programming experience to take workload off me.

We use Python/Django which has some of the friendliest documentation around and a breeze to learn.

I'm currently a one man IT department for my company and I don't have enough hours to develop everything the company needs. We are not a software company, but it helps to have in house IT to automate tasks, develop customer service features, analyze data, etc.

How do you slowly integrate rookies working on your codebase? Say you have an intern - what do they do? I'm completely reluctant to let them design or develop core code as we'll be dealing with their mistakes / strange design patterns for years. As the primary developer, I'll be the one who has to work around their code.

My thought was to have rookies only modify existing code, never building core features. I can offload work to them with simple tasks after I build the feature itself.

We'd like our employees to learn / find value in the company, and we generally have people 'move up the ranks'.

Is it standard practice to teach people with general/hobbyist level programming? How does the "moving up the ranks" in a software company work for junior level programmers? When do they start working on core code?

I'm trying to decide if it's going to cause more damage than help, and or if there's a way we can use their help without potentially risking core site code (isolated environments?).

Thanks for your time guys!

Answer 1

I used to work at a software shop, where we were coding a large project (significant ramp-up time).

Rookies were treated like vets. They were assigned a technical leader and started features "on their own". The architecture style was dictated, but they were free to come up with their own clean design. The "strange design patterns" were weeded out during (daily) peer code reviews.

One mistake I have seen in another shop: assume "core" is hard and "ui" is easy. Rookies had an easier time in the core, and messed up the UI front-end code.

Good luck!

Answer 2

If you delegate the rookie to an ineffectual role he/she will never learn anything substantial, and they certainly will not be too terribly useful to you.

Let me give you a word of advice, my first IT job out of school was at a relatively small manufacturing firm where I was going to be working on software to assist sales engineers in writing quotes for various projects. I was also supposed to assist the IT guy who single handedly managed IT for the whole company.

The guy was a stressed out overworked mess, and the worst micro-managing perfectionist I have ever worked under. I was supposed to lighten his workload but he spent almost as much time worryingly checking up on me and my work as I was spending working (he almost never left the office, I think he despised his family). If I made so much as a single mistake he would completely lose his mind and start throwing a tantrum about, "I knew I shouldn't have trusted you with this, it was too important!" and other rants.

The point I am trying to make is to NOT be that way. Not only will it make the rookies miserable and destroy their morale, you will be burning the candle at both ends worrying about their work.

Give them a chance to prove themselves but have formal technical specifications, design reviews, and code reviews. Also you can test what they produce to make sure it meets requirements.

I think you will be surprised how capable some of them can be.

Answer 3

How can your company afford to take time away from other employees, but not hire someone with programming experience? The amount of your time training, trouble-shooting and hand holding along is costly.

The only thing I've ever done in this area is to teach people how to use a report writer or maybe some VBA/Macro code for Excel. I usually give the data sets to reuse. Having them learn SQL is a stretch, but I've seen it done (Paid for them to get outside training.) Most of these people were financial analysts who have the ability to learn to code, but may not have taken the time. Trying this with some people in operations is a long-shot.

Make sure you get the right person and they really want to learn to code. You won't have time to teach them everything. They'll have to do a lot on their own.

Answer 4

You want to start by giving them small, discrete pieces functionality to implement. Define the input you promise and the output you expect, and let them connect the dots. And then use team-lead code review to ensure quality, and peer review to train them to learn from each other and to teach themselves.

This assumes that you have an overall application architecture that allows for atomic units of logic to be built in a decoupled way. If not, you're headed for a world of grief as multiple developers work in it--that would be the case even with old pros.

Inevitably you'll have certain people who take to it, learn quick, and rise up. Make sure you keep feeding them tasks that are just a small step beyond their current capability. Nothing educates somebody like a task that starts out impossible. Inevitably you'll have some people who try and never really catch hold of it. Those people should be thanked for their efforts and gracefully transitioned to something else.

Answer 5

@louisgab was right about code review. That would be my first step too. One critical thing that will hel you is to make sure they have to fix thier own mistakes whether you find them in code review or later. They won;t even realize they are making mistakes unless they have to fix them. MAke sure also to explain why the solution they used is a mistake and why what you are proposing is better. The first few wweeks it will feel as if you have more work due to having these other people, but if you do your code reviews and explain things and expect them to learn, in a few weeks they will be much more help than if you just do it all yourself. But there is an intial commitment of your time to get them up-to-speed that your management needs to be aware of.