Skip to content

Instantly share code, notes, and snippets.

@svpersteve
Last active June 15, 2018 21:38
Show Gist options
  • Save svpersteve/5dc7c21ab478836f4f0445e7143ec50d to your computer and use it in GitHub Desktop.
Save svpersteve/5dc7c21ab478836f4f0445e7143ec50d to your computer and use it in GitHub Desktop.

Training Developers

Contents

Introduction: How to love learning

My sister’s son comes home from school every day and wants to do his homework. He enjoys homework. He loves learning.

How did she get so lucky that she doesn’t spend her evenings wrestling with him to do the absolute minimum to avoid detention? This wasn’t luck, because he wasn’t always like this.

My sister’s an educational psychologist, and she learned years ago that praising children for their effort shapes them into people who enjoy learning for the challenge, not to improve their performance or their image in the eyes of their peers and superiors.

My nephew has a growth mindset. He understands intelligence isn’t fixed, you learn and grow when you try hard for long enough, and he enjoys the trying, not just the success when he gets the work done right.

We fear failure when we're defined by our performance, and when we fear failure we're reluctant to do anything we might not be brilliant at from the start.

Doing work is like debugging - success and failure are equally valuable, because they both give you feedback from the effort you've made that you can use to move forward.

I hate programming!
I hate programming!
I hate programming!
It works!
I love programming!

We’ve all felt that ‘I hate programming’ meme, where you’re absolutely miserable for as long as you’re trying to get your code to work, and the only joy you feel is that brief moment when you finally succeed and get it working, before moving on to the next frustrating 'effort' phase.

But what if we can change that? Find a way to revel in the 'effort' phase so we get less tired and frustrated with it? What if we can spread that programmer happiness beyond just the success phase and have happier programmers?

There is a way, and as a technical manager it’s your job to help your developers get there.

All you need is praise

Rewards make behaviour more likely to happen. With children and pets, we don’t always have to explain the behaviour we want repeated when we praise them right after they do what we want. As long as they have happy feelings when they do it, the habits will kick in. The Power of Habit has lots of interesting findings about rewards and habits.

If you feel good after you do something enough times, your brain will try to make you do it again. If you usually watch Netflix while you eat, do you crave binge watching the moment your dinner is ready? I do, it's just one of many bad habits I have.

As a technical manager and a human, one of your special powers is the gift of praise. Do it sincerely and specifically about something that your developer has actually done, and it will have a huge impact on them, whether it shows in their face or not.

Here's an example of sincere, specific praise for effort:

I really appreciate how quickly you got stuck into refactoring all that Pattern Library tech debt, Elena. You were so focused and really cracked through it, thank you. We'll all be so grateful for it next time we work on the Pattern Library and it's 10 times easier.

Here's an example of unspecific praise:

You're so fabulous! You're such a good developer, do you know that?

While the second one is nice, it's meaningless. If you can't tie it to something specific that happened, the developer you're speaking to won't really believe it's based on anything besides wanting to make them feel good.

Praise effort, not performance. But what is effort?

How do you make a developer’s brain feel good after expending effort? And what does effort look like? To understand this, let’s look at four developers on a team who all expend different kinds of effort. For a fun twist, they’re also animals.

Four examples of effort

Sid the Sloth

Sid is great at SQL queries and complex mathematical problems. He’s very well practiced at this.

He scans the backlog for tickets that involve these tasks and works on them. When he can’t find any, he stalls, works on ‘management stuff’ or a blog post, despite a growing list of bugs, and a pressing deadline for a feature that’s been lingering in the back log for a few weeks now.

Sid takes the easy road, only taking work he’s familiar with and avoiding work he’s unsure about that would challenge him.

Danny the Dog

Danny is well-intentioned and has a lot of energy. He works hard but doesn’t seem to have much success, and often needs help untangling himself. He also doesn’t seem to be learning much. He waits for other developers to be free to pair with him, and when they do they find themselves carrying him through a lot of the work.

Danny’s starting to get upset lately, talking himself down with sentences like “I’m not very good at that”.

Helen the Horse

Helen spent her life being told she’s exceptionally clever. When she gets something wrong, this theory that she’s exceptionally clever is thrown into jeopardy.

She knows everything. Even when she gets it wrong, she was right because you were thinking about it the wrong way.

If someone gets something wrong in front of Helen, she’s not shy about correcting them in glorious detail. She runs regular training sessions to teach people what she knows and she’s good at this.

But everything Helen does is safe. She never fails, and when she corrects others she does so almost as if she’s confused they managed to make such a simple mistake, as if mistakes are holes in the ship keeping the team afloat. She’s causing other developers to feel like failing is inappropriate and they’re nervous around her.

Uma the Unicorn

Uma is a humble and friendly developer with lots of energy. She’s rarely set back by failure or mistakes, and in fact is keen to share them publicly so others can learn from them like she did.

She always takes the next ticket that’s highest priority in the backlog, regardless of what the work involves, knowing she can always either figure it out, or ask for help from her team.

She loves a challenge, and she’s not afraid of saying when she doesn’t know something. In fact, she often behaves like she knows the least on the team, despite being the most experienced developer, and the unofficial leader guiding the team.

Despite her decade of experience in programming, when Uma pairs with other developers, she often says things like “Do you know how we might do this?”, or “I have no idea how to do that, but let’s figure it out”.

Why effort?

Dweck found that praising intelligence or talent is detrimental to children's self-esteem. If a child is clever because they got something right, it stands to reason they must be stupid if they get something wrong. They subsconciously avoid the risk of getting things wrong to avoid the realisation that maybe everyone was wrong about them being clever after all, and they are in fact stupid. Classic imposter syndrome.

I wanted to see how children coped with challenge and difficulty, so I gave 10-year-olds problems that were slightly too hard for them. Some of them reacted in a shockingly positive way. They said things like, "I love a challenge," or, "You know, I was hoping this would be informative." They understood that their abilities could be developed. They had what I call a growth mindset. But other students felt it was tragic, catastrophic. From their more fixed mindset perspective, their intelligence had been up for judgment, and they failed. - Carol Dweck

Types of effort

Each of our developer beasts fall somewhere on James Anderson’s Effective Effort matrix. The matrix is based on Dweck’s growth mindset.

Effort is broken down into four categories. Each developer is an example of each type.

To be clear, these metaphorical animals can, with time and patience, change species. Don't confuse the fixed metaphor with a fixed mindset!

Effort matrix

Running from difficulty

Sid (low effort) and Helen (performance effort) are afraid of failing. They avoid difficulty and this is holding them back from learning and growing. Dweck talks about what fixed mindset children do in response to difficulty. Compare this to how adult developers might behave:

In one study, they told us they would probably cheat the next time instead of studying more if they failed a test. In another study, after a failure, they looked for someone who did worse than they did so they could feel really good about themselves. And in study after study, they have run from difficulty. - Carol Dweck

Pushing themselves too far

Danny (ineffective effort) is not afraid of difficulty, he's frequently working outside his comfort zone. But his learning habits need work, and he's pushing himself too far, taking on work that is beyond his current abilities. The lack of improvement and constant set backs will eventually wear Danny down and he'll run out of steam.

Working within their abilities and outside their comfort zone

Uma the unicorn is where it’s at. Uma works at a level that sits just outside her current abilities. She pushes out of her comfort zone frequently. She makes mistakes because she’s new at what she’s doing, but she doesn’t mind this because those mistakes identify a gap in her knowledge and she’s filling that gap with the lessons her mistakes are teaching her.

You should all be like Uma

Cultivate and sustain effective effort by:

  • Praising strategies that push a developer out of their comfort zone but within their abilities
  • Praising processes that help them face and embrace difficulty
  • Praising perseverence with difficult problems
  • Praising improvement in their abilities: compare them to their past selves, not to other developers

Don't praise intelligence or talent.

Every time they push out of their comfort zone to learn something new and difficult, the neurons in their brain can form new, stronger connections, and over time, they can get smarter. - Carol Dweck

Helping Sid

Avoid negativity at all costs. Punishment or the shame of under-performing won’t solve anything for anyone, and will have more negative side-effects than you can afford.

Negativity creates a narrative of ‘you are bad’, which for a fixed mindset is going to reinforce the problems. Feeling inferior is exactly the reason Sid is playing it safe with easy work in the first place. If he tries harder, he has more chance of failing, and he can’t fail if he doesn’t try.

Ideas for action

Try to build something more challenging for Sid into one of the tickets he already wants to work on. If you have an SQL ticket you know he’ll love, build in some front-end work to display those results for the marketing team to access and use.

Offer to pair with him, or suggest he and Uma pair on the work to give him a chance to show off his SQL prowess but still have someone humble around to support him for the front-end part.

Speak to Uma privately and help her praise him for making the effort to solve problems he’s unfamiliar with. Uma’s openness about what she doesn't know despite being more senior should put him more at ease with ‘looking stupid’.

Helping Danny

Danny really wants to improve, perhaps a little too hard, but he’s taking on work that's too challenging for him.

If you’ve ever learned to put contact lenses in, you might have been told that if you find it difficult getting a lens out, you can start to panic and can damage your eye from frantically scrambling to get the lens out. Danny is at risk of frantically panicking because he’s not improving as fast as he wants to. We need to avoid panic, and encourage a 'not yet' mindset when he isn't achieving something.

It's not that he can't, it's that he isn't there yet.

Ideas for action

Try to establish if there are any pressing reasons why he wants to progress so fast. Maybe he's having financial diffulties and badly needs a raise, maybe he's worried he might lose his job. There might be ways of solving other issues that might calm him down.

Ensure Danny has the space to learn at an appropriate pace and level. Make sure the work he's taking on or being assigned to is appropriate for him.

Establish a baseline of his abilities by finding something 'easy' and if he breezes through it, notch it up a level until he's starting to feel challenged. From there, make sure work gets progressively more difficult from that point, but allow him some work that's easy from time-to-time to keep his confidence up.

Pair with him and see if you can find ways to help him improve the way he approaches planning and problem solving.

Helping Helen

Helen has clearly mastered the work she likes to do and has settled in her comfort zone that feeds her hard-earned alpha geek status. It's fragile high self-esteem though, and that can be explosive when it's threatened, so keep language positive and encouraging.

As with everyone else, avoid comparing her to others - positively or negatively. Performance effort is the kind that made the children in Dweck's study seek out worse performers to compare themselves to when they feel bad, or cheat and make it look like they're performing better than they are to protect the illusion they were born exceptionally smart.

Ideas for action

Recognise the effective effort she’s spent in the past to get to where she is now, and start a conversation about where she can go with more of that effective effort. Talk about learning goals that offer Helen a challenge, focusing on the process of figuring out those new skills.

Encourage Helen to write an article or give a lightening talk about a time she failed at something and what she learned from it.

Actively praise others who are open about their mistakes in front of Helen to model emrbacing mistakes as opportunities to learn.

Sustaining Uma

Uma’s not a machine. She can tire, she can fall off the ‘effective effort’ wagon, and she can feel under-appreciated, despite the fact she is literally a unicorn. If you have the chance to interview Uma, hire her. If you already hired her, treasure her because she is a goddess.

Ideas for action

Praise her effective effort. Praise and recognise her with specific details when she takes on challenges that are outside her current abilities but well within her ability to figure out. You don't want her effort to become ineffective by taking on work beyond her strengths or abilities.

I think it’s fantastic how you always take the highest priority work from the backlog, even if it seems challenging. I admire you for not letting unknowns hold you back from working hard.

I love how open you are with your comments on GitHub when you don't know something or have a question. Commenting publicly on the code not only makes it easy for others to help you, it sends the message that it's ok to ask questions.

It’s really valuable how you’re always so open about what you don’t know. This is so motivating and reassuring for the rest of the team. I know they really appreciate your openness and it breaks the ice for others to also say what they don’t know, which helps everyone's learning.

Thank you for all your work trying to get that feature to work. We’ve learned a lot of valuable stuff from seeing it fail, which means we can now restructure our Fooby feature with confidence, knowing the alternative doesn’t work and why it doesn’t - with solid arguments to give stakeholders. We couldn’t have done that without your pioneering problem-solving efforts.”

Focus more of your positive attention on the effort and process of taking on that challenge, how she figured it out, how she embraced and learned from mistakes and made it through to the end.

Resist the temptation to praise the results of the work, those results are rewarding in themselves but your focus should be on the process she used, whether it yielded results or not. Praising results will push her towards avoiding 'risky' work that might not yield results, but it's the highest risk work that yields the biggest results in the long run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment