Mentoring #2

I think I’ll end up writing loads of blogs about mentoring my new Apprentice. It’s going to be an interesting journey for sure.

1. He doesn’t know C# or SQL and that’s a prerequisite
2. He has never used our software before
3. It’s his first software job so knows nothing of the process

I explained to him that this team is really difficult, but historically, we have always thrown juniors into a team like this, much to the protest of many. This team deals with a wide range of bugs, and often requires good knowledge of requirements, and excellent debugging skills. We also get really tight deadlines, since we are given all the “Major Incidents” which can have 1-3 days deadlines. It’s unfair to put that much pressure on an inexperienced developer.

I told him it’s a “sink or swim” type approach, but strangely I can’t think of anyone that quit. When I was a Junior, we all complained about this, but yet everyone stuck around and became good developers.

I was telling him my long journey into development, and told him it takes years to get good, although maybe I was just slow because I was extremely casual. He reckons he can learn within a few months. I think he is ambitious, but I reckon he can learn like 10 times faster than I did. He can put more effort in, and I can guide him.

I was telling him how I haven’t been given guidance on how to be a mentor, but I can just freestyle it. I told him I’d like to be the mentor that he expected to have. I mean, he is an Apprentice and has been here a year without anyone actually being assigned to him. That is such a classic thing to do: hire people on the promise of training and good things, then they get here and they are never assigned any official training.