In the 1984 film The Karate Kid, young Daniel LaRusso arrives at Mr. Miyagi’s house expecting to learn devastating kicks and lightning-fast punches. Instead, he’s handed a cloth and told to wax cars. “Wax on, right hand. Wax off, left hand.” For days, Daniel polishes cars, paints fences, and sands floors, growing increasingly frustrated.
What does any of this have to do with karate? Everything, as it turns out. Those seemingly irrelevant movements had been building the precise muscle memory needed for defensive blocks. The mundane tasks were secretly crafting a martial artist. This principle, that mastery emerges from unexpected places, applies with remarkable force to software engineering. Yet mention to most developers that they should spend time in change management, business analysis, or testing roles, and you’ll likely encounter the digital equivalent of Daniel’s initial resistance. “I’m a software engineer, not a business analyst,” they’ll protest. “I code, I don’t test.” This resistance is understandable but ultimately self-defeating. Like Daniel’s car-waxing, these “peripheral” disciplines contain the hidden DNA of engineering excellence.
The Specialist’s Trap
Software engineers often fall into the specialist’s trap. Having invested years mastering programming languages and frameworks, they naturally want to deepen that expertise. The idea of “wasting time” on seemingly tangential disciplines feels inefficient.
This thinking reflects a fundamental misunderstanding of expertise development. Research consistently shows that the most effective problem-solvers aren’t narrow specialists but “range specialists” – individuals who combine deep knowledge in one area with broad experience across related domains. The most effective software engineers possess not just coding skills but insight into the entire ecosystem that surrounds their code.
Change Management: Production Readiness and Stakeholder Clarity
Change management is about answering three critical questions: Why does this change matter to the business? How do we know it’s safe to deploy? What else might break when we flip the switch?
Engineers who understand change management develop the crucial skill of explaining the benefit of the change in a way that resonates with senior technology stakeholders who must prioritize competing demands for limited production resources. They learn to communicate with production support teams who need to confidently accept responsibility for changes.
This creates “production partnership” – the ability to communicate effectively with both senior stakeholders who determine deployment priorities and operations teams who will support the change. Engineers who can clearly articulate business benefits find their changes approved more readily, while those who provide clear and complete operational guidance find their releases accepted more smoothly by production support teams.
Business Analysis: The Bridge Between Human Need and Digital Solution
Business analysis is fundamentally about human-centered problem solving – capturing authentic business requirements through stakeholder collaboration and translating them into experiences that genuinely serve customers.
Modern business analysis involves design thinking sessions where diverse stakeholders collaborate to understand not just what customers do, but why they do it and what would genuinely improve their lives. Engineers who participate in these sessions develop “customer experience intuition” – learning to spot gaps between what stakeholders say they want and what customers actually need.
This human-centred approach proves invaluable when they return to coding. They write more intuitive interfaces because they understand customer context and make better implementation decisions because they grasp the human journey their software serves.
Functional Testing: The Discipline of Systematic Doubt
Functional testing is essentially systematic doubt – requiring engineers to approach their own work with fresh eyes and imagine all the ways their code might fail. Engineers who spend time in testing roles develop cognitive flexibility – the ability to switch between different mental models of the same system.
They learn to think like users, consider edge cases, and question assumptions. This mental agility makes them better debuggers and more reliable team members. Most importantly, they internalize that software exists to serve users, not developers – a perspective that fundamentally changes how they approach design decisions and error handling.
Non-Functional Testing: Making the System Sweat!
Non-functional testing reveals the invisible architecture that separates good software from great software. Engineers who understand performance and scalability testing develop an intuitive grasp of how systems behave under stress.
They learn to anticipate bottlenecks and build resilience from the ground up. This systems thinking proves invaluable throughout their careers – they make better database decisions because they understand query performance under load, and write more efficient algorithms because they’ve seen how optimizations compound in production.
Penetration Testing: Thinking Like an Adversary
Penetration testing requires engineers to temporarily abandon their role as creators and think like adversaries – imagining how their systems might be exploited or broken. This adversarial thinking transforms how they approach system design, teaching them to consider attack vectors, validate inputs rigorously, and design systems that fail safely.
The benefits extend beyond security. The adversarial mindset teaches engineers to think more rigorously about system boundaries and edge cases, encouraging defensive programming practices that make systems more robust and maintainable.
The Compounding Effect
The real power lies in how these perspectives compound. An engineer who understands change management communicates more effectively with stakeholders. One who grasps business analysis writes more relevant code. One who thinks like a tester builds more reliable systems.
Combine these perspectives, and you get an engineer who can see the complete system – technical, human, and organizational – that their code must serve. They become translators between domains and architects of solutions that work not just in theory but in practice.
The Miyagi Principle in Action
Like Daniel LaRusso, software engineers who embrace seemingly tangential experiences often discover they’ve been building precisely the skills needed for their next level of growth. This isn’t about becoming a generalist – it’s about recognizing that the most valuable professionals can operate effectively across boundaries.
The software industry desperately needs such professionals. As systems become more complex and interdisciplinary, the engineers who thrive will be those who can think beyond their code to the complete ecosystem it must serve.
So the next time someone suggests you spend time in change management, business analysis, or testing, remember Daniel LaRusso. What seems like a distraction might be exactly the experience you need to reach your next level of mastery. Sometimes the best way to become a better software engineer is to step outside software engineering entirely.
After all, wax on, wax off – the movements that seem most irrelevant often build the skills that matter most.