36

As a senior member of a software team that, unfortunately, has little documentation for legacy reasons, what are the things that one could do to make a new hire comfortable?

I have been planning debug sessions with the person on specific defects/feature requests to get him/her acquainted with the code base. However the code base is real large, and its only a fixed amount of code I can expose the person to in this manner.

I am looking for suggestions in either cases when the new hire is a recent graduate or an experienced professional.

gnat
  • 21,442
  • 29
  • 112
  • 288
Fanatic23
  • 7,533
  • 4
  • 31
  • 56
  • 3
    What does "legacy reasons" mean? – Job May 14 '11 at 22:48
  • 9
    @Job: It means that the original architects of the code did not believe in documentation. They were mystic people. – Fanatic23 May 15 '11 at 04:50
  • 7
    I would say that your new hire needs time and support and no immediate deadlines! I have been that new hire where bugs needed to be fixed ASAP for a client's patch but many of them were quite involved - I needed to walk around and talk to literally 6 people, producing conflicting answers. Someone flipped because I asked too many questions. It would have been easier if that guy fixed the code himself. I needed availability of people + no immediate deadlines + an ability (allotted time) to improve things as I went. I did not have those, so I almost quit but decided not to for the experience :( – Job May 15 '11 at 15:12
  • @Job: very useful, thanks. No immediate deadlines is a good start, and a free hand to improve things would definitely improve candidate confidence. – Fanatic23 May 16 '11 at 16:37

7 Answers7

31

These really apply to any new hire, whether they're freshers or have extensive industry experience:

  1. Make sure that you are approachable. If you're too busy to help them get acquainted with your system, assign a mentor to them. Make sure that the mentor is personable and willing to do things like go out for lunch with the new hire. The mentor's job is to answer any questions that the new hire may have and to provide them with a helping hand where needed.
  2. Ensure that any tasks that are assigned to them have as few dependencies as possible. There's nothing that will cause someone new to your system (fresh or 5+ years experience) feel overwhelmed more than assigning them a task that has dependencies strewn throughout your system (which they will also need to learn in order to complete their task)
  3. Have some form of contact/ownership list available through an intranet site or something along those lines. New people (especially freshers) are usually quite tentative about asking "who do I ask about x sub-system?". If there's a list provided for them at hire, they're much more willing to send off an e-mail or talk to them directly without having to go through a chain of people to find the right one.
  4. Get documentation up. Enforce coding standards that include commenting that can be parsed with a utility like Doxygen. At minimum, this will provide new hires with the capability to browse through your API. If you use an IDE like Netbeans, using Javadoc commenting format will provide documentation along with its code completion. Invaluable when learning a new system.
  5. Have some of welcoming meeting/lunch/hazing/etc. Plunking someone down in their desk without some basic personal courtesies can leave them feeling rather detached from the team.
Demian Brecht
  • 17,555
  • 1
  • 47
  • 81
  • 1
    Thanks but what if a new hire is too hard to understand things & attempting to not accepting his fault even we teach them to a Max.level - i m experiencing a situation where a new hire is not good & i m handling his tasks also in development - thank u once again – Naveen Kumar May 14 '11 at 12:14
  • 2
    @naveen: There is a such thing as a bad hire. If they're absolutely unwilling (or unable) to learn or take accountability for their tasks, then I'd have a talk with their manager and leave it in their hands - either they'll talk to the new hire to see if they can assist further and maybe (hopefully) get them on track, or the new hire may find that he/she would rather pursue other interests out of your company. – Demian Brecht May 14 '11 at 17:28
10

I think I can really help you with this one. When I was 18, my first job was a Jr. .Net Developer position. They had a very large framework and he had me jump straight into learning a crash course on CAB, and when the first project came I was expected to estimate the project, and learn SqlServer, and their framework. What made this a wonderful experience was that my Sr. Developer was there for me throughout the whole process from estimates, to SqlServer, to their framework. I learned what I needed to learn in a very timely manner because I was able to use him as a resource for questions and help. Mind you, this was also done while I was in Colorado, and he was in California. (Remote development). He had me read whitepapers on CAB, pointed me to good resources, etc, so its not like he had to do all the teaching, but when it came to questions he was there. Bottom line, you need someone to be the support for your Jr. Developers. Especially if you want them to learn and grow with the company and have a good working relationship. They wanted me to relocate to California because they were pleased with the rate at which I was able to learn and progress, and my work, unfortunately I couldn't make the move due to cost/etc.

That one experience really set a trait in me too. Now I am developing software on my own successfully for businesses and foundations in my local city and I'm still only 21 years old. It was the best first job and I am extremely thankful to Tom Anderson at RenEvo Software & Designs (who was my Sr. Developer). An amazing mentor.

David Anderson
  • 1,259
  • 9
  • 12
4

The company I'm with now, IMO, does it right for new hires. Here's some of the things that I have seen to be effective.

Mentors

Maybe a bit of a misnomer because some experienced devs might not think they need one, but we have 1 person that is assigned to be your mentor. This person is to be available to answer any question you could have. It works better if they sit close to the new hire. The whole point of a mentor is so that new hires, especially juniors, are comfortable enough to not fall into the trap of not asking enough questions.

Documentation

You've already mentioned it, but documentation can help. We have a document in our wiki here that basically describes your first two weeks on the job. By the time you're done going through your first two week ramp up, you've gotten yourself into a groove, gotten the lay of the land, and are comfortable working there.

Community
  • 1
Steven Evers
  • 28,200
  • 10
  • 75
  • 159
  • Too much mentoring leads to an employee who needs a babysitter most of the time and asks anything, really anything instead of reading code etc. I'd only recommend it for juniors. – Falcon May 14 '11 at 17:13
  • 1
    @Falcon: I haven't seen that happen in practice, but maybe I can clarify that the mentor is more of a person whose role is well defined to the new hire as someone who is to maintain high availability for the new hire to answer questions or direct the new hire to any information they need. Again, a bit of a misnomer, but I can't think of a better name for the role. – Steven Evers May 14 '11 at 17:17
  • 1
    @falcon: I disagree (about recommending it only for juniors). Do those with experience get better just by themselves (okay, so most *can*), or does it become easier with mentoring? There's *always* someone better than you, someone who's been around longer and someone that you can learn from, to help you get to that next step in your career, whether you're a new hire or CTO. – Demian Brecht May 14 '11 at 19:34
1

Patience

Joining a new company can be quite daunting, especially if you have a new product to learn, and use different tools to what you are used to. Give them time to settle to the new environment and get up to speed. Assign them tasks to do, but be aware it will take them much longer than a normal experienced programmer will take.

Support

You don't necessarily have to assign a dedicated mentor to them, but be sure there are plenty of people around who can offer them help when they need it.

Everyone has different ways of learning, some might find they need a mentor, others may find a mentor slows them down. There is no one size fits all solution, so instead let them find their ground and support them, and be patient as they learn the ropes.

Gavin Coates
  • 1,054
  • 5
  • 11
1

I started at a new job 4 months ago, and I really think that my new workplace did a really good job on this new hire stuff.

A. Buddy

They have a so-called "buddy-program", where developers can sign up to be a buddy / mentor for new employees. When a new developer is hired, a developer in the same team (who signed up to be a buddy) is pointed out to be the new guy's buddy / mentor. It is his responsibility to get the new guy up and running, help him out with the problems he will encounter, go to lunch with him, introduce him to the team and so on.

B. Low dependency

This was previously mentioned also, but start out with assignments that are not critical and too hard to do, without full knowledge of the code-base. There is nothing worse than getting thrown into a code-base you don't know, and then need to perform from day 1. If possible, make assignments that are relatively easy AND span across the entire system. That way he will get some knowledge of the system.

You probably have small tasks that you didn't have the time to do, when you first wrote the code. Give those tasks to him.

C. New-hire trainings

This is probably luxury to most, but I work in a large corporation that can afford to do this. Every month or every two months or so, some kind of new-hire training are arranged. It is basically a series of presentations, with the goal of giving the new-hires some kind of knowledge about the system, how testing is done, how the bug-tracking works and so on.

Where I work, there is a lot of different teams, working on completely different tasks, but on the same piece of software. A member of each team is assigned to do a presentation on their part of the software, where they give an introduction to what that part does, how it works and so on. Besides that there are trainings on tests (I am working as a tester) about how tests are written, how they are run, how they are checked into the codebase and so on.

To sum it up, be gentle on new-hires and don't expect serious work from them in the first month or so. Give them tools to get help and if possible, give them some presentations or videos.

Niklas H
  • 645
  • 5
  • 15
1

Draw a quick sketch on a piece of paper. Functional blocks, and data travel among them. So that the new hire can keep this list handy, and look up where is the spot he's trying to touch, and which modules affect it hierarchically.

Everything else comes with time. But it's the big picture that's making you feel dumb when you need to change 2 lines of code, but have no idea what side effects can cause on dependent modules, code blocks, etc.

Coder
  • 6,958
  • 5
  • 37
  • 49
0

In addition to what have been said before, identify training needs and provide for it either by providing time, material, in-house classes, books, etc. Chances are not every one knows everything. Make him/her aware that this is OK.

Keep him/her away from 'bad' guys. There are usually at least 1 arrogant person in every organization (this is my law :))

If you assign a mentor, make sure the mentor knows that it is the mentor's job to help and it is not out of his kind heart. Make time in the mentor's schedule for that.

Follow-up on his progress the first month or so, infer his problems if you can.

NoChance
  • 12,412
  • 1
  • 22
  • 39