Today’s .NET Rocks! podcast featured an interview with Llewellyn Falco, who does coaching/consulting work for companies that are trying to improve their processes and techniques. There were several concepts that were worth noting, so I thought I’d create the TL;DL (too long; didn’t listen) version here.
- When you’re teaching a team new skills, it only matters if the team continues to apply those skills after you leave.
- Even if you know there’s a better way, go where the team wants to go because otherwise they’re less likely to stick with the new way.
- Building a habit is more important than simply acquiring knowledge.
- Doing something just 10% different (so it’s mostly similar to what you’re already doing) makes the change seem more achievable. People are inherently uncomfortable with big changes.
- Change blindness (change happens so slowly that you don’t notice it) can be exploited to introduce habit adjustments without having significant resistance.
- An example of small change — if your software release cycle is 6 weeks, try doing a 5-week iteration. This has more potential to succeed than jumping right into deploying every afternoon.
- Change is about perception and is relative. For example, if you’re lifting a 100-lb barbell and someone added another pound to your bar, you probably wouldn’t notice.
- If you get the team caring about something that helps them improve, you can build momentum for bigger things.
- Small changes repeated over time have cumulative effects that earn interest.
- Mob programming (which I’m a huge fan of) can be very effective.
- One exercise is to work on a complex method/class and the only two actions allowed are “rename” and “extract method” — but you have to use the keyboard shortcuts. As soon as one person memorizes the shortcuts, they can help train the others, and then the mentality of “I’m part of this group so I should learn this, too” kicks in.
- This is in a sense mob learning: One person is the student and everyone else is the teacher.
- When you get a group of people involved, there’s collectively more interest. You want to be where the people are, because there must be something interesting going on for them to be doing something together.
- Holding the space — because you are there, even if you aren’t doing anything, everyone is doing something that they could do without you but for some reason they don’t.
- First out, you don’t need to worry about doing great things — you just want to be doing better than you were before.
- Consider the fixed mindset vs. the growth mindset. If you feel like you’re a great developer because of innate talent, you have a tendency to avoid situations where you could fail. Does failure help you understand what success looks like, or do you equate the failure with you yourself being a failure?
- Effort trumps talent, which is a thesis put forth in Talent is Overrated by Geoff Colvin (another book I’ve read and would recommend). The real value is in building good habits and then following up with the work.
- People get full (cognitively) and they get tired. When exercising, it’s not just the heavy lifting that’s important — it’s the rest that rebuilds the muscle.
- Some other developer-specific resources…
- Practical Refactoring
- Mob programming
- Lean Coffee
- Learning about code smells
- Related to code smells, being able to identify small problems and fix them (while they’re small) makes it easier to keep large problems from occurring. Build the habit of asking, “Is this code good, or does it smell?”
Another book I’d personally recommend is Switch: How to Change Things When Change Is Hard by Chip and Dan Heath. I have another post on my to-write-about list about the concepts covered in that book.
If you have examples of other habits you’ve built, feel free to leave a comment here, or leave one on the .NET Rocks! page.
5 Comments