Beyond the Great Divide
The comfort zone is comfortable for a reason. Feeling content, engaged and productive is a thrilling experience. If we’ve ignited passion in our programmers, you’ll see their fingers dance eagerly across the keys. Developers become complacent with not only particular technologies, but specific platform components.
If you always do what is easy and choose the path of least resistance, you never step outside your comfort zone. Great things don’t come from comfort zones.
To address our recent bottleneck and design challenges, I’ve been reading Your Code as a Crime Scene by Adam Tornhill. One clear challenge described early in the book is that engineers struggle to reason about the entire system. This is a difficulty we are finding as our platform starts to scale more widely. Here I reflect on our own experiences of encouraging developer laser precision on parts of the system, and how it has impacted platform performance.
Bridges Crossing Rivers
As I eluded to before, engineers are building knowledge of only a part of the system. This is partially a symptom of the myriad of microservices that we have constructed over the past few years. Our architecture has made it easier to decouple services and create new features. Nevertheless, delivery pressures result in our engineers persistently touching the same services. Reasoning about the performance of the entire plant becomes impossible.
Our team is not the worst for coupling programmers to components. Several developers have migrated across domains. Such moves are normally a reaction to increased project demands in a particular area. In such circumstances, experienced engineers are utilised over junior developers due to time pressures. These rare occurrences have grown more experienced developers into leaders. What is the effect on juniors developers?
This preference can introduce poor design into components when junior developers do not receive appropriate mentorship. Component design can become bloated, impacting performance. Giving all developers experience of other parts of the platform provides them with the guidance they need to better design performant microservices. To grow our entire team and platform, we need to make better use of rotations.
Through the grapevine whispers that other organisations are better at utilising enforced rotations echo. Reflecting on a talk I attended back in March reminded me of one particular example.
As part of their adoption of Extreme Programming practices at Pivotal, Elisabeth Hendrickson discussed mandatory rotations. Combined with pair programming and other XP techniques, they have found great benefits to their product development. Enforced rotations expose engineers to different projects, teams and technologies.
I’m tempted to consider more regular rotations by our engineers. To adopt a similar approach, we must determine how often should developers rotate? Like sweet and salt popcorn, a balance must be maintained to ensure people have space to learn, while ensuring client features are consistently delivered.
The Tender Trap
We should be growing our workforce to allow them to become adaptable. Building their transferable skills will prevent technologists being trapped in a particular domain. Seeking single technology skilled developers will also prevent them building expertise across all systems that we build and support.
An emerging trend discussed at a recent conference was the need for organisations to evolve their hiring practices. Our historical strategy of employing Java experts to write Java, or Angular developers to build Single Page Applications will not scale. Employing engineers with intrinsic curiosity can aid us in nurturing cross-component experience. Fostering the ability to learn new technologies, architectures and performance evaluation techniques will make for productive platform-wide programmers.
Thanks for reading! Remember that claps and responses are always appreciated.