Originally published on LinkedIn on 5 January 2026
At the beginning of 2026, I decided to make a deliberate change in my professional direction: to reconnect more directly with hands-on software engineering.
This was not a rejection of leadership, architecture or the experience accumulated during a long career. It was a recognition that the work I have always found most satisfying begins with understanding how systems operate and then building something that solves a real problem.
Returning to where it started
I began programming professionally in 1986, working initially with BASIC, C and x86 assembly language. Those early environments required a close understanding of the computer itself. Memory, processing capacity and storage were limited, and inefficient design could not easily be hidden behind additional hardware.
That experience gave me an enduring interest in performance, correctness, resource management and the internal behaviour of software.
Over the following years, I worked with C++, COBOL, Clipper, SQL, UNIX and other technologies. I developed business applications, reusable software libraries, database-connectivity components and development tooling. I also created source-management, automated-build and deployment processes long before practices such as continuous integration and continuous delivery became established industry terminology.
C++ remained especially important to me. It offers a combination of performance, control and expressive power that few languages provide. It rewards disciplined engineering and makes the consequences of design decisions visible.
How my career moved away from daily coding
As my career progressed, my responsibilities expanded.
I moved from software development into systems engineering, performance analysis, infrastructure, solution architecture, enterprise architecture and eventually engineering management. I led teams across Platform Engineering, DevOps, SRE, Cloud Operations and Security.
These roles gave me a much broader understanding of technology.
I learned how software behaves in production, how architectural decisions affect operations, how technical debt accumulates and how organisational structures influence engineering outcomes. I also learned that many failures attributed to individual components are actually consequences of interactions between applications, operating systems, databases, storage, networks, security controls and human processes.
Leadership added another dimension: building teams, coaching engineers, setting priorities, resolving conflicts and creating the conditions in which people can deliver good work.
However, the more senior the position became, the less time remained for direct engineering. Calendars filled with planning sessions, stakeholder meetings, performance discussions, budget decisions and organisational work. These responsibilities were important, but they gradually increased the distance between me and the activity that originally brought me into technology: building software.
Experience should strengthen hands-on work
Returning to hands-on engineering does not mean starting again from zero or pretending that the intervening years did not happen.
The objective is to apply that experience more directly.
An engineer who has also been responsible for production reliability, security, architecture and team delivery approaches software differently. Questions arise earlier:
How will this behave under load?
How will it fail?
How will it be tested and deployed?
How will operators understand what it is doing?
What information will be available during an incident?
Which assumptions could become future constraints?
Can another engineer maintain it without depending on undocumented knowledge?
Does the design solve the actual problem without creating unnecessary complexity?
Clean code matters, but production-quality engineering extends beyond code. It includes operability, observability, security, maintainability, predictable failure behaviour and a clear understanding of trade-offs.
Rebuilding day-to-day fluency
C++ remained my primary technical passion, but modern engineering rarely exists within the boundaries of one language.
For that reason, I also worked on rebuilding practical familiarity with C#, Java, Go and Swift. Each serves different environments and encourages different approaches to software design.
The purpose was not to claim identical expertise in every language. It was to recover the daily rhythm of implementation: reading unfamiliar code, designing components, debugging behaviour, writing tests and turning requirements into working software.
Technical knowledge does not disappear entirely, but fluency requires use. Just as leadership improves through practice, hands-on engineering becomes sharper through repeated contact with real problems.
The role I wanted engineering to play
I was particularly interested in products and systems where performance, correctness and engineering discipline genuinely matter.
That could include infrastructure software, platform tooling, security products, developer tools, distributed systems, storage, observability or other technically demanding environments.
My ideal contribution would combine several parts of my background:
the discipline of a software engineer;
the systems perspective of an infrastructure specialist;
the judgement of an architect;
the production awareness of a DevOps and SRE practitioner;
the risk awareness of a security professional;
and the organisational understanding developed through engineering leadership.
Those capabilities do not need to compete with one another. Used properly, they reinforce each other.
A deliberate reconnection
This decision was not about moving backwards.
Careers do not always need to follow a single upward path in which every new position creates greater distance from implementation. Sometimes the most valuable move is sideways—or back toward an earlier discipline—with a much wider understanding than before.
For me, reconnecting with software engineering meant returning to something fundamental: the satisfaction of taking a difficult problem, understanding it properly and creating a solution that is clear, reliable and useful.
Experience should not become a barrier between a technologist and the technology.
It should make the work better.
This article is based on my original ideas, experience, analysis and conclusions. Artificial intelligence tools were subsequently used as editorial and research assistants to review grammar and wording, improve structure and presentation, organise some arguments into clearer logical sections, and help review references to legal, regulatory and technical concepts.
Where relevant, factual and regulatory references were checked against the sources cited in the article. AI assistance does not replace professional legal, regulatory, financial or technical advice, and the final selection, interpretation, opinions and conclusions presented here remain my own.
Comments
Post a Comment