This year will mark the twelfth anniversary of my software development career. While that’s not much, I’ve learned a lot throughout the years. And I see I still have a ton to learn about software organizations. This article is a short reflection on the crucial stages in my career. By crucial I mean stages that have led me to a change in the way I think and act. I believe this is a key trait of a software engineer. Otherwise, we succumb to archaic concepts which is unacceptable in such an innovative and competitive field.
So, once upon a time…
I was a Critical Outsider
My journey in professional software engineering began earlier than most of my peers. At 19, while still in university, I landed my first role in game development. This early start gave me a unique position – I was earning a good salary that allowed me to live independently, covering my university fees, rent, food, and other expenses while most of my classmates were still focused solely on their studies.
This gave me a lot of confidence and a know-it-all attitude. Apart from that I was eager to learn, so I immersed myself in software engineering literature. Books like “The Mythical Man Month,” “The Pragmatic Programmer,” and “Peopleware: Productive Projects and Teams” shaped my theoretical understanding of how software organizations should function. Armed with this knowledge, I felt equipped to identify everything that was “wrong” with my workplace.
What I didn’t realize was how theory-heavy and experience-light my perspective was. I could quote Brooks and DeMarco, but I hadn’t yet earned my stripes as a productive team member. This disconnect between my theoretical knowledge and practical contribution affected both my performance and how I interacted with colleagues.
The wake-up call came just three months into my first job. My manager delivered sobering feedback: if my performance didn’t improve, they would have to let me go. This was the jolt I needed to recognize that before I could change an organization, I needed to prove my value to it.
I shifted my focus from critiquing processes to applying my engineering knowledge in ways that actually helped the team. Instead of pointing out problems, I started contributing to solutions. The change in approach paid off – while I wasn’t transforming into a rock star developer overnight, I received a raise shortly after my course correction and remained with the team until an opportunity arose to work with Camplight.
This phase taught me that influence comes after impact, not before it. No matter how well-read you are, your ideas only gain traction when you’ve demonstrated your ability to deliver value within the existing system, however imperfect it might be.
Then, I moved fast and broke things
When I joined Camplight, I became part of their biggest team working on an ERP system for private clinics. Despite my earlier wake-up call, I hadn’t learned my lesson. From day one, I started pitching “better” processes to the team, convinced I knew how to improve our work.
Our team moved fast. We cared about quality, but not enough. Our motto might as well have been “ship now, fix later.” This approach seemed to work at first – we delivered features quickly and got lots of feedback. But over time, our system became harder to maintain. Small changes started taking longer. Bugs became more common. Technical debt piled up.
I developed a tense relationship with our clients. In my mind, they were often the problem. I believed:
- Requirements shouldn’t change much once we started working
- We should release work early and often, even if it was low-quality code
- When problems came up, it was usually because we didn’t follow “the process”
If a feature didn’t work right, I’d blame unclear requirements. If the system was slow, I’d say we needed more time to optimize it. If clients were unhappy, I thought they just didn’t understand software development.
I was so focused on processes that I missed the point: we were building software for real people with real needs. Our job wasn’t to follow a perfect process – it was to solve problems for our clients in a sustainable manner.
About 8 years in, I discovered the value of eXtreme Programming
My journey into eXtreme Programming began through social media, where I followed thought leaders like Alex Bunardzic and Kent Beck on LinkedIn. I was drawn to their perspectives on software development, which challenged my existing views.
The turning point came when Alex commented on one of my posts about traditional management. I had argued that managers should give individual feedback that’s on point and fair. Alex pushed back, suggesting that focusing on the team, not the individuals gives better results than micromanagement. This exchange made me reconsider my mindset.
As I explored further, mob programming caught my attention. The collaborative approach seemed not just enjoyable but practical – it addressed real problems I’d seen in teams: bottlenecked code reviews, knowledge silos, and the constant context-switching that drains productivity. Watching teams work together in real time, I saw how quickly they could solve problems and how naturally knowledge spread throughout the team. Apart from that, it was a really enjoyable way to work together.
Test-Driven Development made sense as a natural companion to mob programming. It created a tight feedback loop that kept quality high and provided a safety net for refactoring. Meanwhile, Trunk-Based Development eliminated the merge conflicts and integration delays that plagued many teams I’d worked with.
These practices formed a coherent system in my mind. I began to see how they complemented each other to create an environment where teams could deliver high-quality software consistently. While I never had the opportunity to work in a fully XP-practicing team, I became convinced of its potential.
But I had learned from my earlier mistakes. I knew that advocating for changes without first establishing credibility would only create resistance. My approach shifted to patience and persistence: first contribute value within the existing system, then gradually introduce improvements when the time is right.
I started looking for small opportunities to demonstrate these practices – suggesting a paired programming session to solve a tough problem, doing TDD whenever I implement a feature, or proposing shorter-lived branches. Each small success created an opening for more.
This period taught me that good ideas need good timing. The best practices in the world won’t take root if the team isn’t ready for them or if the person suggesting them hasn’t earned the right to influence. I remained convinced about the value of XP practices, but became more strategic about how and when to introduce them.
Meanwhile, I started to understand the value of balanced views
As I deepened my understanding of eXtreme Programming, I simultaneously developed a more nuanced view of software development practices. This wasn’t a sequential shift but happened alongside my growing appreciation for XP.
I noticed a divide in the software community. XP advocates often spoke to an echo chamber, rarely gaining traction outside their circle. Meanwhile, those promoting other methodologies occasionally received acknowledgment from XP practitioners, but meaningful cross-methodology dialogue was uncommon. The community resembled tribal camps rather than a profession united in solving problems.
This division challenged me. If I truly believed in the value of every human perspective, how could I reconcile that with my growing conviction about XP practices? I realized that contributing to this polarization with rigid advocacy wouldn’t advance our field or make humanity better. Instead, I needed to develop a balanced approach that honored context and respected different viewpoints.
My conviction about XP’s effectiveness hasn’t wavered. I still believe that mobbing, TDD, etc. create powerful synergies that can transform team performance. But I’ve come to understand that disregarding other perspectives doesn’t bring value – it only creates resistance.
Organizations, even small ones, are intricate systems with unique histories, constraints, and cultures. A practice that thrives in one context might fail in another, not because the practice is flawed but because the environment isn’t ready for it. There’s no universal formula for improvement.
The most valuable skill I’ve developed is seeking to genuinely understand different viewpoints before suggesting changes. This means asking questions rather than making statements, listening more than speaking, and approaching differences with curiosity instead of judgment. Only through this understanding can you identify the right moment and approach for introducing new ideas.
Sometimes this exploration leads to surprising insights. Processes that seem inefficient at first glance might address important concerns I hadn’t considered. In rare cases, I’ve found that maintaining the status quo was better than pushing for change – at least for that moment in time.
Looking Forward – Moldable Development
My journey into moldable development began with a provocative statement from Alex Bunardzic that challenged my fundamental understanding of programming: “We shouldn’t program by manipulating text. We should do it by manipulating Abstract Syntax Trees.” This idea struck me as both radical and obvious once I considered it. Why are we still working on the text level of code, instead of raising the abstraction?
This seed of an idea gained clarity when I encountered AI-assisted development with Verification, as articulated by Jeff Langr. The concept showed how we might interact with code at a higher level of abstraction while maintaining precision and control. It wasn’t about replacing human thought but enhancing it with tools that operate at the right level of abstraction.
My exploration of these concepts has been influenced by Simon Wardley’s work. I’ve long appreciated his systematic approach to strategy and his commitment to advancing collective knowledge rather than personal gain. Wardley’s thinking taught me to look for patterns and evolution in technology rather than getting caught in cycles of reinvention.
The breakthrough came when I discovered “Rewilding Software Engineering” by Wardley and Tudor Girba. The book’s thesis is that our development environments haven’t evolved to match the complexity of the systems we build. We’re trying to understand intricate, dynamic systems through static text files – like trying to understand a forest by looking at pressed leaves.
This led me to Glamorous Toolkit, a moldable development environment that embodies these principles. It allows developers to create custom tools and visualizations specific to their domain and problem, enabling them to interact with code in more meaningful ways than just editing text.
I’m just beginning this exploration, but it’s already shifting my perspective. Where I once focused almost exclusively on process improvements (mob programming, TDD, etc.), I now see that the tools we use are equally important. The best process can’t overcome fundamentally limited tools, and powerful tools enable better processes.
Conclusion
My evolution as a software engineer has taught me that there’s no single “right way” to build software. What started as rigid thinking about processes has developed into a more balanced view that considers technology, process, and people.
The key lesson I’ve learned is that effective change requires both strong convictions and the humility to recognize context. This balance has made me more valuable to teams at any stage of development. As I continue exploring approaches like moldable development, I’m focused on expanding my toolkit rather than finding a universal solution. Software development is ultimately about solving problems together, which requires flexibility above all else.
