How to mentor

​Once you start getting experience, you’ll find other developers asking for your help. I started tutoring at university so that I could help, and reflect and improve my own knowledge. 

Mentoring isn’t about answers. It’s about learning how to find the answer. The most interesting problems we deal with are the ones that no-one knows how to do. 

When someone asks for help, help them to help themselves. You need to start asking questions to help them find their own way. 

A successful mentor makes themselves obsolete quickly, but remains available to keep asking questions. A successful mentoring process leaves the learner with autonomy and support. 

My favourite quote from my tutoring days was a pair who, after I asked them enough questions to finish the tasks, said “I like you because you make me feel smart”. 

If you’re hiring the right people, they will be smart. Make sure the mentoring and onboarding reforces that. Smart, confident people are the ones who solve problems. 

Advertisement

Everyone has a voice

​One of the challenges that Technical Leads face that isn’t always easy to resolve is making sure the whole team is involved in decisions. 

There is a large overlap between people who can think in code and people who are shy around other people. For some, the enthusiasm of the former can overcome the latter, but for many, especially younger members of the team, they need encouragement. 

There are a few key ways to do it. If you’ve built the right team, pairing with a patient mentor, who asks questions, is a good way to build confidence. We all hate it, but asking someone their opinion in a meeting is important too, until they get confident enough to speak up themselves, because they know they’ll be heard. So pick your meetings wisely. 

There’s also non-verbal ways to increase interaction and confidence. I’m a big fan of asynchronous code reviews, because they help people focus on the code rather than the coder. I realise there is a risk that this can lead to an atmosphere where someone being reviewed feels under attack, but in my experience, with ego-less teams, and especially with teams who understand and fight technical debt, they see reviews as a chance to improve the code and their own understanding, and make everyone’s life easier next time they look at that feature. 

Lean Coffee meetings are also good for helping encourage people to suggest ideas, as they can see what others want to talk about, so they know they have something worth dating. 

Make sure the quiet people speak up

Did you have a useful week?

Did you learn something? Did you stretch yourself? Did you challenge your assumptions, or your practices? 

Do you feel like you achieved something last week? Did the frustrations inspire you to make it easier next week? Did you share them with others, in the pub, or on your blog, so others can learn from your frustration? 

Did you set new goals? Are you going to be a faster typist? Are you going to learn functional programming? This time, are you going to lose weight? 

Did you make new connections? Did you make an effort to understand the people you work with? Did you do something to strengthen your work and personal relationships? 

You don’t have to do all of that. But did you think of it? Did you write it down? Did you, in some small and agile way, improve yourself? 

Can you say to yourself, today, that you had a useful week? 

Fear of failure, and risk-takers

We all make mistakes. We should learn from them, whether it’s because we didn’t know enough, or because we’re taking a risk. People are afraid of mistakes. We’re afraid of being found out. We need to fight imposter syndrome, and tell the world we are not phonies. So we don’t want to fail, we don’t to make mistakes, so we avoid taking risks.

But what if, when we ask Is it OK to fail? we start asking instead, “is it OK to learn?” or “Is it OK to to take risks?” If you feel like an imposter, that you’re out of your depth, you have 2 options:

1. Decide you need to learn. I’m currently in charge of a team that’s moving to a more devops culture, and I don’t know enough to know if we’re doing it right. So I’m reading, and testing, and building out my knowledge, so that I can make some mistakes and learn from them, to help me understand the mistakes bigger teams made so I can learn from them too.
2. Decide you don’t need to learn. Trust your team, or a 3rd party to deal with it for you. Learn how to detect bullshit, and let them deal with the detail.

I loved reading Risk taking and imposter syndrome at Google where Google talk about battling imposter syndrome head-on. When you are surrounded by the brightest and best, you are always going to struggle with confidence. So ask everyone what risks they are taking, and what they’re learning. What do you know today that you didn’t at the last stand-up?

When you are adding value, no-one will think you’re an imposter. And hopefully, neither will you, but when you do, know you’re not alone.

Go learn.

 

 

Project Manglement: a few leadership anti-patterns

Note: these are a selection of things I’ve seen and heard from a number of people in a number of companies, and some mistakes I’ve made. Any similarity to your situation is entirely coincidence.

(If you like this, I’d definitely recommend PeopleWare by Tom DeMarco and Tim Lister, as that’s got a lot of good stories and science about what makes for a productive team, company, and office)

Expecting things to just be done

Just because a problem was identified, doesn’t mean it will get fixed. In a team, everyone, including you, can easily claim it’s someone else’s problem, or that their other work is more important. If you want it done, assign it, and prioritise it, either yourself or as a team.

Tell, don’t ask

On the other hand, don’t fall into the micro-management tap of telling everyone what to do, thereby removing autonomy, you’ll kill creativity and motivation, and you’ll end up with an informal work-to-rule where people twiddle thumbs until you tell them what to do.

Treat estimates as promises

We call them estimates for a reason: we don’t know how long it will take. We can make a good guess on what we know, an educated punt on what we know we don’t know, and a wild gamble on what we don’t know we don’t know. If you want an accurate figure, ask us when we’re finished.

Meetings as status

Meetings aren’t for your ego, for everyone to listen to you. If the team respects you, they’ll listen anyway. If they don’t, meetings like that are likely to antagonise.

Meetings aren’t for you to find out progress. That’s what wall charts, release notes, and daily stand ups are for.  Don’t call another meeting just because you weren’t paying attention.

Leaky abstractions

It’s likely we’re just as frustrated as toy that the release wasn’t perfect, that those requirements are taking longer, and we know the customer is frustrated too. Telling us about it every time they contact you (or Cc’ing us in so we can see it ourselves) is rarely helpful. Developer’s egos can be fragile enough beating ourselves up about what we could do better.

Understand what we’re doing to fix it, and communicate it back, but part of your job is to filter out noise.

But when we get praise from the customer, please pass it on.

Any other anti-patterns you’ve seen?

Bootstrapping new developers

Start of a new day

When things are tough, do them often, to get more practice, as Sky Betting discuss in their recent blog post. It’s certainly something that I’ve noticed as we’ve moved to more regular releases, more regular planning and reducing feedback cycles.

One big thing I’m still learning how to do, where that doesn’t apply, is adding new developers to a team. I’ve been thinking about this after hearing The Improv Effect talk about onboarding to a company on .Net Rocks 1253 : Onboarding is Culture with Jessie Shternshus

My usual approach doesn’t apply, because good teams are stable, so onboarding is rare, which makes it harder to know how to bring new people on to the team. I always try to write a short introduction, on a wiki, to introduce the project and list the useful urls, and the getting started steps, and I ask new developers to update it with any differences they find, to keep it up to date.

Most of the team knowledge doesn’t come from there. It comes from the rest of the team. So the team needs to be built so that the onboardee collaborates with other members of the team from day one. Getting involved in code reviews, asking questions. I’m sometimes tempted to give as little information as possible to encourage asking questions, but that’s not how psychology works, and I’ve had more than a few gotcha moments where someone who’s been on the team for a while says “I didn’t know that was there” or “oh, so that’s why we do it that way”, and I have to revisit the onboarding story again, and wait for the next chance to validate it.

So, assuming your company has a good story for onboarding employees, how to you take a fresh start, or a start from another project, and build them into your team?

Apprentice programmer

Let’s talk about plumbing, and customer service, and an experience I had recently with a company I won’t name. Overall the experience was good, but I don’t want anyone to get into trouble because they’ve misinterpreted what I have said here. (and if you’re wondering about the picture : the Olympic flame isn’t lit either).

A couple of months ago, our gas combination boiler failed. It refused to start and complained that the flue was blocked. I sighed because we’d had the bearings on the fan replaced last year. So I called the service company to get it fixed.

A couple of days later, I was working from home to let the service technician in. He was fairly young but identified a problem. Unfortunately, a new part was required, so he had to come back the next day. He came back, replaced the part, fired up the boiler and all looked good. The next morning, no hot water and a flue warning 😦 it was the weekend by this point so we got a senior employee, who identified an error in the replacement part (fitted the wrong way) and identified the original problem as a blocked inlet. 5 minutes to identify, 1 hour to dismantle the boiler to get to the blockage and put it back together.

He finished, switched the boiler off, and then made sure it fired when put back together. Problem solved.

So, what did I learn, and why am I posting this on a programming blog?

Firstly, a monthly fee means that I didn’t have to worry about callout or parts, which was great, and left me less annoyed than I might have been.

Secondly, your first fix might not be the right fix. It looked right and it passed the first test, but caused problems later on (at the next restart). Ever written the wrong test and thought the problem was solved? Threading has caught me out in that way before.

Thirdly, just because it passes the test, doesn’t mean the problem is fixed. The boiler fired easily when the case was open and there was more airflow, but didn’t fire when the case was closed. Ever had a bug that only appeared in production or in a system test?

Fourthly, experts will find problems quicker than rookies, but rookies still need to learn.

Fifth, sometimes the only way to fix a problem, even a small one, is to tear everything apart, blow on it, and put it back together again.

The second guy also said something that struck a chord, as I’ve been trying to do it myself : he was disappointed that the company didn’t send the junior out with him so he could pass on his experience so that he’d learn for next time. Apparently, the fault itself is rare, so it’s a good learning opportunity. For developers : fix your own bugs, as there are a lot of things apprentice developers will see in the first few years after they graduate that are rare enough not to come up in university but common enough to be real problems in the real world. For example,
trusting user input (and the related buffer overrun bugs).

So, what have you learned from other professionals?