Hi All,

I'm in the position where I'll be taking a new entrant under my wing (at managements request, not like I have enough work to do ). The new entrant is just out of school but does have some programming experience (but obviously not 'real' experience).

We have several courses lined up for him to go on, but as they are all busy, he won't go on his first one for over a month after he starts work. After the courses, he'll be on the formal training program so it won't be my problem.

So, in the meantime, my plan was to throw a compiler at him and give him lots of small programs to do, slowly building up the complexity to the point where he can do useful work (i.e. the crap I can't be arsed to do ).

Anybody had experience of training a programmer that has a better way ? The method above was the one that was employed on me when I started work many moons ago and hasn't done me any harm (much).

Thanks for any serious (or not so) advice.

Cheers

Ian

 

It's not.........Si is it?

 

LOL @ Chris

What we've done in the past is give them some code where we either already know the solution or give them the code before the solution had been done. The result isn't critical as it will have already been done, or you could probably do it yourself quickly, but it gives the newbie time to find their way round the code, and you can compare results and guide them as to what was good/bad about their solution.

Unless you want them to be productive from day one, as this doesn't gain the company anything initially, but will get the person thinking about how the existing code is written and will help familiarise them with any revision control systems, development environments, testing, requirements docs, etc.

 

LOL @ Chris, luckily for me, my employer and the planet at large, no it isn't Si.

Haslow,
Sounds like a plan. no, we don't expect him to be productive first off and in fact I think we generally don't start adding them into the resource pool (I hate that term) until three months.

Yes, he'll have loads of other stuff to get up to speed with, i.e. our systems, our software packages, change contol, testing, etc. etc.

But I really like your idea of giving him some real code to play with. I guess I could just pull out some earlier versions of code for our config management system, i.e. before they were working and while they were still bug ridden.

But I think it best to get him to initially play with some easy problems, mainly to get the hang of the compiler and tools themselves, then do as you suggest as soon as he knows his way around the system. Thanks for that, will also save me trying to think up meaningful, but actually pointless exercises.

Cheers

Ian

 

LMAO @ Chris

I usually get them to do something i could figure out fairly simply myself, but that is going to be of some use, so that they can cut their teeth on some real stuff for a bit. Expect very slow progress initially though, they are learning it all at once so to speak.

Be very careful to not make them feel under any pressure on for a result, as you want them to learn, not necessarily to produce stuff.

and try to enjoy it, sometimes it is helpful to pass on some knowledge to someone else.

 

Ian,

You could always get him doing mundane tasks, my first programming job at 16 involved lots of keying in of data, when I used to complain I was always told 'its a character building exercise - it'll make you a more round person!' yeah right! When Ive worked alongside trainees I always tell them to RTFM, they might moan but always say 'one day you'll thank me for it!' I think you need not only a good coder but someone resourceful that can go and try and find the answer if they dont know it without continually hassling you!

Gary

 

Well if it is Si we had better all prepare to get our hands dirty doing crap code for a while, as he always comes here for the solution!

 

My philosophy (passed on from hallowed sources) went with pointing someone in the right direction if they were asking questions, and helping them answer it for themselves. Give them enough info to get started, tell them where reference material is, and explain concepts or programming structures to them if they need help still, and they hopefully (if they're any good) will get through it really learning as they go (or hang themselves with it ;-).

If you have a look every now and then, and check they understand it, things should go ok. But without watching them like a hawk, cos that doesn't help most people work.

You only really learn stuff if you have to put effort into it. If someone just tells you, unless it's profound, or amazing, or you use that info lots soon after, you'll forget it. At least, I do.

 

You've never seen my code, have you know i got top results in college , thanks.

If your teaching java mate, let me know.

ive loads Useful programs/tests/Information, which is availble on my uni site.

Si

 

My "staffee" (who unfortunately for him is about to hit a well sharp learning curve on Monday ) has been "trained" along the lines of think for himself with pointers, so take the problem, have a think & talk over the solution that he comes up with, then pick the holes (gently) & narrow down the choices to the correct answer. Then try & get them to implement.

Slightly diff as a PC/Network Support type role, but time & encouragement do work. Also given mundane tasks that took up my time However, check that he's actually doing them

Also helps if the person is actually keen to learn as that too can be satisfying to you when passing on knowledge

 

Thanks for the input guys, I'll use some of that.

Si,
No, we don't do Java. It is on the list of languages we are *not* to use. We mainly use Delphi, Fortran, bit of VB if necessary (but I'll fight against it) and the occassional ASM.

Cheers

Ian

 

Got some good notes on Visual Basic if you need them aswell

Si