|
How to welcome a newbie
Todays management decision: we will get a new co-worker, he will appear in two days, and my job is to introduce him to our team and our work. I know virtually nothing about the guy, except his name and that "he did something similar in C++".
OTOH, I strongly believe that the most important factor in software work is the quality of the programmers (which is Fact 1, and, no, I will ignore Fact 3 for the moment); so I'd like to give the new one a warm welcome and a positive start.
Do you have any hints, tips, tricks how to do that? How to make him productive ASAP?
- Roland
Monday, March 1, 2004
A lot of people have a problem with Agile methodology practices, but in this case pair programming may be the answer.
Pair the noob up with a developer for a week or two. He/she can start out watching, absorbing the day to day work processes of the group, see the code, it's organization, any coding standards, tests, etc, etc, etc. At first, your experienced developer will do all the "driving", but after a week or two you should start to see the noob driving more and more.
anon
Monday, March 1, 2004
Also, if you pair the noob up with a developer whose skills you trust, you can get feedback as to his/her true strengths and weaknesses.
anon
Monday, March 1, 2004
I would make him wear a bra on his head, and send him and the other noobies over to your competitors to steal their mascot. Then when he is done with that, force him to sing your company song after downing a liter of vodka. If he can't do it, make sure he gets "pantsed" in front of the Delta Delta Delta girls during homecoming.
ogre
Monday, March 1, 2004
Start big, work down.
Walk the facilities
- Take him literally to each person on the team and introduce him. Have your 1 minute speech ready:
"This is Gale, she is responsible for the TPS reports. She also knows a lot about the foobar systems."
- Take him through the building, as you walk you will talk and that will give you a feel for his behavior. I find people tend to be more open when walking.
- Show him the coffee area, bathrooms, fax machines, and give him hints about parking, routes to the office, etc. if they apply.
- Get all the HR stuff done (i.e. security badges, paperwork, userids etc.)
- Take him and the team to lunch. Even if you normally eat at your desk, he doesn't know anyone and most likely did not bring a lunch.
Send him home. - Yep, he is done for the day.
Day 2
Explain the business - What does widget international do and what does your team do to help it.
Then the systems - This is the TPS system. It processes all the Tax returns for the State of HoldIt. This is foobar, it is responsible for matching all the Social Security numbers against addresses so we know where a person...
Then for the system he will be working in, the code.
Go through and look at some sample programs. Point out what you like and don't. Keep it simple and if you have standards, mention them and why the program you are looking at didn't follow them. (Come on... we all know it will happen)
Give him any system documentation then...
Send him home
Days 3 - 87
Pair him up with whomever will be responsible for showing him his area. Give him a change to make that is simple, but will show him your tools, and processes.
I still believe the 3 month rule applies. No one, no matter how good, can come from outside and be independently productive in less than 3 months. Some will be able to do more, but it takes three months just to bump into all the processes someone forgot to mention (or maker forbid) document.
In month 2 ask him what you could do better as a team. Soon he will be one of the borg and it is unlikely he will see that it is illogical to "cut/paste" changes into UAT because no one ever setup SourceSafe to include it.
And also, tell your team the unacceptable response to any of his questions is "That's just the way we do it." If you cannot explain it, should you be doing it?
[Digression -- Is it me, but everwhere I have worked it seems userids, regardless of when they are requested, show up a week after the person starts.]
MSHack
Monday, March 1, 2004
The first week be prepared to give him explicit tasking. Don't do a "okay, here's your cubicle, so just browse around the network and learn your way around"
In my personal experience, this lasts for about an hour, followed by four hours of "okay, so now what do I do to look busy?"
Email him a bunch of *relevant* documents and links, with an explicity "read these, see me if you have any questions, let me know when you're done." When that's done, give him the code to the current project and tell him to trace program flow from entry to exit (not "look over this and understand it" - give explicit direction).
Then pair him up with someone.
Philo
Philo
Monday, March 1, 2004
Send him out for a Left-handed monkey wrench or some Relative bearing grease.
Sven
Monday, March 1, 2004
"I know virtually nothing about the guy, except his name and that "he did something similar in C++."
Here's another thing you can try. Simple and very humane. Send an email to the guy saying to the effect:
Hi New Fellah,
My name is Roland and I'll be helping you get oriented at our company. If you have any questions, feel free to call or email me. If you have any free time, I'd like to take you out to lunch or dinner, so we can get to know each other better.
Looking forward to having you on the team,
Roland
Of course not everyone will be receptive to it, but the point is that you made the effort to reach out to him. I always found that to be the most flattering. Of course you can do that on his first day at work.
VP
Monday, March 1, 2004
Start requesting all the security access and all necessary programs now.
Lou
Monday, March 1, 2004
Clarification: I think the offer would be most effective before he starts work, but since things are happening fast, the first day should be fine.
VP
Monday, March 1, 2004
I personally think it's best to give newbies hard problems that will make them need to ask for help -- so they may be properly mentored and learn who knows what and also to see how they handle said hard problem -- and also that will force them to get to know some portion of the production codebase.
And, of course, have code reviews at least for a few months.
Hazing, teasing, and other newbie fun is, of course, optional but encouraged.
Flamebait Sr.
Monday, March 1, 2004
make him/her buy you lunch
Yo
Monday, March 1, 2004
I want to work for mshack.
itnirvana !
moses whitecotton
Monday, March 1, 2004
"And, of course, have code reviews at least for a few months."
Code reviews should last *forever*. A good light-weight way to do this is to have the coder walk through all the diffs before submitting to source control, possibly also stepping through the running code or a test program.
Exception guy
Monday, March 1, 2004
On a non-technical note, and this is obvious as we're all professionals but I'll say it anyway, avoid influencing his opinions of the organization outside of technical objectives with your own. If you have influence over other team members, encourage the same from them.
I tend to find it frustrating when I'm new in a company and start hearing gossip, especially about people I have to work with or report to.
MacSqueeb
Monday, March 1, 2004
Time for my GE annecdote. In about 1995 the division that I worked for at GE was standardizing on a certain desktop configuration. Prior to that we had a mix of Unix, Mac, PC and mainframe terminal workstations. To standardize the work environment and make workflow more efficient it was decreed that everyone would migrate to a cookie-cutter PC configuration.
My manager told me to take some newbie under my wing but as was standard proceedure in previous years I had to call him a couple weeks before he was to begin and get his work station preferrences.
So I called J. Random Newbie at home and ask his preferences. He wanted a Mac. I had to say he couldn't have a Mac. His second choice was a Sun. I had to say he couldn't have a Sun. Ok, OK, he'd take a PC. He wanted this much memory and disk and monitor. I had to say he couldm't have that or that or that but had to have the standard configuration which was this and this and this and that was really his only choice.
He thought I was friggin nuts. By the time he started and I did usher him around to meet all the guys, he was already fairly well familiar with the inane bureaucratic proceedures he would have to face from then on. Newbie didn't last long in that environment. I don't know why.
old_timer
Monday, March 1, 2004
Funny, I read the subject as "How to become a newbie".
That's one thing I wouldn't have a problem with.
TomA
Monday, March 1, 2004
Have a desk available and a PC set up before he arrives. The thing that impressed me the most about when I started my current job was that someone did some planning.
Previous jobs I had to scrounge for stuff myself or use someone's extra machine while they scrambled to find a place for me.
pdq
Monday, March 1, 2004
Start him out on the bug list.
The reason for this is threefold:
a) Working on bugs is the quickest way to get to know a system. You very quickly learn many different parts (out of necessity), and most importantly, you learn the pitfalls.
b) You'll knock off dozens of those silly "easy to fix but everyone is too busy" type bugs. The things that most of the experienced guys don't have time to bother with, but really need doing. Nows your chance, dedicate someone to it and watch them disappear in no time.
c) It's the most realistic way to judge if your new hire is any good. Giving them a nice seperate project like many places do is all well and good, but not very realisitc of what you'll be expecting him to do day to day. In the real world, you have to work with other people's code. You want to find out if someone is any good at that ASAP. Hence, throw them on the main project, not a side one if you want to know whether they're worth keeping around.
Sum Dum Gai
Monday, March 1, 2004
Give the newbie a good first task. As a prereq, they should first build and run the company product on their PC. Then give them a well-defined not-too-difficult task, so then can gradually get their bearings. It shouldn't be make-work, but it doesn't have to be top priority. Also, try to avoid grunge-work assignments, like asking a developer to do testing for their first two weeks (not that I'm disparaging testers).
Also, be available to answer questions. One of the most frustration things about programming is when things aren't working and you have no clue why.
Julian
Tuesday, March 2, 2004
See, this is the trouble with programming. People get jobs who have to ask: "how do I introduce a newbie?"
Tuesday, March 2, 2004
Thanks, this thread really gives me some great ideas how to start.
> Email him a bunch of *relevant* documents and links
One of which will certainly be JoS (if he does not read it already).
> avoid influencing his opinions
Yes, one of the most important hints, at least for me.
> Hazing, teasing, and other newbie fun is, of course, optional but encouraged.
Nope. I wouldn't like it, so I don't do it to others.
> See, this is the trouble with programming. People get jobs who have to ask: "how do I introduce a newbie?"
blank, I just don't want to repeat the experiences I had when I was new.
The one time, introduction was rather quick: "This is the project you will work on. We estimated that it will take 6 months [really?]. Here's your Unix box [Unix?] - have fun." Ok, I lied. They didn't tell me to have fun, and actually it wasn't very funny. It was not until a fellow a few weeks later said to me: "Heck, you don't ask any questions! I URGE you to ask more questions about everything!" that I started to understand the work there.
The other time, I took over a ~100 KLoc C code mess from a colleague. He was very helpful, but a bit, uhm, chaotic and detail-oriented. When I asked something, we quite often ended up at some irrelevant low-level detail, which was rather confusing.
- Roland
Tuesday, March 2, 2004
>[Digression -- Is it me, but everwhere I have worked it seems userids, regardless of when they are requested, show up a week after the person starts.]
Not we I work, cause I get the user ID out at least 5 minutes before the staff arrive, this does not guarantee they get the password though...Sometimes Annual Leave just gets right in the way, and be darned if I am going to answer any phonecalls from work, just let them use the work-experience kids password.
Aussie Chick
Tuesday, March 2, 2004
No. Send him out for a long stand and a big wait.
Tuesday, March 2, 2004
> "Heck, you don't ask any questions! I URGE you to ask more questions about everything!"
That's something worth telling a newbie explicitly; and, if necessary, repeatedy.
Christopher Wells
Tuesday, March 2, 2004
The last thing you want to do is give the newbie a walk-around off the cuff.
Sit him down in your office. Spend the entire morning telling him what the company does, where the different bits fit in, the direction you are heading, and all the other corporate nonsense.
Introduce him to his immediate team, and then *all* go for lunch.
This way, he has a way of referencing names and roles. I think it is much easier to remember/relate to people when you have an idea of what value they can add to your life. A morning spent introducing him to people who deal with widgets and foos, when he does not know what bearing the widgets and foos have on his life is a waste.
I agree with the idea of pairing, although if he is half competent, pairing him when no one else in the company is doing it can be condescending. Pair him for a little while, and then like someone said, set him on the bugs.
He will learn how things are done, and tracking down bugs will force him to look at the rest of the system.
A direct path to the senior manager, and encouragement to question the status quo, should make him feel involved, and contributing to the project, even as he tracks down bugs.
Tapiwa
Tuesday, March 2, 2004
On a sidenote, regarding Corporate Policy, and This Is How We Do It Here ...
Start with a cage containing five monkeys. Inside the cage, hang a banana on a string and place a set of stairs under it. Before long, a monkey will go to the stairs and start to climb towards the banana. As soon as he touches the stairs, spray all of the other monkeys with very cold, high-pressure water. After a while, another monkey makes an attempt with the same result -- all the other monkeys are sprayed with cold water. Pretty soon, when another monkey tries to climb the stairs, the other monkeys will try to prevent it.
Now, put away the cold water. Remove one monkey from the cage and replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his surprise and horror, all of the other monkeys attack him. After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted. Next, remove another of the original five monkeys and replace it with a new one. The newcomer goes to the stairs and is attacked. The previous newcomer takes part in the punishment with enthusiasm!
Likewise, replace a third original monkey with a new one, then a fourth, then the fifth. Every time the newest monkey takes to the stairs, he is attacked. None of the monkeys that are beating him have any idea why they were not permitted to climb the stairs or why they are participating in the beating of the newest monkey. After replacing all the original monkeys, none of the remaining monkeys have ever been sprayed with cold water. Nevertheless, no monkey ever again approaches the stairs to try for the banana. Why not? Because as far as they know that's the way it's always been done around here.
And that, my friends, is how company policy begins.
Tapiwa
Tuesday, March 2, 2004
> And that, my friends, is how company policy begins.
That's the only story I thought of, when I read "Significant institutional inertia" in the _Help me bring my dept into the 21st century!_ thread.
Christopher Wells
Tuesday, March 2, 2004
 Recent Topics
Fog Creek Home
|
