The Learning Conversation

“It’s not until you realize most people are alike in this way that you can start to have more productive learning conversations – even with folks you strongly disagree with.” – Phil Haack

This has been a topic that I have been meaning to write about for quite some time now. But recently I read a blog post by the great Phil Haack on The Inevitability of Failure and Importance of Repair, which has inspired me to finally write this post.

I’m going to begin this with an example to illustrate the problem, let’s say we have 2 developers, Matt and Pete. Matt is the junior developer in the team and Pete is the senior developer. If you read my previous post on Stop Following Best Practices and more specifically my point on the Dreyfus Model for Skills Acquisition, you will see the varying levels of skill progression. Matt is a Novice trying to get to Advanced Beginner, whereas Pete is at the Proficient level. Matt and Pete have been tasked with coming up with an architectural solution for a CRM application. Pete has previously built an application using micro service architecture and thinks this will be the best way forward, whereas Matt is learning about micro services so he can make that next step in his career. This is the conversation:

Pete: OK team, I’ve been thinking about how we should build our CRM application and I think there is only one solution, and that’s using micro service style architecture.

Matt: I’ve been spending a lot of time in advance of this discussion looking at using micro services and I don’t think this is the right solution, I think… (Pete interrupts, because he is the senior and assumes he knows better)

Pete: Why would you think such a thing, micro services is the only way forward, we keep things apps small, simple, lightweight and isolated. Meaning the applications can form their own continuous pipeline. So if something goes wrong in an application we have built in resilience so if we need to replace, we can easily do so without affecting all the other components.

Matt: Considering you have previous experience in building a micro service oriented application, I guess you are right.

So, what’s wrong with this conversation? Clearly, Pete, the senior developer on the team has articulated a valid response to Matt’s concern about the right solution and using his experience has given the team insight as to why this would be the only way forward…

Well, the problem here is simple, Pete interrupted. Pete interrupted because he is the senior, has experience with this and thinks he knows better. But this is not always the case, just because someone is more junior doesn’t mean they’re always wrong. But what if Pete had not interrupted and employed a simple rule of listening to someone else’s suggestion before making theirs. Let’s see how the conversation pans out were Pete doesn’t interrupt Matt:

Pete: Ok team, I’ve been thinking about how we should build our CRM application and I think there is only one solution, and that’s using micro service style architecture.

Matt: I’ve been spending a lot of time in advance of this discussion looking at using micro services and I don’t think this is the right solution. I think we will end up introducing a lot of overhead in how we will have to monitor our individual apps. Using micro services will push the problem from the application architecture to the infrastructure and integration, which can become evident with network latency. Using micro services requires a level of maturity and understanding of the greater domain, something that in an Agile environment may not be known until later in the project development timeline. Once the domain is understood, you can start breaking things down by using the strangler pattern and branching by abstraction.

Pete: Huh, well, there’s something I didn’t consider. You’re right, let’s take a step back and see if we really need to implement micro service architecture later on the project development timeline, thanks Matt!

This is a learning conversation. There are 2 important points covered here, Pete didn’t interrupt, and by stepping back and not letting what he thinks is the better judgement get in the way, he has allowed Matt to explain why he thinks Pete’s approach may not be the best way forward. This resulted in Pete learning something new that he hadn’t considered, which he wouldn’t have learned if he interrupted as in the first example. Not only has the learning conversation helped Pete gain a new perspective, but it has also immensely helped Matt progress his confidence in his own knowledge by explaining what he has learned. He is now teaching Pete (his senior) more ways of approaching a problem. This is also creating a relationship of humility, respect and trust between Matt and Pete. Matt will feel empowered to know that he can continue to advance his learning. Knowing that he has used his already gained knowledge and won’t be knocked back when trying to help and teach others and Pete will know that by listening. Even if you think you know the right answer upfront, you may still find a new and even better approach.

I certainly don’t have a halo over my head when it comes to applying the learning conversation; it’s something we are all guilty of. Just because someone is more senior, doesn’t mean they’re always more knowledgeable in a particular area of software development. Realising this and realising that you can learn something new by stepping back and listening for a few minutes to even the most junior in your team will help everyone involved.

 

Thanks for reading and keep building awesome.

Until next time!

Ian B

P.S. You can also find me on Twitter: @ianaldo21