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.

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!

share|improve this question
2  
"general/hobbyist level programming" is very different from "junior level programmers" in my mind. The former sounds like someone who plays around with shell/batch scripts on the weekened to tweak their system. The latter sounds like someone who's just finished a CS degree. Handling these two types would be very different. Just sayin'... –  FrustratedWithFormsDesigner Oct 25 '11 at 17:25
    
@FrustratedWithFormsDesigner Thank you! I am not familiar with the terminology. Hobbyist I took to mean has self taught a few programming languages, built a program or two, a website.. Junior level I thought to be someone who has enough programming knowledge to be hired at a software company, but it now occurs to me that these two may be quite similar (in my definitions) ? –  Yuji Tomita Oct 25 '11 at 17:38
1  
Young guys with formal CS education and no experience - are naive, but often talented, learn new things fast and adapt to your work practices. "Hobby vets" are much more dangerous, as they are often slaves of their habits, thus they can be reluctant to changes, and have troubles fitting in your ecosystem. But nevertheless - only by giving them freedom, you can see their stupidity, or smartness. If you will give them primitive mundane tasks, neither them will learn anything about job, nor you will learn anything about them. –  c69 Oct 25 '11 at 18:49
    
@c69 Thanks! My question is how to ease the rookie into our codebase? The goal is not to pigeonhole them and solely do mundane tasks. It's just dangerous to give somebody access to our codebase, and have them build their very first django / programming project ever as a part of our system (or is this what you mean? Let em try and see?). PS: Duly noted about the hobby vets –  Yuji Tomita Oct 25 '11 at 19:50

5 Answers 5

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!

share|improve this answer
1  
Frequent code reviews was just what I was going to suggest. It will take an hour out of your day and will pay back in spades as you teach them what is wrong, they have to fix it and their skills improve. After some time, you won't need to spend as much time in code reviews as the first few weeks. Also make sure they know how to use (and do use) source control. Then any mistakes can be rolled back fairly easily. –  HLGEM Oct 25 '11 at 17:38
1  
@isgab - An effective User Interface Design is hard to achieve even with 30 years of experience. I mean look at Microsoft and Apple they both have different ideas about how a user interface should work. –  Ramhound Oct 25 '11 at 17:45
    
I love what you're saying about core vs ui. I thought there were pros and cons to both (rookie on backend, rookie on frontend). On one hand, HTML is often about experience - knowing what doesn't work. It's also "safe" in that projects are isolated. Backend works exactly as it should, but code built now has to be maintained and worked on in the future. –  Yuji Tomita Oct 25 '11 at 17:53

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.

share|improve this answer
1  
It should also be said that if you delegate the rookie to a role where they do not feel useful they will take the little experience they do gain to find a better job. Even a rookie should be able to follow directions, maintenance tasks are fine, but unless your willing to help them grow expect to always have a rookie. –  Ramhound Oct 25 '11 at 17:42
    
Thanks for your input - it's greatly appreciated. We have to start somewhere since we're considering people that literally have no experience. Introduction to python 101, django tutorial, bash scripts, how to use version control, etc., I will heed your warning about not micro managing. And yes! I believe our people are quite capable. –  Yuji Tomita Oct 25 '11 at 17:48

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.

share|improve this answer
    
I mentioned we're talking about people with zero prior experience (or a very small amount) so we're not talking about the pay grades required to hire a professional programmer. –  Yuji Tomita Oct 25 '11 at 17:40
    
Ah, and our company is a bit like a family: we like to do everything ourselves and have people work up the ranks. I was mainly curious how to structure a rookie's workflow into mine. –  Yuji Tomita Oct 25 '11 at 18:02

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.

share|improve this answer
1  
"Make sure you keep feeding them tasks that are just a small step beyond their current capability." - If this isn't done you might find that those people take their knowlege to another company. If you do not feed, train, and walk the Rookie they will run away just like your dog. –  Ramhound Oct 25 '11 at 17:47

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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