When you start coding, you start the adventure. It feels like unlocking a new world of logic and creativity. From programming classes where we tried to solve pyramid programs to professional work, I used to have fun with coding each day. I chased small wins and learned to debug my own thinking. Each day brought new challenges and opportunities to solve problems through authoring code. The feedback loop was immediate, the learning compounding. Those early years were about craft, curiosity, and fast feedback.
Over time, the role changes. But as my career advanced, my role evolved, steering me towards leadership. Teams grew, systems scaled, and the problems became more about people than syntax. This shift meant a gradual departure from hands-on coding to management, and with it, the risk of getting rusty. Itʼs a known transition familiar to many in the tech industry. The question is not whether to stop coding, but how to stay technically credible while leading.
Analytics Dashboard
Adjusting To New Reality
When Java 8 was released, I was already navigating the waters of leadership. All of a sudden, my calendar was filled with one-on-ones, planning sessions, and hiring loops. Funny enough I still use the same sort of language syntax when I code, mostly out of habit rather than necessity. I use lambdas and streams, but my default is still imperative. I gradually shifted my focus from coding to the broader perspective of project and team management. Be it roadmaps, architecture reviews, and cross-team alignment. It was a bit unusual at first but then it felt alright; the identity shift took time, moving from a maker schedule to a communicator schedule. To avoid drift, I set clear guardrails: time-box leadership work, protect small maker blocks, and keep a live view of the code through reviews and incident write-ups.
What stuck and worked for a while before managing multiple teams was two 60-minute maker blocks on the calendar every week. One for substantive code review per day, pairing on the riskiest change, a monthly deep-dive where I read code paths end-to-end and summarize back to the team.
Focusing On What Matters
As a leader, my days are now filled with project management, hiring, planning, and guiding teams towards success. That means roadmaps, capacity planning, incident reviews, and cross-team alignment on a weekly cadence. My shift has been rewarding in new ways, it brought its own set of challenges. Decision load went up, cognitive overload increased, and feedback cycles got longer.
The tangible impact is technical drift unless it’s actively countered. One significant change is stepping away from hands-on coding, leading to what many call “rustiness” in coding skills. Muscle memory faded. I can still draw boxes quickly, but my editor shortcuts and library choices need refreshing. Iʼm still able to read code without any problem or ask interview questions but writing code professionally is different. It requires up-to-date tooling fluency, current idioms, and production-grade instincts. Those are standards I hold myself to before touching the mainline.
Respecting the Craft of Coding
Stepping away from day-to-day coding taught me something simple: coding requires current context, reproducible workflows, and disciplined review habits. The norms, libraries, and operational expectations keep moving even when leadership work pulls you elsewhere.
For those of us in leadership positions who have moved away from active coding, itʼs crucial to acknowledge that diving back into coding without the necessary up-to-date skills and environment parity (tooling, frameworks, testing, deployment practices, observability basics) can be a business risk with production-grade consequences, from subtle regressions to incident load. Itʼs not just about losing touch with specific programming languages or tools (syntax, build systems, performance profiles, dependency hygiene); itʼs about respecting the craft and its current demands by meeting today’s standards: explicit code quality bars, reliability SLOs, security baselines, and team conventions that have evolved while we led from the balcony.
Finding Balance
The challenge for tech leaders is staying close enough to the work to make good calls without crowding the people doing it. I want to understand the technologies my teams use even when I am not actively coding. In practice, that means one substantive code review a day and, for a line or skip manager, a monthly end-to-end reading of a code path. The point is better team decisions, not personal commit counts.
Now, coding has become a nostalgic and enjoyable part of my life. It’s also a calibration tool that keeps my technical judgment honest. Though my main focus is leadership, I keep the joy of coding alive through fun side projects. These are deliberately low-stakes and time-boxed, with readme notes on what I learned. I occasionally contribute to my GitHub repositories, engaging in these activities for the sheer pleasure of it. That lightweight practice keeps my instincts, editor fluency, and test-first habits from drifting. My fun side projects help me stay connected to my coding roots while embracing my role as a leader in the tech industry. And they make me a clearer, faster partner to the engineers I support.