Developing Programmers .com

Well not really; I like newbies and they are the most important part of my readership. But when someone new hits an existing work place there is a lot to learn in very little time, and I’ve certainly heard people vent their frustration like this when someone new was having a hard time adapting to how the team worked.

Today I’m exploring what kinds of rants experienced programmers have when they start working with someone new. There are a few reasons to do this and none are intended to offend. The main reason is that there are a few problems common to most new work places which can be identified and explored. This will make our readers at least fore-warned, and possibly arm them with ways to mitigate frustrations both from the perspective of a new programmer and also from the perspective of a team leader bringing someone new into a project.

The topic is intended to be a bit of a free-for-all: hopefully some of you will have had experiences you’d like to share with us in the discussion forum for this article (see end of article).

I’ll start with my own experiences. In my first programming job myself and another newbie were assigned “familiarization tasks” where we read some documentation and added a “browser” for a particular kind of data. Because the company didn’t know about abstraction, they had separate “browser” code for several hundred different kinds of database table. The other newbie attempted and failed to abstract the code, and was soon delegated to fixing spelling mistakes. I just wrote a browser as I was told. After a year I was writing abstract code that worked, but it had taken a while to understand the problem in full and even then I didn’t know what all of the software was for.

In my current job we work in a small team and have different backgrounds, which can be frustrating for all of us at times. We each see problems a different way and have a different idea of how they should be approached. It can be hard at times not to “throw out the baby with the bath-water” because a good idea is implemented in a clumsy or inexperienced way. Also we’ve had different experiences which make us like or dislike various approaches.

New people can lead to new debates. Some debates are trivial (”why are you letting Emacs reformat all my files without tabs?”) and others are more serious design issues (”why can’t you see that this operation and that operation are really the same thing and should be merged?”). A common difference of opinion boils down to “applications are data driven” versus “applications are procedure driven”. I’m a data driven gal; I like to know exactly what information there is and find that if it’s represented just the right way then the procedure side of things becomes rather obvious. On a constructive day we’ll write documentation aimed at both ways of thinking. Other days we just argue a lot.

Problems I’ve had specifically with new programmers include:

• Reluctance to use revision control.
• Over- or under- formality of process.
• Not trying hard enough to simplify.
• Not seeing forest for trees.
• Failure to generalize and make re-usable code.
• Trying too hard to impress or not to stand out.
• Telling Grandma how to suck eggs.

I’ll discuss each of these and some ideas to mitigate the problems in turn.

The most common mitigating factors boil down to discussion and making the new people feel welcome. Weekly meetings where people just talk through anything they’re stuck on, major decisions they have to make, and what they’re up to have a positive effect because they allow even the most junior programmer to contribute to high level decisions, and just to see the others as people who have their own problems too.

Making an effort to include new programmers socially is important too; often at my work place we’ll have sub-groups getting lunch together and that’s a good chance to talk to a newbie about life beyond work.

Reluctance to Use Revision Control

Most of the newbies I’ve dealt with have never seen revision control before and it takes months before they can really see the point. The ones that do know revision control tend to have the next problem:

Over- or Under- Formality of Process

Each project and each team find a naturally “right” level of formality for their process. Testing might be all important or just an afterthought; depending on the kind of project. It takes a newbie time to get familiar with what this project needs, and to come to agreement with their new workmates about what is the minimum acceptable formal process and what is overkill. This is a tricky one because in my experience each new person shifts the average for the team. The newbie adapts the most but the whole team will change their expectations just a little to match the newbie as well.

Just today I’ve noticed that one of my workmates has duplicated all the API documentation for part of a program, in the .C files instead of just in the .h files. He has broken the rule our group has of continuing each file in the style of its creator, and he has introduced redundancy (one of my pet peeves) that means the documentation is now twice as hard to keep up to date. On Monday I’ll have to go and undo all his changes and find a way of telling him he stuffed up without upsetting him too much. D’oh!

Not Trying Hard Enough to Simplify.

Part of the problem here is different people have a different idea of what “simple” means. However, I have seen simple tasks like separating the fields on each side of a “=” sign complicated into dozens of lines of code and I think any experienced programmer would cringe at that. It is nearly always possible to make a section of code look simple. Finding that way can be a pain but is usually worth it.

Not Seeing Forest For Trees

It takes a while to learn how to see the whole of a system and have a feel for how the parts all fit together. While it’s fine to start in one little corner, it’s easy for a newbie to get caught up in that and never see what their part of the program is doing for the whole system.

Experienced programmers can mitigate this by re-offering the tour of the system after a month or two of settling in, so that it’s not lost in the information overload of the first month. New programmers can help by remembering that while they’re starting small, to be really useful they should at least know how their part of the project fits the “big picture” and should do the reading and questioning needed to find out about that.

Failure to Generalize And Make Re-usable Code.

This seems to be common in new programmers: they write one-shot code too often. If you find you’ve written 3 functions, one to arrange letters, another to arrange numbers and a third to arrange images then perhaps you should be writing one function that can deal with arranging “stuff”.

Also, for nearly all applications work if you have much code at all that isn’t packaged in a library then you’re doing something wrong. Odds are most things will be needed again. At work we use a third party parser tool which sadly was written to be an executable and not a library. The author never thought it would form just a part of a larger system, he always saw it as a stand-alone problem. It’s cost us a lot of time to write libraries to package it.

Trying Too Hard to Impress or Not to Stand Out.

Newbies will typically embarrass themselves if they try to re-design an entire system in their first week on the job. Take the time to learn the code layout, the reasons for it, who’s using it, the personalities of the other programmers, and more before you try to rework something in a big way.

At the same time, don’t limit yourself to just doing what you’re told. So long as you’re careful not to put someone else out, why not try doing something a different way and see what the other think? Meet with the other programmers to discuss your suggestions and accept when the suggestions are knocked back: it’s part of the learning experience and the fact that you’re really thinking about what’s going on will pay off in the long run.

Telling Grandma How to Suck Eggs

Chances are, the team you’ve just become a part of has got used to doing things in particular ways and are quite comfortable with the status quo. There will be some reluctance to learn new tricks and sometimes the things that worked for you elsewhere will not work here. The main thing is to be patient and learn. Once you are confident you can improve something and that your change would be a good one for this situation, try to raise it the right way, as a suggestion that they can take up and adopt for themselves rather than as an order from someone who may not have even earned the respect of the others yet.

If you’re accepting someone new into your team, make sure you go out of your way to talk to them about how things are different elsewhere. Sometimes you’ll need to tell them that your way works better for you, and sometimes they will have an idea that you can adopt to improve your current methods.

Any More?

Got any more pet annoyances with new programmers? Make sure you talk about how to mitigate them and remember that workplaces do vary a lot; so it’s more “learn the local rules” than “this set of rules fits all”. New programmers, what would help you to fit in at a new workplace? Do you have any pet peeves about what the other programmers and team leaders should be doing to help someone new? Use the links below to have your say.