Before software was my profession

My first program was an airplane drawn with BASIC at school. At university, I encountered Visual Basic and Microsoft Access. Later, during my accounting career, Excel, enterprise accounting systems, and ERP platforms became everyday tools.

Although “software developer” was not yet my title, I regularly worked with programmers as the business-side domain expert. I could explain processes, rules, exceptions, and expected results clearly enough to get unusually good outcomes. Looking back, I was already doing a form of domain modelling: turning real operations into data, rules, and system behaviour.

The first real application

My first substantial application was built with three friends using Java Swing and MySQL. Our practical knowledge was limited, but we were responsible enough to make the system work.

It managed a gym: member registration, tariff plans, barcode-based attendance, reports, cash, and debt. My main responsibility was the relational database design. Normalisation felt unexpectedly natural—possibly because accounting had trained me to think about consistency and relationships, or simply because structural thinking had always suited me.

The application ran locally, as required, and remained in real use for several years. It was not sophisticated by later standards, but it taught me something important: useful software begins with understanding the domain and accepting responsibility for the result.

Learning through unfamiliar technologies

My first professional software role was at DataFoundry AI, working on a platform for a US-based medical-research technology company. I entered a genuinely polyglot environment: Clojure, Java, Python, Pandas, Amazon Redshift, AWS Lambda, and AWS Batch.

Clojure introduced me to Lisp and functional programming. Its elegance was striking, but so was its difficulty. The smaller ecosystem made finding answers harder and forced deeper independent reasoning.

My most important contribution there was a Redshift optimisation. A multi-tenant endpoint took approximately one minute to respond. I redistributed related tables using the study identifier shared by the data and queries, then introduced an appropriate sort key for another frequently used identifier. Response time fell to roughly 400 milliseconds.

Another early engagement took me into C# and .NET modernisation. I worked with Redis-based coordination and designed a configurable logging abstraction supporting files, a database, and Windows Event Log. Even then, I was drawn to separating application responsibilities from concrete infrastructure.

The DataArt years

At DataArt, the variety and scale of systems increased quickly.

On a US-based cross-border employment platform, I worked with Java 14, jOOQ, and Firebase. The system was a well-designed monolith. It taught me an enduring lesson: architectural quality is not determined by whether a system is a monolith or a collection of microservices. jOOQ also showed me how elegant a type-safe, SQL-oriented persistence layer could be.

For a UK financial-markets infrastructure company, I worked on a performance-critical data-processing system using RxJava and Kafka. Data passed through multiple stages of normalisation and validation before reaching Cassandra and Neo4j. I improved Neo4j persistence with Cypher MERGE-based operations, reducing database round trips while eliminating duplicate metadata observed in the existing flow. This was also where I discovered how naturally Cypher expresses relationships that are awkward to represent through relational joins.

On another large UK financial-markets platform, I worked with complex trading-room permissions while a service was being decomposed into several microservices. The architecture included Kafka, the transactional outbox pattern, Feign clients, PostgreSQL, and Liquibase.

Two initiatives from that project remain particularly important to me. First, I designed the database schema migration to work both against populated development and QA environments and against a completely empty environment. Preserving existing databases had not been required, but I wanted the transition to be non-destructive. The same Liquibase migration path successfully handled both brownfield upgrades and clean deployments.

Second, I built audit reporting over trigger-maintained version-history tables. Repeated business keys made ordinary joins produce misleading duplicates, so the data had to be reconstructed through version-aware joins. The resulting audit history was exported as an Excel workbook using Apache POI and returned to the frontend.

Workflows with a visible human consequence

For a major US online travel platform, I helped migrate booking processes from a large Java 8 monolith into a Camunda-orchestrated service architecture.

The new system separated long-running workflows from decision logic. Business rules were composed from reusable predicates, and each migrated process was introduced gradually: a small portion of production traffic went to the new implementation before the full cutover. This was my practical introduction to workflow orchestration, composable rules, and progressive delivery.

One process remains especially meaningful to me: wheelchair-assistance requests for air travellers. It was one workflow among many inside a shared reservation backend serving several global travel brands, but it made the human effect of backend software tangible. Somewhere downstream, the process I helped migrate contributed to a traveller receiving the assistance they needed at an airport.

Integrating and modernising live platforms

For a global online betting and gaming group, I first worked on a difficult post-acquisition integration. Two large systems had to operate together while mandatory capabilities from the acquired platform—particularly bonus calculation and management—remained in place. Their separate identity systems also had to be federated.

The surrounding product used one shared codebase but was deployed independently for multiple customers. Every change required strict cross-client compatibility review. It taught me to think beyond “making a feature work” and instead design capabilities that belonged safely in a shared product.

I later worked on a real-time sports-data platform. Provider adapters fetched external feeds, validated and normalised them into a canonical model, and published them through ActiveMQ Artemis. A core service performed further transformations, persisted data in MySQL, and supplied downstream systems.

My work included a provider integration, concurrency and resource-correctness fixes, database connection-pool corrections, documentation, and the modernisation of multiple services from Java 8 to Java 21 and Spring Boot 2 to 3. I also reduced unnecessary Hazelcast coupling, prepared the platform for Kafka, and introduced a configurable cache abstraction designed to support Hazelcast and Redis-compatible implementations without changing business code.

Building independently

Outside client work, I build systems around questions that interest me.

dtrd is my Java trading-engine project. It lets me work directly with real-time market data, WebSocket streams, ring buffers, broker-independent boundaries, timing constraints, concurrency, and risk controls. It is an independent engineering laboratory for real-time market systems and performance-conscious Java design.

Through the j-util open-source initiative, I design and publish focused Java libraries to Maven Central. inputstream-processor-core processes items incrementally without materialising an entire input first; columnar-projection-store generates typed, column-oriented in-memory stores; reduction-store maintains client-defined aggregate states during ingestion; and splice-list explores O(1) whole-list transfer through structural splicing.

Going below the abstraction

I have rarely been satisfied with knowing only how to use an API or framework. When a subject matters, I keep following it downward: from concurrent code to memory visibility and synchronization algorithms, from data structures to CPU caches and locality, and from distributed behaviour to the reasoning that makes it correct.

This habit often takes me beyond the immediate requirements of a project. The purpose is not technical depth for its own sake, but to build mental models that remain useful when technologies change.

During self-directed learning, I began looking beyond popular programming books toward the papers and lectures of the computer scientists who established the foundations. Leslie Lamport became a particularly important influence. His conviction that programming begins with precise thinking—understanding and specifying what a system must do before expressing it in code—felt less like a new method and more like a formal articulation of how I had always approached problems.

What connects the journey

Across these systems, I have worked through the main layers of modern backend engineering: application logic, workflows, messaging, caching, relational and graph storage, analytical databases, cloud infrastructure, and production delivery.

The technologies changed, but their responsibilities repeated. Understanding those boundaries has allowed me to move between alternatives without beginning from zero each time.

The common thread is structural thinking: modelling a domain carefully, preserving correctness under concurrency and change, improving performance where it matters, and making difficult transitions safe for the people and systems already depending on the software.