Teaching a junior programmer from a Sys Admin perspective?

Question

As a system admin with some programming experience, how do I guide a Junior Programmer to follow best practices or even start along the path?

My specific problem. I'm the Sys Admin, but know something about programming. Not an expert but understand a lot of the concepts, and like to try and keep up in the field. Our company has an accountant who programs. Self Taught VB6, and used it up till 1 year ago when I encouraged moving to .net. He does not understand much about programming, programming best practices, or design. The situation is more complex because he is older than I am by 15 years, has longer tenure at the company, and I am not anywhere in his line of direct report. His manager is the CFO and doesn't understand computers or programming at all. Just that he can get a certain report done by him. So, almost anything has to be done by encouragement, demonstration, and pleading.

What is most important to "push" for?

I'm currently trying to get him to use source control. Currently he just makes a new numbered directory and copies the whole project any time he thinks he should. I've set up subversion, and will get him to use it. But, it's going to take a while as the concept is brand new to him.

Testing consists of it "works on my machine". Builds consist of F5, and copy the executable. Database changes, ugh.

I finally got him to put database connection and calls in a function. I demonstrated a good use for an object in one program, but it didn't catch on either.

Design of programs consist of him throwing things on the screen as he goes. Any program design before writing code is non-existent.

Documentation of any form is non-existent.

What beginning programming concepts are most important? What are most important that will better help the company and this programmer make better use of time and resources?

Answer 1

You're in a pretty tough situation, since you have no actual control over this developer. The first thing that I think you need to do is make sure that you aren't in an antagonistic relationship with him - because if you attempt to force changes upon him, you will likely lose. It sounds as if he has too many things backing him for you not too - he has the support of his boss and the ability to deliver what his boss wants.

I think you're going the right path, honestly - you need to show him the benefits of the practices. Drop him blog entries that will help him do his job, and that may also contain tidbits of best practices. Source control is a great place to start, since I've always thought that that was a high value basic beginning to a good envioronment.

The one area where you may need to push back, though, is in relation to database security. You likely don't want him to have full access rights to your database, for instance, since the risk is high that he may lose production data.

In the end - this is going to take a long time, and will only work if he sees the benefits of improving. If he doesn't, or isn't motivated to do such, than you won't succeed.

Answer 2

That's really tough luck, I don't think there's a really satisfactory answer.

I've never had much success forcing bad programmers to behave - if you tell them what to do they just feel it as another burden.

Your best chance might be finding the "added value" for your coworker in whatver you want to change. Expose him to source control? Then find something REALLY cool that he can't do with the way he currently does things. It sounds bad, but view yourself as a salesman pitching good technology to him. Don't change too much at once.

Especially if he's friends with the CFO try to be helpful to him. He has done things like that for a long time, and even if it's bad practice doing stuff that way is a "local optimum" for him. Change anything and he gets less productive for a while. (Just imagine a good two-finger-typer learning touch typing. In the long run he will type more words per minute but during training he will be a lot slower as before.)

Whenever I'm in such a situation I try to be helpful. When I know how to improve a situation I nevertheless need the trust of the people involved to start changing something.

Answer 3

Source control, testing and debugging. All these sound like ways he was introduce to which makes him more confortable, the only way to make him step out the bubble is to show him ways thats out of his comfort zone that will still make him feel as ease of doing it. Unless he doesn't like getting into new things which is what it sounds like then he's not really fit to be a programmer from the beginning. But if your company doesn't have the resources to put someone in his position that actually cares about doing the best of what he can do, by updating to better and easier ways to solve problems then I would say you're going to have to give him discrete ways of why his old habits have been replaced.

Answer 4

Please excuse me being direct, but what's the point of an [established] accountant getting to become a professional programmer?

From your description it looks like there are little things at your company that can get programmed. So there is little effort and skills needed to achieve this goal. If there were a real need for a more than simple programming adventure, I suppose some movement would have been made to train this guy or hire a professional programmer/team.

To turn oneself into a professional programmer (okay, into a programmer that realizes himself as such) one needs time, dedication, clear goal and motivation. What makes it more thrilling and easy-going is an inherent enthusiasm. Ask yourself - what of these factors are present in your situation? In your situation I see: time - probably not much as the guy has other stuff to deal with (accounting), motivation - not really as there is no clear goal, dedication - also little due to the lack of motivation. Enthusiasm I do not know.

I do not see it a viable idea to turn an established accountant into a programmer, especially if the latter has definitely worse career perspectives.

You can try to find out what the guy would be interested in and help him with these things. This way you will have the feeling of having helped him and he could profit from learning a few new and good things.

Or you could think of some little and useful program or a site that would bring some benefit to the company and then pair with him to do it together. Then you both will learn something. If there will be two of you, there will be a justification for a versioning system. Try it out then new options will come into view.

Strange situation. And I probably gave a strange answer...

Answer 5

On the environment side, source control is nice and with Subversion you should show that the messages with a commit are better than numbered directories that could mean all kinds of things. Another point could be the history element of source control so one can see how often certain files get changed.

You may want to talk to him about the Software Development Lifecycle, which in an overview has these stages:

• Gather requirements
• Analyzing and designing a solution
• Implementing that solution
• Testing the solution to see that it meets requirements

Granted this may seem easy or common sense, but if someone hasn't seen this, there may be an "Aha!" moment here that could help save your sanity to some extent.

On the code side, continue to try to do mini-reviews that may help his code which may make you into a bit of a programmer at times. I can respect the wanting to help and prevent disasters that may come, but there is only so much one can do, ya know.

Answer 6

Your best bet is to introduce him to new things little by little, step by step.

Change is often scary for people, we all like the safe comforts of stuff we already know, but we also like to make things easier for ourselves. So keep on doing what you're already doing (it sounds like you're doing a great job), let him figure out subversion... he'll understand the benefits once he's over the initial 'this is different' scariness... you can introduce another good idea to him.

The most important thing to push for is control. I mean control over what is done. No-one really cares how its done, as long as you have it. If he knocks up an app on his laptop, and then gives you the exe to run... that's no good. If he knocks up an app and puts the source in a repository so the app can be modified and re-created, then that's great.

It doesn't matter if he's not a good programmer (you should see some of the stuff our outsourced partners did once, or the very expensive contractor we hired, when he wasn't outside with his hipflask full of whisky), but it does matter that what does get produced is controlled. It doesn't matter if its crap code, there's thousands of crap apps written by so-called professional programmers out there, if his code solves the problem, it doesn't matter so much that its what I'd consider 'throwaway' code, the only person who is hurt is himself (as I hope you avoid maintaining it by asking him for any changes to be made ;)

And make sure that what goes into SVN is what actually does get used to make the app. As an accountant he should be familiar with keeping records, this is the computer equivalent.