I’m working with a new senior programmer who has almost the same amount of experience as me. He his own project to work on — but I have to make sure he does not mess things up.
Now, how can I monitor him since he’s not junior?
Do I examine his code? Cons of this are that I am not as deep into project as himself so it’s time consuming for me (have my own project besides this).
Do I only do QA from the perspective of another senior?
Any advise here is appreciated. I was recently in the same situation where I relied that another senior will handle all tickets properly, and then it took me 3 weeks to fix his oversights. So I do not want to be in the same situation again.
3
For starters, monitoring sounds not like an environment where trust is valued highly. Yet, that’s the opposite of what a senior needs — an environment where she or he is trusted (and expected) to do whatever is necessary to get the job done, in an appropriate manner, without instruction. I presume you want this guy to succeed, so I wouldn’t take a “monitoring” approach.
Having said that, I would do this:
-
make yourself available — let her know that she can ask you questions, even seniors need to clarify things, especially in the beginning.
-
don’t expect her to know everything on the first day — show her where to find information, even seniors need time to get to know a new system.
-
clarify rules — let her know the rules, how the system or department is run, what to look out for, what expectations and no-gos are. Even seniors need to know these things.
-
involve the new guy — include her on every meeting and discussion where she might benefit, and in particular those meetings that concern her areas of responsibility.
-
clarfify responsibilities, and practice hands off — for any areas of responsibilities that were previously yours (or anyone else’s), make sure decisions are taken by the new person, including the risk of failure.
-
agree objectives — make sure the teams’ expectations and your own are clarified. I say agree because it should be a process where you sit together, discuss priorities and then agree on the objectives to be reached. Remember the SMART rule — any fair objective is Specific, Measureable, Achievable, Relevant and Time-bound.
-
review progress and praise achievement — review progress and achievements regularly
Finally, whatever you do, always give direct, personal and timely feedback: If you see something that doesn’t work the way it should, take him or her aside, explain what you observed, why you think its no good, how it should be. Be sure to be open for discussion, because new people tend to see things with a fresh perspective and might just have a good reason to do things differently than what is considered usual. Oh, and do give positive feedback, too, even seniors like getting some.
PS: “her” includes “him”, just saying
1
Start doing code reviews. Whenever he has some feature finished, go through all the changes together and discuss them. Do the same thing for all your code, discuss your code with him too.
That way you can both make sure the other doesn’t mess up, you both know what the other is doing, you can decide on a common style together, you can learn from each other, and you’ll probably find bugs and improvements that would have taken much more time to fix if they had been found by users later on.
A good code review is not necessary directed from a senior developer to a junior developer: peer reviews are good too. Everyone makes mistakes, and everyone has something to learn whether you are on your first day of your first job or on your final work day before retirement.
Code reviews are collaborative, not instructive: they are not college lectures and are not like grading homework. They are focused on working together to achieve a common goal: good code. Keep an open mind and be receptive to constructive criticism.
1
I would recommend pair programming. You would pair program with him as long until you are sure he got everything he needs. Ultimately you can not check everything and can only trust that he does things proper in the end. Because, as you said, if you check all his work you are stuck yourself.
Also pair programming is/should be common and it would be no offence to offer/demand it in the beginning. You do not want to offend the new guy. Also he would learn about your work which helps also you in case of absence or need of a second opinion.
Problem is that as you say, you are working separately. Maybe this is not a good way of organization anyway because if you want to monitor him you need to work closer with him anyway. So if this is not possible you could do 2 hours a day for the beginning maybe?
It is only my belief, but trust and transparency in feedback should be at first place for any co-workers. It doesn’t mean that you have to just let him/her into work without monitoring progress. First of all:
- pair programming, but it takes a lot of time, although its worth doing, especially you will feel secure that you have a good and competent collegaue (or not). Worth doing in first phase of getting know each other.
- code review, but it should be both-side code review – show him your code and let him ask you about it, not just monitoring his progress (he might have other techniques in writing code, but it might be useful as yours).
- just talking, openess and trust in telling what is going wrong (nobody wants to say “i have some issues” for stranger) will help you too.
These are mine thoughts, i rely on them and it never get me into wrong path.