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.

Roy Bennett

 

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.

 

We have encouraged programmers to exhibit laser precision over the components to which they always contribute

 

Bridges Crossing Rivers

 

As I alluded 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.

 

It’s vital that we encourage engineers to cross component bridges and develop knowledge of the entire system

 

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 junior 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.

 

Another Spin

 

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.

 

Leads need to be proactive in rotating engineers across projects, technologies and teams

 

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.

 

It’s more important to employ curious engineers that can investigate technologies and system components than be the best coder in technology X

 

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!