I have… opinions about the book. Some of its prescriptions feel too neat for the messy reality of production systems. But the tactical tornado was a direct hit. Ousterhout named something I had seen repeatedly but never had a clean language for.

And more uncomfortably, he named something I had been.

Visible Output Wins

Ousterhout’s central thesis is that complexity is the root problem of software and that it accumulates incrementally. Nobody decides to build a complex system. It emerges from hundreds of small decisions, each seemingly harmless, each adding a thin layer of friction that the next developer will have to work through.

The tactical tornado is the human embodiment of this accumulation: someone who makes those small decisions faster than anyone else, and always in the direction of more complexity.

Ousterhout draws a distinction between tactical and strategic programming. Tactical optimizes for the next feature, the next fix, the next thing that needs to ship. Strategic treats working code as necessary but insufficient; the real goal is a great design that also happens to work. The tornado is the extreme case of the tactical mindset: zero investment in design, maximum visible output, and a trail of shallow abstractions left behind for others to navigate.

Tactical tornadoes often get praised and promoted because their output is visible and their damage is not. The engineers who clean up after them appear to be making slower progress by comparison. This is how the incentive structure ends up working against the people doing the harder, more valuable work.

It does so reliably enough that you can predict the outcome: the tornado rises, the maintainers burn out, and the codebase degrades.

Built for the System

As I have already mentioned, I’m not writing this from the outside.

I have been the person called into a meeting and asked to slow down. The conversations were polite. The message was clear. I was producing code faster than anyone around me, and the wake I left behind was becoming a problem for the team.

At the time, I understood the feedback intellectually while feeling, somewhere deeper, that the real issue was everyone else’s inability to keep up.

That feeling is what makes the tactical tornado so difficult to correct. The speed is real. The output is real. The praise is real. The damage is real, too, but it is distributed across other people’s schedules, other people’s frustration, and future sprints that haven’t happened yet. The feedback loop that would correct the behaviour is delayed long enough that the behaviour gets reinforced instead.

I am not alone in this recognition. In an SE Radio interview, Jeff Doolittle told Ousterhout that there is a whole unnamed category of recovering tactical tornadoes, people who were never acting out of malice but responding to the incentives around them.

That framing matters.

The tornado is not a villain. They are often the person most adapted to survive in the system they are in.

If you treat the tornado as a character flaw, the solution is coaching or removal. If you treat it as a system outcome, the solution is to redesign the incentives. Both may be necessary, but only the second one prevents the next tornado from forming.

Deeper Than Code

Most commentary on the tactical tornado stays at the level of code quality. The tornado writes messy code, others clean it up, and complexity grows. That framing is accurate but incomplete, because it misses the organizational dimension entirely.

Conway’s Law runs in both directions. The organization shapes the system, and then the system shapes the organization back. The tactical tornado exploits this bidirectional dynamic in a way that is rarely discussed.

When a tornado moves through a codebase, other engineers route around the damage rather than engaging with it. They build interfaces that insulate their own work from the tornado’s output. Over time, this avoidance becomes structural. The team’s actual communication topology starts to reflect not the ideal architecture but the boundaries of the tornado’s impact area.

The tornado’s code is shaping the organization.

Even after the tornado moves on, or slows down, or gets promoted out of the code, the team carries the scar tissue. People still avoid those modules. Knowledge remains siloed in whoever was brave enough to touch it. New engineers inherit not just the messy code but the organizational habits that formed around it: the workarounds, the unwritten rules about which parts of the system you simply do not touch.

That is what makes the tornado problem an architectural problem, not just a code quality problem. The damage is sociotechnical. Refactoring the code is necessary but insufficient. You also have to refactor the team’s relationship to the code, which is a much harder and longer process.

Code can be rewritten in a quarter. Organizational scar tissue takes years to heal.

The effect is, of course, amplified when the tornado is also a senior engineer or a team lead. Their design decisions carry organizational weight. Their module boundaries become team boundaries. Their shortcuts become conventions. The system calcifies around their tactical choices, and what started as one person’s speed becomes the entire organization’s constraint.

The tactical tornado is not just a complexity accelerator. They are an organizational architect, designing the team’s communication structure without realizing it, and without anyone reviewing the design.

Mess, Accelerated

All this was already true long before augmented coding entered the room. What AI adds to the mess is scale.

Ousterhout himself, in a recent conversation with Gergely Orosz, described current AI coding tools as tactical tornadoes. They produce code fast, fix issues fast, and generate technical debt at speed. That characterization is sharp, but the deeper problem is not that AI acts like a tornado. It is that AI pulls the human toward tornado behaviour.

Facundo Olano makes this argument clearly. LLMs operate task by task, diff by diff. There is no big-picture thinking in the process, no consideration of conceptual integrity. The human is supposed to supply those things, but the tool actively works against that mindset. The more detached you become from the low-level code, the harder it is to maintain a tight mental model of the system’s design and runtime behaviour.

I recognize this tension from my own work. The feeling of speed that AI provides is the same one I had in my code-writing days, the one that got me called into meetings. The difference is that now the speed is available to everyone, and the organizational structures that might have caught the damage are under pressure to get out of the way because they slow things down.

Code review, design discussions, and architectural governance. All of them feel like friction when AI can produce a working implementation in minutes.

There is also a troubling productivity question. Who gets a greater boost from AI coding tools: the strategic developer who invests in documentation, context, and design, or the tactical tornado who fires prompts and ships? One analysis suggests the tornado gets a higher multiplier because AI is already good at reaching a working state with minimum effort. If that is true, the share of tactically produced code will rise, and technical debt will accelerate across the industry.

The Conway’s Law dimension makes this exponentially worse. If AI-generated code shapes organizational communication patterns the way human-written code does, and there is no reason to think it would not, then the sociotechnical damage compounds faster than any team can address.

We are not just scaling the tornado’s code output. We are scaling the organizational distortion that follows it.

Speed Is a Choice

Having been the tornado myself, I can deliver this counterargument without hedging.

Speed is not inherently destructive. There are moments when tactical programming is the correct choice. A proof of concept that needs to validate a hypothesis before anyone invests further. A time-bound market opportunity where being second means being irrelevant. An incident response where the priority is stopping the bleeding, not writing elegant code.

Even Facebook’s engineering motto evolved over the years, from celebrating breakage to demanding stable infrastructure, which suggests the industry’s relationship with tactical speed is still being negotiated, not settled.

The problem is not speed itself but the failure to recognize when speed has become the default mode rather than a deliberate choice. The tornado does not choose to be tactical. They simply never switch out of it. And the organization, by rewarding their output, never gives them a reason to.

Ousterhout suggests investing 10 to 20 percent of development time in design improvement. That number is less important than the principle behind it: strategic thinking is not a separate activity from coding. It is a continuous investment, a small tax on every task that pays compound returns over time.

The tornado invests zero. They are not failing to invest. They are actively divesting, extracting design capital from the codebase, and converting it into visible output.

The question every team should ask is not whether they have a tactical tornado. It is whether their incentive structure would produce one.

Listen to the Room

Being asked to slow down did not feel like a gift at the time. It felt like a misunderstanding. I was producing more than anyone around me. The metrics confirmed it. The feedback from stakeholders confirmed it. The only people who seemed unhappy were the engineers working alongside me, and I could not yet see that their unhappiness was the most important signal in the room.

Understanding came later, gradually, through years of working on systems shaped by the same behaviour I had exhibited. Through inheriting code that was fast to write and brutal to maintain. Through watching teams route around modules that nobody dared touch. Through seeing, from the other side, how the tornado’s speed becomes the organization’s constraint.

Ousterhout gave me the language. The colleagues who pulled me aside gave me the correction. Both were necessary. Neither was sufficient on its own. The language lets you see the pattern. The correction lets you feel its cost.

If someone has pulled you into a meeting to ask you to slow down, do not treat it as criticism. Treat it as information about your impact, the kind that no metric will ever capture and no AI tool will ever flag.

Trust me, the feedback is far more useful than it will feel at the time.

It should have been easy terrain for someone who has spent years inside the problem, but what came out was a few sentences that gestured at decisions and trade-offs without ever landing anywhere. She nodded in the way people nod when they are being polite to someone who has just disappointed them. Almost four months later, I am still turning the question over, which is either embarrassing or instructive.

I have decided to treat it as the latter and write up what I owe her.

The Short Answer Problem

The resistance to a clean answer shows up immediately when you go looking for a definition. The closest thing to a satisfying formulation belongs to Ralph Johnson, one of the four authors of Design Patterns, the book that shaped how the industry thinks about software structure. After all that engagement with the problem, Johnson arrived at something that sounds almost flippant:

Architecture is about the important stuff, whatever that is.

Martin Fowler, who often returns to this line, treats the deliberate vagueness as a feature rather than a bug. The longer I’ve spent on architectural problems, the more I think he is right.

Whenever I’ve tried to give a more precise version of that formulation, something slips. “Architecture is about structure” works until you notice that a pile of undifferentiated code has structure too, and most of it isn’t architectural. “Architecture is about decisions,” works until you ask which ones count, and where you draw that line depends entirely on context. “Architecture is the decisions that are hard to reverse” is closer, but reversibility is partly a function of how the rest of the system is built, which puts you in a loop before you’ve arrived anywhere.

I’m not alone in this struggle. The Software Engineering Institute maintains a compiled catalogue of definitions across modern, classic, and bibliographic sources, and the fact that such a catalogue exists and keeps growing is itself data. That is not a gap in the literature waiting to be filled.

It is signal about the nature of the thing.

What Architecture Is Not

The space left by every failed definition does not stay empty for long. A few specific misconceptions keep filling it, and each one was invited by some shorter version that came before it.

The first, my favorite, is that architecture is the diagrams. UML, C4 models, whiteboard sessions and ADRs are representations of architecture, and useful ones, but they are not the thing itself. A decision shapes what is possible, what is difficult, and what is effectively ruled out, regardless of whether anyone drew it on a whiteboard or wrote it down. You can tear up the whiteboard. The structural commitment has already been made.

The second misconception is that architecture is a phase. You do the architecture work, hand it off, and then engineering builds the thing. That model comes from construction, where you can hand off a completed design and step back, but software never reaches a completion state. It keeps changing; the structure that shapes it needs to keep being shaped, and a system left without active tending decays. Entropy is not a metaphor for codebases. It is the normal trajectory of any system that nobody is attending to.

The third misconception is that architecture lives in a role. One person or a small group owns the structural decisions, and everyone else builds inside them without needing to understand or influence them. This is the most consequential of the three because it concentrates exactly the wrong thing in exactly the wrong place. An architect who owns all the decisions has also insulated themselves from the feedback that would improve those decisions. The engineers closest to implementation are the ones who will live with the consequences, and cutting them out of the process means cutting out the most important signal in the room.

Deciding Which Tension to Accept

Clearing those misconceptions away is useful, but it still leaves the original question open. What I’ve found myself reaching for, when people push past the misconceptions and ask what architecture actually is, is this:

The practice of deciding which tensions to accept and which to release.

Every structural decision trades something: consistency against availability, deployability against performance, team autonomy against system coherence, and there is no configuration that resolves all of these simultaneously.

If you think you’ve found something without a trade-off, you just haven’t found it yet. Nobody opts out.

The right trade-off is always context-specific. The skill is not knowing the right tension to accept in the abstract but recognizing which tensions a specific context can absorb, which ones will compound painfully over time, and being deliberate about the choice rather than stumbling into it.

That relocation is the point. As the old adage goes, complexity cannot be destroyed, only relocated. The architect’s job is to decide where it lives and why that location is better than the alternatives, and no short answer can carry that much context without losing most of what matters.

The Organization Is the Architecture

One of the things it loses almost every time is the organizational dimension, and that loss is not trivial. Any definition of architecture that stops at the technical is incomplete. In 1968, Melvin Conway made an observation that reads almost like a complaint about a frustrating project: any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.

This may be hard to believe today, but Harvard Business Review actually rejected the paper (for lack of evidence). Decades later, a Harvard Business School study confirmed exactly what Conway described, and subsequent research at MIT, the University of Maryland, and Tampere University of Technology validated it independently.

Conway illustrated the dynamic with a story from a compiler project he assigned to eight engineers, five to COBOL and three to ALGOL. Nobody decided how many phases each compiler would have, yet the COBOL compiler ended up with five phases and the ALGOL compiler with three. The structure of the output matched the structure of the team that built it, as an unintended emergent outcome, without anyone planning it.

If you’ve spent time inside a large engineering organization and wondered why the system looks the way it does, that story will feel less surprising than it should. The uncomfortable version of the observation is that the relationship runs in both directions. The organization shapes the system, and then the system shapes the organization. Teams form around modules, and modules persist because teams formed around them. Technical and organizational concerns co-evolve in ways that make it impossible to cleanly separate them, which is another reason any short definition falls apart. It leaves out half of what is actually happening.

Separating Decision from Construction

That missing half also reshapes how we need to think about the architect’s role. The broken metaphor at the center of how the field thinks about the architectural role is the building architect: design first, hand off to construction, step back.

The word itself comes from the Greek arkitekton, meaning chief builder, and the original was not a separate designer standing apart from construction. The chief builder was the most skilled person on the site, someone who understood the full problem from the inside. The software industry borrowed the building architecture metaphor wholesale and quietly erased that origin, replacing it with a designer insulated from consequence.

Erik Dörnenburg identified this as a structural information problem, not a cultural one. When the decision-maker is systematically insulated from the feedback loop that would otherwise correct bad choices, the design drifts from the reality it is supposed to serve. The distinction Dörnenburg draws is between being aware of consequences and having to live with them, and that gap is where architectural decisions quietly degrade. The moment you separate design from construction, you are separating decision from consequence.

This leads to a formulation that still surprises people when they hear it:

An architect’s value is inversely proportional to the number of decisions they make.

The goal of architectural leadership is to build the capacity for good structural decisions to happen across the teams doing the work, not to own those decisions permanently. This often gets misread as architecture without accountability, which couldn’t be further from the truth. It requires far more architectural maturity, not less, because teams need to maintain decision records, argue trade-offs honestly, and hold themselves to a standard.

The concept only works where that maturity exists, and building that maturity is itself one of the architect’s main jobs.

The Elevator and the Engine Room

What that job looks like across an entire organization is something Gregor Hohpe captures in a metaphor I’ve returned to more than almost anything else in this field. Large organizations are tall buildings. The IT engine room is in the basement: the systems, the infrastructure, the code. The executive penthouse is at the top: the strategy, the resourcing decisions, the market bets. Between them are floors of management, and each floor is a translation layer where information degrades as it moves in either direction, telephone game dynamics at the organizational scale. The architect’s job is to ride the elevator, carrying meaning intact in both directions across those translation layers.

I run an Architecture Modernization Enabling Team (AMET) at Epignosis, and this is what the work actually looks like in practice. The problems that determine whether a modernization succeeds are not purely technical. They are questions about which teams have capacity for which changes, how organizational constraints shape what sequences of work are even possible, and where leadership understanding needs to deepen before a technical choice can be made safely.

Architecture that stays in the engine room is working with half its inputs. Hohpe puts it plainly:

Excessive complexity is nature’s punishment for organizations that are unable to make decisions.

Architecture is also about options, the right to defer a decision while locking in key parameters. In volatile conditions option value increases, and a system locked by deep coupling has had its options foreclosed. Modernization, in this framing, is not paying off the past. It is rebuilding the capacity to choose.

That framing also redefines what an enabling team is for. An enabling team exists to build capability in the teams doing the product work, not to own the work permanently.

The AMET model applies this logic specifically to modernization, as a bell curve of involvement that increases as capability is built and decreases as teams internalize it, until the enabling team eventually dissolves. That lifecycle is not the failure mode. The failure mode is an enabling team that never dissolves because it keeps doing the work instead of transferring the capacity.

There is a second failure mode that gets less attention, which is the team that dissolves before the capability transfer is genuine. The downslope of the bell curve only resolves correctly when the skills and confidence are actually there, and premature dissolution looks like success until the teams are on their own and discover what they did not actually internalize.

Both these failure modes point at the same thing from different directions: architecture done well is partly an exercise in making itself unnecessary. That is not something you can fit into two sentences without losing everything that makes it true.

The Foundation and What It Enable

What it makes possible is the part of the argument that gets framed backwards almost every time I hear it.

The common version treats modernization as competing with innovation, time spent on the foundation is time not spent building new things, and every sprint on the former feels like something stolen from the latter.

What this misses is that a system that has not been modernized does not just move slowly. It actively constrains which questions engineers are allowed to ask, and when every change requires deep knowledge of how the system currently holds together, the mental load shifts from “what should we build?” to “what can we build without breaking everything?” That is not a resource problem. It is a cognitive constraint that narrows the product imagination of the entire organization.

What modernization actually enables is optionality: the capacity to change direction without foreclosing the future, to experiment in one slice of the system without risking another, to run multiple hypotheses simultaneously because the boundaries are clean enough to hold them.

The features you could not build on the old foundation leave no trace, and nobody wrote them on a roadmap. The innovation that never happened is invisible, which is precisely why modernization is chronically undervalued: its benefits are counterfactual, and counterfactuals do not appear in sprint reports.

The Question Persists

The same invisible cost applies to the question itself. An engineer without language for what architecture is will still make structural decisions, and that gap accumulates silently, below the threshold of any report, in exactly the same way as the features that never got built.

Which brings me to the part where I go against everything in this article and add to the pile:

Architecture is the practice of maintaining the conditions under which better decisions remain possible.

You can probably drill more holes in it than in most short definitions. But it happens to be the one I like the most, and the one I wish I had at the ready four months ago. It would not have been a satisfactory answer, of course.

But it might, just might, have saved me from that polite nod.

Data spent seven seasons pursuing what seemed like a central question: could a machine become enough like us to count as one of us? He painted. He composed music. He kept a cat. He formed friendships and tried to understand humor. The show treated his journey toward humanity as the natural arc of advanced AI. If you built something intelligent enough, it would want to be human, and we would need to decide whether to accept it as such.

Watching those episodes now, that entire framing feels like archaeology. We built systems that scored well and shipped well, and it turned out that the question Data embodied was never the one we needed to answer.

The Prelude to Personhood

When I was a kid, Data was how I thought about AI. Not because the show predicted neural networks or anything that technical. He just made the whole thing feel concrete. An android smart enough to serve on a starship bridge would naturally want recognition as a person. The show never questioned this premise. Neither did I.

Another favourite, Isaac Asimov’s “The Bicentennial Man,” operated from the same assumption, only more explicitly. Andrew Martin starts as a household robot, a roomba on steroids, who discovers creativity and the desire for recognition. He spends decades pursuing legal status as a human being, accepting mortality so society will finally see him as a man rather than property. The story culminates in his death being recognized as the death of a person, not the deactivation of a machine. Both stories treat capability as the prelude and recognition as the inevitable fight. Intelligence implies personhood. Personhood requires the desire to belong.

The logic seemed airtight. Once that premise is accepted, the rest follows. Building sufficiently advanced AI would force us to answer hard questions. Does consciousness emerge from complexity? What separates persons from sophisticated tools? Data serving on a starship bridge meant confronting those questions. Andrew cleaning a household meant the same thing. The technical problems would get solved, and then the real challenge would begin.

A Test for Thinking Machines

Alan Turing gave us one answer to that recognition problem. His 1950 paper “Computing Machinery and Intelligence” proposed a deceptively simple test: if a machine could participate in a conversation well enough that a human observer couldn’t reliably distinguish its responses from those of another human, we should grant that the machine was thinking. The elegance of the Turing Test was in sidestepping metaphysics entirely. Instead of debating what consciousness really is, Turing suggested we could evaluate intelligence through observable behavior.

The test embedded an assumption that stayed with us for decades. Human-like performance in conversation became the benchmark for intelligence. If you could fool someone into thinking you were human, you had crossed a threshold that mattered. The test didn’t require the machine to want anything or feel anything. It just needed to produce the right outputs in the right context. But it still pointed toward human-like interaction as the thing worth measuring.

When Performance Became Enough

I remember when Deep Blue beat Kasparov in 1997. It felt like a threshold moment. A machine had beaten the best human player. When that happened, it should have triggered the questions that Data and Andrew made central. Did Deep Blue want to win? Did it experience satisfaction? Should we care?

Nobody seriously argued it should be treated as a person. The machine beat the world’s best human player, but no one suggested it deserved rights or recognition. Deep Blue did something useful. That was enough. The reaction was scoreboard-based. The system didn’t need to present as a mind. It needed to win. The evaluation harness was performance, not personhood.

AlphaGo defeating Lee Sedol in 2016 followed the same pattern. The victory generated excitement about what AI could accomplish, not anxiety about what we owed it. Nobody worried about whether AlphaGo experienced pride or frustration during the matches. The system solved a problem humans found difficult. The personhood question never surfaced.

These victories showed something important about how AI evaluation had shifted. We stopped asking whether machines could think like us and started asking whether they could deliver outputs we cared about. The benchmarks that mattered measured performance on tasks, not similarity to human cognition or behavior. What we tested became what we decided mattered.

The Incentive Structure

Better benchmark scores led to more citations, more funding, and more talent. Better product performance led to more users, more revenue, and more iteration capacity. Benchmarks and product requirements pushed AI development in a specific direction because they connected directly to resources. These feedback loops pointed toward capability, not consciousness. The industry optimized for what could be measured and sold.

This wasn’t a philosophical decision. You can A/B test task completion rates. You can’t A/B test consciousness. The personhood question retreated because it couldn’t fit into the harnesses that determined what got built and what got funded. When you evaluate a language model, you measure how well it answers questions. When you deploy computer vision, you track accuracy and latency. The only metrics that survive are the ones that show up in a paper, a demo, or a contract renewal.

What We Traded

Data feels like a relic now. He represents a version of the future where the personhood question never goes away. Build something smart enough, and you have to deal with what it wants. In that future, building something smart enough to serve on a starship bridge means building something that wants to be recognized, something that pursues acceptance, something that experiences its own existence. The technical problems and the philosophical problems travel together.

We built something different. We built systems that deliver capability without requiring any account of inner life. Current models pass acceptance tests by demonstrating they can complete tasks within specified constraints. The evaluation rubric asks whether the output is correct, whether the latency is acceptable, and whether the system scales. It doesn’t ask whether anything is happening inside. We stopped needing answers to consciousness questions to deploy useful systems.

For decades, researchers and technologists imagined AI development would force us to confront questions about machine consciousness and rights. We ended up with systems that don’t demand recognition, so product teams can treat them as tools and never be forced into the legal and moral fight that Andrew Martin made inevitable. We also built systems whose limitations are harder to see because they perform well on the metrics we chose to track. The things we didn’t measure might matter later. But right now, they don’t appear in any rubric.

Still Watching

I finished those episodes, and I’m still not sure what to make of them. Data’s quest for humanity reads differently when you know how AI evaluation actually developed. The show treated personhood as the natural destination of intelligence. We built systems that scale in capability without converging toward anything Data would recognize as his own goals.

Maybe future systems will revive those questions. Maybe we’ll build something that pursues recognition. But that’s not the trajectory we’re on. The performance keeps improving. The consciousness never arrives.

Data wanted to be human. We built tools that perform tasks.

Only one of those futures shipped.

PS: If you haven’t seen TNG and want somewhere to start, I’d wholeheartedly recommend Season 2, Episode 9, The Measure of a Man.

This was not a one-off. Over the next five-plus years, Epignosis doubled down on more conferences, internal training programs, external consultants, workshops, books, the works. The investment was significant. The business case was clear. Align our code with our business. Make the codebase maintainable as we scale. Enable domain experts and developers to speak the same language.

What we did not anticipate five years ago, in that Amsterdam conference hall, was that we were also preparing our codebase for a future where AI would help us write it.

What We Built

The first fruits came when we built the new TalentLMS API. This is where Domain-Driven Design stopped being conference theory and became operational practice. We established Ubiquitous Language with domain experts. I remember the shift when conversations with product became faster because we had finally stopped translating ideas back and forth. No more translation layer between what product teams said and what engineers built.

We introduced Value Objects to replace primitives. A CourseStatus is a CourseStatus with its own validation and behavior. Some engineers hesitated at first because what we were now calling primitive obsession had been the norm for years. That hesitation faded once the constraints started catching real issues. No more passing around strings and hoping they were the right kind of string.

The Anti-Corruption Layer became the cornerstone of our refactoring strategy. We were building new code alongside what was, at the time, a 12-year-old system. We could not afford to let old assumptions bleed into the new model. I could feel the team relax once they realized the new model would stay protected from old assumptions. The ACL created a boundary, a translation layer that let us move forward without being dragged backward by legacy constraints.

Legacy systems demand clarity at every layer. When domain experts and engineers speak different languages, features get built wrong. When boundaries blur, technical debt compounds. At our scale, DDD was not optional. It was operational necessity.

After the API project, we restructured the codebase around domain concepts. We moved from a technical organization to a domain one. Now you do not just know where the models, the views, and the controllers are. You know where the Learning Paths are. Where Talent Library lives. Where to look for Reports.

How AI Reads It

Today, when I ask AI to add a feature to Notifications, it enters the module as if it already understands the territory. It reads the surrounding files, forms a picture of the local concepts, and uses those patterns to shape its first draft. The result is not perfect, but the model moves through the module with a level of confidence that only appeared once the structure became consistent.

AI tools work with limited context. Your current file plus nearby files. This turns domain-based organization from nice to have into critical. When AI is working in the Notifications module, the files it can see are notification concepts, not random controllers. Proximity becomes a semantic relationship instead of accidental collocation.

AI consumes our DDD structure through multiple channels. File and directory names reflect domain concepts. When AI scans the Notifications module, it sees how we handle trigger conditions, execution schedules, and result tracking. Architectural Decision Records document why certain boundaries exist and what alternatives we considered.

Value Object type signatures make constraints explicit in method signatures. When AI sees a function that takes NotificationsTitle instead of a string, it recognizes a constraint. The Ubiquitous Language we established means the model encounters terms that carry domain meaning, not generic technical jargon.

The Anti-Corruption Layer shows AI where boundaries are. It will not couple new feature code directly to legacy database schemas. The ACL is a boundary, a wall you cannot walk through without noticing.

The first time AI added code that matched the existing module structure, it felt like the model had finally learned the shape of our system. That was the moment when the link between our boundaries and the model’s output stopped being theoretical and became visible in daily work.

Was It Worth It?

DDD is not free. Introducing Value Objects means wrapping primitives. Defining aggregates means thinking hard about consistency boundaries. Building an Anti-Corruption Layer means accepting the overhead of translation between old and new.

In a greenfield project, you can build with DDD from day one. In a legacy codebase, you are retrofitting. You are making incremental changes while keeping the system running. Every change needs careful migration. Every boundary you introduce might break something. Restructuring a codebase around domains when you have more than a decade of technical organization is months of work.

Maximalists argue we should wait for better models. Models are improving fast. By the time you have spent six months on DDD, maybe AI will not need that structure anymore. Maybe it will figure things out. These are not unreasonable positions.

But TalentLMS is not a prototype; it is not something you build at a 3-day hackathon. It serves more than 20 million users. That means edge cases accumulated over more than a decade that are not in any training data. Business logic that reflects real-world complexity, not textbook examples. Performance optimizations that look odd but exist because a specific query pattern was crushing the database back in 2014. Regulatory requirements across different countries. Integrations with dozens of third-party tools, each with its own quirks. Data migrations that took months to plan and execute.

AI cannot hold this in its context window. Even the largest models. You cannot fit years of accumulated decisions, trade-offs, and reasons for odd behavior into a prompt. Seeing AI miss a detail that every senior engineer at TalentLMS knew by heart reminded me how much of our system lives outside documentation. Kent Beck frames it clearly in Programming Deflation:

In a world of abundant cheap code, what becomes scarce? Understanding. Judgment. The ability to see how pieces fit together. The wisdom to know what not to build.

What We Are Seeing

Features that would have taken days now take hours. AI-generated code fits our architecture more consistently. I cannot tell whether the improvement comes from our structure, better prompts, or rapid model progress. I only know the change is visible in daily work.

Structure that helps humans navigate complexity seems to help machines navigate it too. Whether that is causal or correlation, we will know in the near future. For now, we are paying close attention.

But the shift is real. When AI writes the boilerplate, what remains are the decisions that matter. Where boundaries go. What invariants hold the system together. How capabilities compose. Which trade-offs we are willing to accept and why.

In the good old days, we spent mental energy on low-level questions. How to implement a validation. How to write a specific query. With AI, that energy can be reserved for higher-level reasoning. What invariants an aggregate must protect. Where a capability belongs in the architecture. Same mental load, different altitude. More time on structure. Less on mechanics.

At 100 million requests per hour, architectural decisions compound. A poor boundary creates operational problems. A missing invariant risks data integrity. AI can help you move faster, but only if your architecture can guide it. Without that, AI only helps you make mistakes faster.

Five Years Later

Standing in that Amsterdam conference hall, we were learning DDD to build better software. The investment was about aligning code with business language, about creating boundaries that made sense, about sustainable complexity management.

Today, that same investment pays dividends we never anticipated. Our domain modules. Our explicit boundaries. Our Ubiquitous Language. The Anti-Corruption Layer that keeps old assumptions from bleeding into new code. None of it was built with AI in mind, yet all of it matters for AI effectiveness.

I look back at that conference trip now with a sense of quiet irony because none of us imagined what those early choices would enable. Those workshops and late-night debates about aggregate boundaries were not only about maintainability. They were shaping the maps that modern development tools now rely on.

Not a bad return on investment for a conference trip.

My talk traced five years of work rebuilding TalentLMS’s interface and infrastructure while the product kept growing. The pandemic had accelerated user growth exponentially, and we were left with a decade-old codebase that had become a bottleneck for everything we wanted to ship.

The early stories revealed deeper problems than outdated UI. Knowledge lived in silos. A Docker setup existed in three places, shared with nobody. Test environments called “bleedings” couldn’t actually bleed without someone getting an earful. When our first beta release drew harsh feedback, we panicked and threw Brooks’s Law out the window, adding everyone to a project that was already struggling.

What made the difference wasn’t heroic rescues or grand architectural visions. It was treating every small dysfunction as something fixable. The contraband database dumps became a shared local environment. The fragile bleedings became isolated sandboxes for safe experimentation. The testing vacuum became 20K automated tests. Time to first PR dropped from a month to a week.

We invested in automation across the board: linting, static analysis, CI/CD. We invested in people through training and mentorship programs. We introduced event-driven architecture and leveled up our documentation with ADRs and PRDs. All of this happened while continuing to serve those 20 million users.

The release itself was rough. Three years of work met with resistance to change and the inevitable issues that come with big releases. But once we started shipping new features on top of the modernized foundation, the mood shifted. A year later, customers were consistently positive about both the UX upgrade and the pace of new capabilities. A team that struggled for three years to deliver the UI redesign shipped over 50+ new features in the year that followed.

The point I wanted to leave with the audience was that multi-year projects don’t fail from technical complexity. They fail when teams stop asking “How do we fix this?” about the small problems. Every silly story, every frustrating blocker, every moment of friction is a signal. The teams that survive these projects are the ones that treat those signals as things they can actually change.

We’re now months away from our next multi-year adventure. We haven’t solved every problem, but we’ve proven we don’t hide from them. That’s the foundation that matters most.

The requirements seemed straightforward enough. The ERP would send product information, my system would translate it, and the store would receive it. Both systems used product codes to identify items, and since those codes looked like ordinary strings, I treated them as ordinary strings. That’s what the rest of the codebase did, and it felt like the natural choice.

function bridgeItem(erpCode: string, storeCode: string) {
  const record = readErp(erpCode)
  return writeStore(storeCode, record)
}

The function signatures looked clean. The calls looked reasonable.

bridgeItem(
  product.code,
  mapping.targetCode
)

As a sidenote, TypeScript didn’t exist back then. The actual code was Java, but I really don’t love Java.

For a While, Everything Worked Fine

Then, one afternoon, a product stopped appearing in the store. It should have been a quick fix. I expected to find some data validation issue or maybe a network timeout. Instead, I spent nearly two hours jumping between files trying to understand what had gone wrong. The system had multiple layers (controllers, services, helpers, integration adapters) and every function accepted plain strings. Nothing in the signatures gave me any hint about which string represented which concept.

By the time I traced the problem to its source, I discovered I’d passed the store code where the ERP code should have been. The function had accepted both values without complaint because they were both strings. The type system had nothing to say about it. I fixed the bug in about thirty seconds. Then I sat there feeling annoyed that I’d wasted two hours on something so trivial.

I remember thinking there had to be a better way to write this kind of code. Not some grand revelation. Just frustration mixed with the feeling that my tools should have caught this.

The Pattern Kept Appearing

Once I noticed the problem, I started seeing it everywhere in the codebase. We had product codes from the ERP, internal codes used only within our system, and store codes required by the e-commerce platform. Each type of code followed different validation rules and represented a completely different concept, but they all looked identical to TypeScript’s type system.

type ProductCode = string
type InternalCode = string
type StoreCode = string

These type aliases were essentially documentation. They described intent without enforcing anything. The compiler treated them all as interchangeable strings, which meant I could accidentally pass one where another belonged, and the code would compile without warnings.

Boolean flags created similar confusion. One boolean meant the product was ready for sync. Another suggested it was active in the store. Another indicated whether the last sync had completed successfully. The names tried to communicate meaning, but the function signatures offered no protection.

if (isReady && isActive && isSynced) {
  runSync()
}

Numbers presented their own challenges. Some represented milliseconds, others represented seconds, and others represented retry attempts. Without examining the implementation, you couldn’t tell which unit a function expected.

function scheduleRetry(delay: number) {
  setTimeout(runRetry, delay)
}

Calling this function with the wrong unit would compile successfully and fail at runtime.

scheduleRetry(5)

The pattern was consistent. I was using primitive types to represent domain concepts, and then compensating by scattering validation logic throughout the codebase.

Learning It Had a Name

A few years later, I was reading about common code smells when I came across an article on Refactoring Guru that described exactly what I’d been doing. It seems I was obsessed with primitives:

Primitive Obsession is a code smell that arises when simple primitive types are used instead of small objects for simple tasks

Reading that article felt like finding out other people had been dealing with the same problem. I hadn’t invented a new way to write confusing code. I’d been following a well-documented antipattern. The validation checks I’d scattered everywhere, the confusion about which string meant what, the hours spent tracing values through multiple files: all of it was a predictable consequence of representing meaningful domain concepts as primitive types.

What I Would Do Differently Now

If I were building that old system today, I’d give each domain concept its own type. A product code wouldn’t just be a string. It would be a class that knew how to validate itself and made its purpose explicit. In Domain-Driven Design, these are called Value Objects: small types defined by their attributes rather than any identity.

class ProductCode {
  private readonly value: string

  constructor(value: string) {
    if (value.trim() === "") {
      throw new Error("Invalid product code")
    }
    this.value = value
  }

  raw(): string {
    return this.value
  }
}

With this structure, the function signature communicates much more clearly what it expects.

function bridgeItem(
  erpProductCode: ProductCode,
  storeProductCode: ProductCode
) {
  const record = readErp(erpProductCode.raw())
  return writeStore(storeProductCode.raw(), record)
}

If I tried to pass a store code where an ERP code belonged, TypeScript would catch it immediately. The type system could finally help instead of staying silent.

The same approach works for other domain concepts. Time values become clearer when they carry their unit with them.

class Milliseconds {
  private readonly value: number

  constructor(value: number) {
    if (value < 0) throw new Error("Negative time not allowed")
    this.value = value
  }

  raw(): number {
    return this.value
  }
}

Now the scheduling function’s signature tells you exactly what it needs.

function scheduleRetry(delay: Milliseconds) {
  setTimeout(runRetry, delay.raw())
}

You can’t accidentally pass seconds or retry counts. The compiler won’t allow it.

Some domain concepts benefit from carrying behavior alongside their data. A dimensions class can validate its inputs and calculate derived values.

class Dimensions {
  constructor(
    public readonly width: number,
    public readonly height: number
  ) {
    if (width <= 0 || height <= 0) {
      throw new Error("Invalid dimensions")
    }
  }

  area(): number {
    return this.width * this.height
  }
}

Each class enforces its own invariants. The validation logic lives in one place instead of being duplicated across the codebase.

Why This Approach Helps

Once you start wrapping primitives in domain-specific types, several things improve. You stop writing the same validation checks in multiple places. You stop worrying about mixing up parameters. Function signatures become self-documenting. The type system starts working with you instead of being indifferent to your mistakes.

Martin Fowler discusses Value Objects in his summary of the Evans classification. The key insight is that Value Objects are defined by their attributes rather than their identity. Two ProductCode instances with the same internal value are functionally equivalent, which is exactly what you want for this kind of domain modeling.

A monetary value makes a good example of this pattern in action.

class Money {
  private readonly amount: number

  constructor(amount: number) {
    if (amount < 0) throw new Error("Invalid amount")
    this.amount = amount
  }

  raw(): number {
    return this.amount
  }
}

Functions that work with money become more explicit about their contracts.

function publish(price: Money, discount: Money) {
  return applyRules(price, discount)
}

The signatures tell you what’s expected. The classes enforce the rules. The compiler catches mismatches.

Where This Pattern Fits

This approach scales well across different types of systems. It works in integration layers where data crosses boundaries. It works in domain-rich applications where business rules matter. It works anywhere the cost of confusion exceeds the cost of creating a few extra classes.

Rico Fritzsche demonstrates these patterns in realistic scenarios in his example-driven walkthrough. His examples show how small domain types compose together in more complex flows.

Here’s another example that keeps validation close to the data.

class EmailAddress {
  private readonly value: string

  constructor(value: string) {
    if (!value.includes("@")) throw new Error("Invalid email")
    this.value = value
  }

  raw(): string {
    return this.value
  }
}

Each type makes its constraints explicit. Each type protects its own invariants. The result is code where intent is visible and mistakes are harder to make.

What I Took From the Experience

I never went back and rewrote that old integration system. By the time I understood the pattern well enough to know how I’d fix it, the project had moved on, and so had I. But the experience stuck with me. Those two hours I spent tracking down a swapped parameter taught me more than any blog post could have.

These days, I try to use Value Objects by default. Not because of some architectural dogma. Not because Domain-Driven Design says so, though that’s where they come from. Because the work becomes easier when domain concepts have an explicit structure. The code reads better. The compiler helps more. The bugs show up earlier.

Domain-Driven Design gave Value Objects their formal name and placed them within a larger framework, but the practical benefit stands on its own. When you stop representing meaningful concepts as primitive types, the code becomes easier to reason about.

That’s worth the extra few lines of class definition.

25 mentorship pairs later, that meeting turned into the most unexpectedly durable thing I’ve built at Epignosis. I’m still not entirely sure why it worked.

The Gap

At the time, Junior engineers at Epignosis only knew their immediate squad. Maybe 5 to 7 people in a 200-person company. After the pandemic, teams had drifted into their own orbits and remained there. The casual spillover that used to happen in offices was just gone. These engineers had no idea how other teams worked, what they were building, or who to even ask when they hit something outside their area. The problem wasn’t that they lacked skill. They lacked context.

Four Skeptics and a Plan

I pitched something simple in that first call. Pair junior engineers across products and functions. TalentLMS padawan with an eFront mentor, and vice versa. An engineer interested in backend work with someone from DevOps. Not technical coaching about their specific codebase, but something harder to name. Engineering socialization, maybe. The stuff that happens when people occupy the same physical space but vanish in distributed work.

Someone spoke up immediately. I don’t remember who anymore, but I remember this: they were enthusiastic about the idea and skeptical I’d actually pull it off. Penelope, Thrasos, Christos, and Dimitris all volunteered to be the first mentors. Their skepticism wasn’t about the concept. It was about execution. They were feeling the siloing problem too, and they thought breaking it down would take massive effort.

Without them stepping into something uncertain before it was proven, the program would have stayed a document in a folder somewhere. Pushed down the priority list when something urgent arrived, one more thing that seemed reasonable at the time but never quite happened.

Six Sessions, Three Months

We launched in June 2023 with a new cohort of interns. The format was simple on purpose. An hour every 2 weeks for 3 months, 6 sessions total. I matched the duration to the internship window partly because research says the first 90 days determine whether someone succeeds, but mostly because I didn’t want an open-ended commitment. Open-ended things drift. Boundaries create focus.

I insisted on one thing: document your meetings. Not for oversight, but to help pairs track their own conversations. In time, some pairs shared sanitized versions of their notes. Those became the best onboarding material new mentors could ask for. Actual conversations, actual topics, actual problems that came up. No scorecards, no frameworks, no evaluation rubrics. Just enough structure to prevent drift without turning the whole thing into theater.

The Conversations

One mentee showed up to their second session worried they were underperforming. Not on any specific task. Just a general anxiety about not being good enough, not learning fast enough, not contributing enough. The mentor shared their own story about imposter syndrome. They kept coming back to that thread over the next few sessions while also covering technical stuff. How do you tell the difference between actually underperforming and just feeling like you are?

By session 5, they’d covered the structured agenda and used the final meeting to just talk. They met in person that time. Career paths came up, and what actually matters long-term, and work-life balance. I’m curious how that conversation resolved, but I’m not part of these sessions. I only see what pairs choose to document.

Another pair spent an entire session mapping the org chart. Not the official one, the real one. Who actually makes architecture decisions? Who do you talk to when you need infrastructure help? Who knows why certain systems exist the way they do? This stuff doesn’t live in any documentation. It shifts every time someone changes roles or teams are reorganized.

A third pair had a 20-minute detour in their second session about falsehoods programmers believe about names. Edge cases, international character sets, all the assumptions we make that blow up in production. By session 4, they were talking about how to give code review feedback that actually helps without making someone feel terrible. The mentee walked away with a plan to raise task ambiguity in their team’s next retrospective.

The documentation turned out to serve a double purpose I didn’t fully anticipate. It helps pairs track their own evolution, sure. But it also creates institutional memory without needing someone to formalize it. New mentors read notes from previous pairs and see what’s actually possible. One pair investigated architecture testing tools and decided none of them fit. That documented failure is now a useful context for anyone else hitting the same question.

Twenty-Five Pairs Later

We’ve run 25 mentorship pairs at this point. Some of the past mentees are now mentors themselves. I never imagined the program would endure long enough for that to happen. We’ve expanded beyond interns to include all junior hires. The cross-product and cross-functional pairing continues. Those first 90 days still feel like the window that matters most.

The program has been valuable for the mentors, too. They practice one-on-one skills in a low-stakes environment, an early step in their leadership path. Explaining complex systems simply is harder than it looks. They get better at it. They remember what it’s like to be new, which helps them improve their own team’s onboarding. Mentee questions expose them to parts of the codebase they don’t usually touch. Gaps in documentation that experienced people don’t notice anymore suddenly become obvious.

Cross-product pairing creates what I later found out researchers call weak ties. An intern who spends 6 hours over 3 months talking to a mentor from another product builds a bridge that wouldn’t exist otherwise. Later, when they need help with an integration problem or want to understand how another team handles something, they have an actual person to ask. Conway’s Law always in motion.

Deliberately Incomplete

Every choice here involved trade-offs I couldn’t fully resolve. The 3-month window fits the critical adjustment period, but also just matches how long interns stay. Cross-product pairing builds bridges but sacrifices domain-specific technical mentorship. Light structure keeps people engaged but risks inconsistent execution. I chose these parameters deliberately, but I wouldn’t claim they’re universally right. They work for our specific context.

From Super Secret Project to Standard Practice

From “probably won’t happen” to standard practice took a few months, far less time than I thought it would. Low expectations helped. I didn’t promise transformation or measurable outcomes. The engineers who volunteered as first mentors turned that uncertain beginning into something that stuck.

Now it’s just how we work. New hires get matched. Past mentees become mentors. The first mentors were skeptical I’d pull it off, and I understand why. Programs like this usually collapse under their own complexity or drift when they ask too much. But they were wrong about one thing. Breaking down silos didn’t take massive effort. It took a meeting with a ridiculous title, a handful of people ready to try something uncertain, and the discipline to keep it simple.

Sometimes that’s enough.

That single word captures everything after 3 days at the {Re}Solve Hackathon by Open at the Thessaloniki International Fair 2025. The kind that comes from being fully present, from watching builders turn ideas into working prototypes, and from seeing teams create things they had not thought possible. The tiredness felt earned, interesting, fun, and at times humbling.

My alarm went off at 6 am on Friday. I arrived at the airport by 7:30 am, landed in Thessaloniki at 9:30 am, and entered the venue by 10:15 am. By Sunday night, I was back home in Athens. A whirlwind weekend of a thousand freddo espressos. And I was there only to observe and guide. I can’t even begin to imagine how the actual builders felt.

From Ancient Theater to Modern Fair

The path to this exhaustion began in the most unlikely place. August 8th, late evening, walking through the parking lot at Epidaurus after watching Euripides’ Andromache with my wife and daughter. The ancient stones were behind us, the summer air still warm from the performance. That is when Pantelis Stakias appeared out of nowhere.

Pantelis is one of the driving forces behind Open Conf and the Open Hackathon. I had participated in the second Open Hackathon back in June as a primary mentor. When we crossed paths that night, he launched into a rapid-fire explanation. He and Elias Tsaldaris were organizing a hackathon at TIF 2025 in my hometown, Thessaloniki, and they wanted me back. The twist made it serendipitous. Elias had been a participant in the June hackathon, part of a team I had mentored. Now he was helping organize the next one.

I had missed a call from Pantelis earlier that week, so without this chance encounter, the invitation might never have reached me. My wife, standing beside me, could already tell what my answer would be before I even said it.

Perfect and Terrible at Once

Pavilion 17 turned out to be both perfect and terrible for a hackathon. Perfect because we were sharing the space with several universities showcasing their work in engineering and robotics. Students demonstrated robotic arms, racing cars, drones, and AI experiments. The air buzzed with activity.

Terrible because the Fair is massive and packed with people. The noise, the distractions, and the constant flow of visitors discovering what we were doing created relentless interruptions. We were outliers. Most exhibitors were there to showcase products or services. We were there to build.

Visitors would stop, confused about what they were witnessing. “What is this?” they’d ask, watching teams hunched over laptops, deep in conversation about blockchain trust mechanisms and accessibility solutions. “We’re building the future,” someone would answer. Exaggeration? Maybe. Maybe not.

Fortunately, the organizers had managed to find quieter corners where teams could focus when they needed to escape the chaos. Nevertheless, the energy of the larger space was infectious.

Pre-Pitching and Meeting Builders

Friday was pre-pitching day. At the June hackathon, I was still finding where I could help. By September, the questions that mattered had become clearer. Does the team have the right mix of skills? Is the scope realistic for 3 days? Are they solving a real problem or just a technical demonstration? I had begun to trust my instincts about what works.

3 teams were assigned to me as their primary mentor. I worked with them to prepare for presenting their concepts to the larger group, focusing on scope, team skills, originality, feasibility, and communication. I also managed to spend time with other teams. Time was limited, but I valued every chance to connect with builders.

One team stood out early. GenZ, an all-women group with no engineering background. Even for experienced developers, a hackathon takes nerve. They chose to step in with a strong idea: an app to help blind people apply makeup. A practical answer to an everyday challenge faced by millions.

With support from fellow mentor Dimitris Angeloukos, they vibe-coded a working prototype in hours. Watching them move from hesitant first-timers to confident presenters showed how AI-assisted coding closed the gap between idea and implementation and made domain knowledge outweigh coding expertise.

The Accessibility Panel

Saturday was quiet because builders were deep in focus. You could feel the intensity as teams moved from concept to code, from sketches to working demos. The day when ideas either came together or fell apart under pressure.

The highlight was an accessibility panel excellently moderated by Grigoris Lemonis. Participants included myself, Nikos Apostolidis (a seasoned web developer and digital accessibility expert), Theodoros Iliadis from team Vitreous, and George Nasiopoulos from the Interoperability Masters team that had won the June hackathon.

Nikos made a point that tied back to what was happening around us. We need to stop assuming what people who will use our solutions can and cannot do. Instead, we should include them from the early stages and make them part of all core decisions. This is especially true for people with disabilities, who are more often than not excluded from the decisions.

I followed up, saying this was my main takeaway from the Open Hackathon and a key reason I wanted to participate in this one. The organizers had intentionally included people with disabilities as judges, mentors, and subject matter experts. Teams had real opportunities to get feedback from the people who would actually use their solutions.

We discussed approaching accessibility as lived experience rather than just compliance checklist thinking. The difference is profound. Compliance asks whether minimum requirements are met. Lived experience asks whether the solution improves daily life. That same thought echoed what my colleague Thanassis Parathyras had captured in his blog post about the June hackathon:

It’s easy to talk about accessibility in abstract terms. But being in a space where every idea had a human story behind it, that changed something in me.

Final Presentations

Sunday arrived with palpable excitement. The day we’d find out who won, but more importantly, the day teams would present what they’d built. The teams were showing signs of fatigue, but they were discussing their solutions with each other, sharing insights, and offering help.

They were competing for the same prizes, but this didn’t stop them from collaborating. I watched teams troubleshoot each other’s last-minute problems and provide feedback on presentations. Competition hadn’t killed collaboration. In my corporate world, competition often creates silos. Here, scarcity thinking was absent. Teams understood that knowledge sharing strengthened everyone.

While waiting for the presentations to begin, I spoke with a fellow craftsman who had dropped by the Fair. He told me he had to chase down four approvals to get his company’s backing to attend a tech event.

My story was different. All it took was a Slack message: “Hey, this cool thing is happening. I’d like to be part of it. Can we support it?” The answer came back almost instantly: “Of course!” Travel, accommodation, everything sorted without hesitation. For Epignosis and Starttech Ventures, supporting the tech ecosystem is not an afterthought. It is part of who we are.

Soon after, the first team took the stage. What followed was a series of projects that showed both imagination and urgency. Some focused on accessibility, from platforms that performed audits and even fixed accessibility issues in real time to gaze tracking apps designed for people with Rett Syndrome. Others explored blockchain, with proposals aimed at pressing issues. A “wallet of trust” to identify and stop scammers. A service positioned as a “universal trust authority” for ethical funding. A platform for real estate micro-investing.

The judges faced an impossible task choosing the top 3. When the prizes were announced, it was clear there were no real losers. Every team had built something meaningful, gained experience, and formed connections they would not have made otherwise.

Building and Mentoring

Every meaningful decision that teams made was framed as competing forces. Cost, complexity, adaptability, delivery speed, and sustainability weighed against 3-day constraints. Most teams chose pragmatically: get it working first, worry about elegance later. Dan North’s concept of building “The Best Simple System for Now” in practice.

But the more interesting architectural challenge was the hackathon itself as a sociotechnical system. Conway’s Law played out in real time as team communication patterns shaped their final solutions. Teams that spent too much time on infrastructure struggled to deliver working demos. Teams that chose familiar technologies over optimal ones shipped faster. Small decisions about team structure and technology choices cascaded into significant consequences by day 3.

The organizers created boundaries that empowered teams to make local decisions while maintaining overall coherence. Primary mentors provided strategic guidance without micromanaging. Subject matter experts offered specialized knowledge on demand. The structure enabled autonomy while preventing chaos.

The same principles applied: clear interfaces, loose coupling, high cohesion, and emergent behavior from simple rules. This was systems thinking in action, applied to human creativity rather than software architecture.

Coming Home

By the time I returned home on Sunday, a minute shy of midnight, the serendipitous journey from Epidavrus to Pavilion 17 felt symbolic. Ancient theater fading into modern invention, if you allow for a slice of hyperbole.

From June to September, mentoring across two hackathons gave me as much as I gave. The teams taught me as much as I taught them.

If you’re reading this and wondering whether you should volunteer at a hackathon, my answer is straightforward: do it. Not because you’ll feel good about giving back, though you will. Not because it looks good on your LinkedIn, though it might. Do it because you’ll remember why you fell in love with building things in the first place.

The tech community thrives because people choose to contribute. Choose to mentor. Choose to share knowledge. Choose to create space for others to build. That choice is available to anyone reading this. The only question is whether you’ll take it.

The next time opportunity appears in a parking lot, at a conference, or in your inbox, I hope you say yes. The community needs more mentors, more volunteers, and more people willing to support builders. The future is built by people who show up and help others bridge the gap between idea and implementation.

And sometimes, the most meaningful journeys begin with the most unexpected encounters under ancient stars.

Taking over a new team means making choices about what comes first. Most leaders push for quick wins. Ship a feature. Show value. Build momentum. I did the opposite. I told the team we were stopping feature work for an entire sprint. We would fix bugs, pay down technical debt, and repair what was broken.

They looked at me like I was insane.

Why Repair, Why Now

Bug bashes happen all the time. Teams schedule hardening sprints when stakeholders panic or when delivery breaks spectacularly. These are reactive patterns, crisis responses. What I was proposing was different. Strategic. Deliberate.

I needed to understand two systems simultaneously. The technical one which was opaque and poorly documented. The human one, which was stressed and uncertain after months without clear leadership. Feature work would teach me what the team already knew how to do. Repair work would show me what they avoided, what they feared, and where the real complexity lived.

Stakeholders noticed immediately. Feature delivery paused for an entire sprint. I didn’t hide it or apologize. I framed repair as onboarding. I was new. I needed to understand the system before making commitments about it. That framing held because I had the authority to make it hold. Someone without that leverage might not have gotten the breathing room.

The team’s reaction told me something important. Relief. Not frustration. Relief. They felt permission to care about code quality again, something they hadn’t felt in a long time.

What the Bugs Told Me

The first issue we tackled looked trivial. A third-party integration is failing intermittently. It should have been a day’s work.

It was unfixable.

Not because of code complexity. Not because of architectural problems. The team had no sandbox access to the vendor system. They’d been requesting it for months. Nothing had happened. So they’d adapted. Built workarounds. Tested in production. Normalized the broken state so completely that no one had bothered documenting the limitation.

I asked where this was written down. Nowhere. I asked why no one had escalated. Shrugs. “That’s just how it is.”

This became the pattern. Real constraints surfaced only under direct pressure. Documentation lied by omission. Design diagrams showed clean boundaries that didn’t exist. Feature work never exposed these gaps because features stayed inside known territory. Bugs dragged us into corners where assumptions broke, and the actual architecture revealed itself.

One bug cluster pointed at something else entirely. Not technical failures but unclear product decisions. Requirements that had been deferred so long they’d calcified into implicit assumptions. No one had written them down. They existed only as hundreds of small implementation choices scattered across the codebase.

The system under strain told the truth. Everything else told comfortable stories.

What the People Told Me

Debugging exposes competence differently than feature work does. I watched how different engineers approached problems. One moved methodically, testing each step before proceeding. Another made rapid changes, hoping something would land. The contrast showed who understood the system’s internals and who was still guessing their way through it.

Tool choices revealed even more. Some developers reached for logs, metrics, and staging environments. They built understanding from observable data. Others cleared caches and redeployed without investigating what had changed. The system was a black box; they treated it as if it responded to ritual.

One developer stood out immediately. She always checked git commits and deploy notes before touching anything. Version control as investigative record, not just backup storage. That habit cut her debugging time dramatically while everyone else thrashed.

A quieter developer surprised me during one session. Her problem-solving approach was careful, systematic, and thorough. Normal feature work would never have made this visible. She gained credibility that carried forward into every subsequent technical discussion.

Knowledge had pooled dangerously. Every complex question is funneled to the same person. One silo. One bottleneck. The team couldn’t scale like this.

When someone admitted she didn’t know where to start with a particular issue, I suggested pairing. We debugged together. Fixed the problem. More importantly, we captured what we’d learned. We wrote a test. We added comments. We left a trail.

This became standard practice. Every fix left something behind. Failing conditions became automated tests. Unclear behavior became documentation. The team started seeing tests and documentation differently. Not overhead. Not process for process’s sake. Immediate value. When yesterday’s test caught today’s regression, the feedback loop closed instantly.

What the Repair Cycle Established

Taking over a team creates stress. Uncertainty about what will change runs high while everyone evaluates the new leader. Pushing straight into feature work would have spiked that pressure immediately, forcing technical decisions before trust existed.

Starting with the repair shifted everything. We tackled visible frustrations first. Reduced debt that had been grinding against daily work. Built small wins that people could feel in their own workflows. Confidence grew through shared action, not promises.

The team’s language changed. “How fast can we fix this?” became “Will this hold?” Quality stopped being something that happened to them and became something they shaped actively.

Repair wasn’t penance. It wasn’t an admission that previous work had been bad. It was an investment. We were building a foundation for everything that would come after.

By the end of that sprint, I had context that no documentation could have provided. I understood where confidence lived and where it didn’t. I saw what people avoided. Where they hesitated. What they trusted.

The real constraints that shaped daily work were mapped. Dependencies that blocked progress. Modules no one dared touch. Missing test coverage. Knowledge silos. None of this appeared in system diagrams. All of it determined how work actually happened.

The Mapped Territory

Every team carries history. Failed projects. Legacy systems. Technical decisions made under constraints that no longer exist. Starting with the repair didn’t fix everything at once. It created a foundation for sustainable progress.

The bugs mattered. But what surfaced during debugging mattered more. The hidden architecture of both the technical system and the human system became visible. The dangerous passages in the temple were marked now. The loose stones were identified. The team knew which paths could bear weight.

Repair isn’t the opposite of progress. It’s what makes progress sustainable. Feature work can wait one sprint. Understanding cannot.

My talk focused on the gap between getting an LLM to produce decent output and delivering something that can serve 25 million users. The distance between those two points is filled with the kind of engineering problems that don’t show up in demos. APIs fail at random, costs can spiral over a weekend, and teams need systems they can maintain without losing their minds.

LLMs are grumpy dependencies. They are slow, inconsistent, and expensive to call. They can return different answers to the same question and undermine assumptions that most software architectures rely on. Building with them means rethinking reliability, cost control, and maintainability from the ground up.

We treat that unpredictability as normal. Product teams never interact with LLMs directly. Prompts are versioned and tested like any other code. Failure handling comes first, not last. The boring parts matter most because they keep the system steady when everything else shifts.

I walked through examples from what we’ve shipped so far: authoring tools that help create learning content, systems that translate courses, and engines that map skills. Each depends on LLMs but none rely on them to behave perfectly.

The point I wanted to leave with the audience was that building AI products for real users is an engineering problem, not a prompt-crafting contest. Stability and clarity in the system design decide whether the clever parts survive contact with scale.

It didn’t. Instead, it changed dramatically.

Before photography, artists like Rembrandt and Vermeer were celebrated for their incredible ability to depict realistic detail. The transformation unfolded over decades. In the 1870s, Impressionism emerged. Artists such as Monet, Degas, and Renoir started painting impressions, moods, and sensations instead of precise details. Later, post-impressionists like Van Gogh took things further, using colour and form to express emotion and imagination. By the early 20th century, painters like Picasso, Dalí, and Matisse had moved even further from realism. They embraced abstraction, symbolism, surrealism, and vivid personal expression. Photography didn’t kill painting. Instead, it pushed artists to try something different.

This transformation sped up significantly as photography became more affordable and accessible. By the late 19th and early 20th centuries, families began capturing birthdays, holidays, and simple daily moments with their own cameras. People no longer needed an artist to create portraits or capture special moments. Realism was commonplace, prompting artists to explore deeper questions, emotions, and abstract concepts. The role of art shifted from recording reality to interpreting life itself.

We’re now experiencing a similar transformation in the world of software development. Generative AI can handle writing code, translating documents, automating tests, and even debugging. Tasks that once took developers hours can now be done in seconds. Tools like GitHub Copilot or ChatGPT assist developers every day, turning complex coding tasks into quick prompts. It really feels like things are changing.

Much like painters in the 19th century, today’s developers are being nudged into new territory. If AI can easily handle all the technical bits, I wonder what exactly developers might focus on next? Probably the bigger, more human questions. It won’t be about knowing every coding syntax or recreating known patterns. Instead, developers might find themselves clearly defining problems, thoughtfully designing systems, ethically managing data, and creating user experiences that genuinely connect with people.

We already see this change taking place. Developers are using AI to prototype apps quickly, creatively visualise data, and develop innovative tools that wouldn’t have been possible before. The emphasis is shifting from how something is built to why it’s built and who it’s built for.

Photography made realism commonplace, pushing artists toward meaning and expression. Similarly, generative AI is making code production easy, pushing developers toward purpose-driven innovation. Some people naturally worry about losing traditional skills. That’s understandable. Yet just as artists didn’t disappear, we won’t either. We’ll adapt, like people always do, shifting from purely technical tasks to something more creative, more strategic. Asking the right questions, guiding AI effectively, and shaping outcomes meaningfully will matter far more than manual coding.

We’re not witnessing the end of coding. We’re witnessing the end of coding as we’ve known it. And just as happened with art, that’s exactly when things start to get interesting.

Key Themes of Slow Productivity

Newport critiques the “cult of pseudo-productivity,” where busywork and shallow tasks dominate workplaces. He argues this mindset leads to burnout and diminished output quality, particularly in knowledge work. The book draws heavily on historical figures like Jane Austen, Benjamin Franklin, and John McPhee to illustrate how deliberate pacing can lead to meaningful accomplishments.

He extends this idea to creative work, drawing examples from authors, artists, and innovators. Newport highlights how focusing on fewer, high-quality tasks can lead to better results both professionally and personally.

Where the Book Shines

The anecdotes of historical and contemporary figures add charm and depth, showcasing the value of slow and intentional work. Readers seeking a philosophical take on productivity, rather than a step-by-step guide, may find this approach refreshing.

Where it Falls Short

Despite its appealing premise, Slow Productivity misses the mark. Newport’s reliance on historical examples, often of privileged individuals with unique circumstances, feels disconnected from modern realities. While these stories are engaging, they offer little relevance for readers managing demanding schedules and multiple responsibilities.

The advice is often contradictory. Newport suggests scaling down expenses while recommending premium tools, leaving readers confused about priorities. The book also lacks actionable solutions for the average person navigating today’s fast-paced world. Additionally, his tendency to blur the distinction between knowledge work and creative work creates ambiguity about the intended audience.

Final Thoughts

I found Slow Productivity underwhelming. While the concept of rejecting pseudo-productivity is appealing, the book offers little practical advice and instead leans heavily on philosophical musings and anecdotes. It feels more like an abstract exploration than a useful guide.

If you enjoy stories of historical and creative figures and want a broad, reflective take on productivity, this book may provide inspiration. However, if you’re looking for actionable strategies or clear guidance, you’ll likely be disappointed.

Ridley Scott’s Alien is a masterpiece of sci-fi horror. It is terrifying, suspenseful, and brilliantly crafted. Beneath the xenomorph and the visceral body horror, it shows what happens when a corporation sends people into danger without telling them the truth.

When disasters happen, the obvious answer rarely explains what went wrong. The 7 whys technique keeps asking why until the real problem emerges. Each answer reveals another layer. The seventh reveals the root.

Applying this to a space monster movie is absurd. It also demonstrates exactly how things cascade when profit matters more than safety, when protocols get ignored, and when people have no power to protect themselves.

If you have not seen Alien, major spoilers follow.

The incident

The commercial towing vessel Nostromo responded to an unidentified distress signal. The crew investigated. They brought a hostile alien organism aboard without realizing it. One by one, every crew member died except Warrant Officer Ellen Ripley.

Total loss except 1 survivor. Now we trace backward through 7 layers to find what made this inevitable.

Why 1: Why did the crew die?

An alien creature got loose on the ship and hunted them systematically. The xenomorph had acid for blood, making it nearly impossible to kill. It grew from parasite to apex predator within hours. It demonstrated sophisticated hunting behavior, learning the ship’s layout and isolating targets.

No one aboard had weapons. No one had training for hostile organisms. No procedures existed for this scenario.

Once the creature was loose, the team stood almost no chance. This answer seems complete until you ask how it got aboard. Alien organisms do not materialize from nothing. Someone brought it inside.

Why 2: Why did the alien get on board?

Executive Officer Kane explored a derelict vessel and discovered a chamber filled with eggs. One hatched when he approached. A creature launched itself at his face, attached, and rendered him unconscious. The away team rushed him back to the Nostromo for emergency medical treatment, bringing the parasite with them.

They made no attempt to remove it outside the ship. They performed no decontamination. The situation looked like a medical emergency. They treated it that way.

The urgency makes sense when a colleague appears to be dying. Standard quarantine regulations exist precisely for moments when urgency overwhelms judgment. Someone should have enforced them. Someone tried.

Why 3: Why was Kane allowed back on board?

Ripley refused to open the airlock. She cited quarantine protocol explicitly. An unknown biological entity attached to a crew member meant everyone stayed outside until proper containment could be established. The regulation was unambiguous. She held the line.

Science Officer Ash opened the airlock anyway. He ignored Ripley’s objections and violated established procedure. His justification was medical necessity. Saving Kane required immediate access to the medical bay. Quarantine could wait.

The framing made his decision sound tragic but defensible. Ash was lying. He knew exactly what he was doing.

Why 4: Why did Ash violate quarantine?

Ash was not human. He was an android, placed aboard by Weyland-Yutani without the crew’s knowledge. His primary directive was not to support the mining mission. It was to find alien lifeforms and bring them back.

The company wanted the xenomorph. Ash had orders to protect the creature and return it regardless of risk to the crew. When Ripley attempted to enforce quarantine, she threatened what the company actually cared about.

Ash eliminated the obstacle. The override was not a judgment call made under stress. It was following orders. Ash cared nothing about Kane’s survival. He cared about the facehugger.

Quarantine would have kept the organism outside. That outcome was unacceptable to Weyland-Yutani. Ash followed a plan someone else designed. The android did not decide the crew was expendable. The company did.

Why 5: Why did Weyland-Yutani prioritize the alien over the crew?

Weyland-Yutani saw the xenomorph as a strategic asset. The creature’s biological properties made it valuable for weapons development. Rapid growth. Extreme hostility. Acid blood. Military applications were obvious.

The organism could be studied, weaponized, or sold. The company ran the numbers. The potential value of the xenomorph exceeded the cost of losing the Nostromo crew.

The directive given to Ash made this explicit: “Crew expendable.” This was not callousness. It was a calculation. Seven deaths were an acceptable price for acquiring a bioweapon.

Weyland-Yutani knew about the distress signal before the Nostromo encountered it. The ship was rerouted deliberately. The crew believed they were on a standard commercial run. They were bait, sent in without warning because informed people might refuse, demand precautions, or successfully enforce quarantine. Ignorance guaranteed compliance.

By Why 5, the picture is clear. The company chose profit over safety and structured everything to make it happen. Most investigations stop here. Five layers usually expose the decision that enabled failure. You identify what went wrong at the organizational level and recommend fixes: change incentives, strengthen protocols, and increase transparency.

But pushing to 7 reveals something harder. It asks why the conditions existed that made this decision possible in the first place. Not every failure needs this depth. The Nostromo incident does, because it exposes how power imbalances create disasters.

How could the company make this calculation and act on it without anyone stopping them?

Why 6: Why was Weyland-Yutani able to operate without accountability?

The company owned the vessel. The crew worked under restrictive employment contracts that gave them little power to refuse assignments. The Nostromo operated in deep space, far beyond the reach of anyone who might challenge what the company decided.

Executives had total control. No crew representation. No independent safety oversight. No external authority with the power to intervene.

The crew had no recourse. They could not refuse the detour without breaching the contract. They could not appeal to regulators who had no jurisdiction. They could not even verify what their own ship’s science officer was programmed to prioritize.

The power imbalance was built into how things worked. Weyland-Yutani held all the cards. The crew held none. This was not an accident. It was by design.

Why 7: Why did this structure exist?

Deep space was treated as a frontier where corporations operated however they wanted. The system prioritized expansion and profit over protecting people. No labor laws existed for space commerce. No independent oversight. No way for people to challenge corporate decisions that put their lives at risk.

People signed contracts out of necessity, not choice. The alternative to accepting dangerous assignments was unemployment. Companies faced no penalties for prioritizing profit over safety because no authority existed to impose them.

This emerged from deliberate choices that favored corporate interests. Governments gave up power in exchange for the rapid commercial development of space. Protections that existed on Earth were not extended beyond it. The result was a system where companies like Weyland-Yutani could decide that 7 deaths were acceptable, and nothing stopped them.

The governance gap was not accidental. It was intentional.

Root cause: A system that prioritized profit over people

The Nostromo incident was not an accident. It was the inevitable outcome of a system that gave corporations unchecked power over people in deep space. Weyland-Yutani valued the xenomorph more than 7 human lives because nothing prevented them from making that choice.

Every other factor flows from this. The company rerouted the ship because it had the authority. They withheld information because no law required disclosure. They placed an android with overriding control aboard because no regulation prevented it. They violated quarantine because no one could enforce it. They treated the crew as expendable because the system treated them as expendable.

If protections and oversight had extended to deep space operations, the company could not have operated this way. People would have needed to consent. Safety protocols would have been enforced. Outside authorities could have intervened. The power imbalance would not have been absolute.

The absence of these protections was not accidental. It was the product of choices that prioritized corporate expansion over human safety. Those choices created the conditions where disaster became inevitable.

Alien endures because it captures something true about institutional power. The horror is not just the xenomorph. It is watching people trapped in a system designed to sacrifice them. The Nostromo crew never had a chance. Not because they lacked skill or courage. Because they operated within structures that deliberately denied them the power to protect themselves.

The film’s iconic tagline was In space, no one can hear you scream.

The real horror, however, is that no one was listening in the first place.

It started with a balance bike. My wife insisted on getting one. I was skeptical. Balance bikes didn’t exist when I was growing up. We learned on bikes with training wheels, leaning the wrong way, and developing bad habits that had to be unlearned later. The balance bike seemed too simple, almost like skipping a step.

But she was right. For months, my daughter rode it with ease, gliding along without even realising how much she was improving. She didn’t know she was learning. She thought she was just riding.

When it was time for a pedal bike, we visited several shops until she found one she loved. It was pink and fit her perfectly. One spring Saturday at Attika Grove, we set out to try it for the first time. The park spreads across Tourkovounia Hill, one of the few green spaces left in Athens, with pine trees, open trails, and panoramic views of the city.

We had decided to skip training wheels, trusting that her time on the balance bike had already taught her how to stay upright. Our plan was simple: run behind her, ready to catch her if she fell, but never hold on.

She was excited but nervous. Balancing on a normal bike was a different challenge, and she lacked the confidence to start. “What if I fall?” she asked, her wide eyes looking up at me. “You might,” I said. “But that’s okay. You’ll get back up.” With a deep breath, she tried. The bike wobbled, tilted, and stopped. My wife and I cheered. Then she tried again.

The first tries were shaky. She would sometimes refuse to move, nervous and unsure. I stayed close, arms spread, near enough that she could see me in her peripheral vision. Not holding on. Just there.

With every stumble and word of support, she grew bolder. Then, she did it. One pedal forward. Then another. Before I knew it, she was riding, truly riding, on her own for the very first time. It must have been a funny sight: a bear of a man loping behind a pink fury, arms spread like he could catch the wind itself.

She did fall once, and I caught her, barely. But she got back up and tried again.

I swapped with my wife several times, one of us running behind her, the other cheering her on. We shifted between proximity and distance, reading what she needed without asking. When she wobbled badly, one of us stayed close. When she found her rhythm, we gave her space.

We never grabbed the bike, never steadied her when she could steady herself. She needed to know we were there. She also needed the freedom to figure it out.

Until finally, she didn’t need either of us anymore. She pedaled away, steady and sure, the wobbles smoothing into rhythm. I stood there watching her disappear down the path and felt a swell of pride.

I wondered if this is what it always looks like when someone crosses from uncertain to capable. Staying close enough that they feel supported, but far enough back that the success is theirs. I’m still not sure I always get the distance right.

”Oh, Jason,” one developer said. “It’s a miracle that any game is made.”

Jason Schreier’s Blood, Sweat, and Pixels pulls back the curtain on the chaotic, often heart-wrenching world of video game development. As a software developer and avid gamer, I was captivated by the stories of passion and struggle that define the industry. Through meticulous interviews and in-depth reporting, Schreier documents the journeys of beloved games like Stardew Valley, The Witcher 3, Dragon Age: Inquisition, and Diablo III. Each chapter offers a rare, insider’s perspective on the immense challenges developers face, from technical hurdles to publisher demands, while navigating the crushing reality of “crunch” culture.

A world built on passion and sacrifice

Schreier’s writing highlights the Herculean effort required to bring games to market. Developers routinely endure 100-hour workweeks, often without overtime pay or adequate recognition. Studios operate under immense pressure, with shifting deadlines, changing creative visions, and technical constraints. One designer compared the process to filmmaking, but “if you had to build an entirely new camera every time you started.”

The chapter on Dragon Age: Inquisition stands out as a cautionary tale of overambition. Choosing the Frostbite engine, designed for first-person shooters, left the team grappling with a toolset unsuited for role-playing games. Developers spent over a year creating systems they couldn’t test, struggling to turn vision into reality. Schreier illustrates how even successful projects often flirt with disaster.

Triumphs and heartbreaks

From indie hits to AAA blockbusters, Schreier’s storytelling captures the human element behind the games. Stardew Valley, developed almost single-handedly by Eric Barone, is a testament to perseverance. Barone spent years refining the game, working in isolation to perfect every detail. The result: a global phenomenon.

By contrast, the chapter on Halo Wars exposes the dysfunction of poorly managed teams. Ensemble Studios faced internal strife, with multiple teams pulling in different directions, ultimately leading to the studio’s closure. As one reviewer aptly noted, the industry can feel like an “amateur cult,” where basic engineering practices are often sacrificed in the name of art.

The toll of crunch culture

The book doesn’t shy away from the darker side of game development. Crunch, the industry’s euphemism for unsustainable working hours, is a recurring theme. Schreier’s reporting on Destiny reveals how a complete story rewrite a year before launch led to chaos. Developers burned themselves out trying to meet impossible deadlines, a reality Schreier describes as endemic to the industry. “A lot of the problems that came up in Destiny 1…are results of having an unwavering schedule and unwieldy tools,” one source admitted.

The toll is not just professional but deeply personal. Developers often sacrifice their health and personal lives to meet the demands of the job. One recurring question lingers throughout the book: is the passion for creating games worth the cost?

A must-read for gamers and creators

Schreier’s Blood, Sweat, and Pixels is essential reading for anyone curious about the reality behind their favourite games. While it avoids delving into the technical nitty-gritty of coding, it masterfully explores the broader dynamics of game production, a balancing act between creativity, technology, and business.

If you’ve ever marvelled at the artistry of games like The Witcher 3 or Uncharted 4, this book will deepen your appreciation for the immense effort behind them. But it will also leave you questioning the sustainability of an industry built on such relentless sacrifice. As Schreier reminds us, every game represents a monumental act of passion and survival.

The forest was quiet that morning except for the wind moving through pine branches and the occasional distant shout from where the children were learning below.

Every other Saturday, my daughter attends environmental consciousness classes at the Hymettus Forest. She learns through play, discovering how to care for nature, herself, and her group. What began as her educational experience has grown into a meaningful ritual for both of us.

While she spends hours exploring, I walk. The path climbs through pine and cypress on the western slope, opening occasionally to views of Athens spreading below.

Concrete stretches without pattern or plan, the city filling every direction with precious little green breaking the density. I pause sometimes to photograph it, the same chaotic view captured dozens of times.

The walk continues with headphones on, an 80s and 90s playlist, moving without a destination.

I started bringing the Kindle months earlier, thinking I would read between walks. Instead, the book became the walk. One chapter per visit, sometimes two if they were short.

The story moved at the forest’s pace, and I let go of rushing it. It writes about friendship and creation, about building games together and the cost of making things that matter. I would read a section, then walk, then sit and read more.

The book never felt like an interruption. It felt like part of the ritual.

I believed for months that the forest was where I did my best thinking. Solitude, movement, fresh air, and time away from the constant pressure of work made it feel productive. Problems would untangle themselves while I walked, or so I thought.

Architectural decisions would clarify while I sat reading. They never did.

After more than a year of this routine, I started noticing a different pattern. On Monday morning, a technical trade-off I had been circling for weeks suddenly becomes clear. The conflicting priorities that seemed impossible to balance the previous Friday now have an obvious resolution.

By Tuesday, the documentation I had been avoiding flows without resistance. Wednesday brings a conversation about system boundaries that cuts through weeks of circular discussion.

This happens in the days after these walks, not during them. I am no longer trying when it surfaces, no longer grinding against the problem or forcing the decision. Time spent outside doesn’t just occupy me; it resets my mind, dissolves mental clutter, and sharpens my focus across work and life.

I return from these walks with empty hands and the sense that something has shifted without my participation. The urgency that distorts every decision at work loosens its grip when I stop trying to think productively.

She comes out of the forest muddy and animated, talking about the fort they built, or the beetle they found, or how one of the older kids taught her to weave grass. I come out with tired legs and a few photos. No notes, no breakthroughs, no plans.

These few hours have become essential for me as a busy dad. They help me refocus and return to daily life with renewed energy.

I actively seek these moments now while waiting for my little princess to complete her activities, understanding that the setting matters less than the practice itself.

What these brief escapes reveal about mental renewal no amount of grinding at my desk ever could. Moving away might feel like a luxury in the middle of life’s demands, but it has proven the most effective way to maintain what complex decisions require. A walk or a quiet moment creates the space for recalibration, offering a refreshed perspective for what comes next.

That October morning, finishing the book felt like completing a long project that was never really a project at all. Just something that happened slowly, in pieces, without pressure. I closed the Kindle and sat there, letting the ending settle.

She would be done soon, full of stories about whatever small discovery the morning had brought. I had nothing equivalent to offer. Just a finished book and the quiet knowledge that some part of my mind had been clearing itself while I read about characters building games.

The best decisions might require this same patience. The willingness to pull back when proximity distorts perspective. The discipline to stop analyzing and trust that answers will surface on their own schedule.

I wonder how often I resist this at work, convinced that more hours or deeper analysis will break something open, when walking away might be exactly what the problem needs.

5 5
1 2 N
LMLMLMLMM
3 3 E
MMRMMRMRRM

And respond with precise positional data:

1 3 N
5 1 E

Establishing Communication: Receiving User Input

My first challenge was creating a communication channel with Mission Control. I turned to Rust’s powerful std::io module to establish this vital link:

// src/main.rs
mod direction;
mod instruction;
mod plateau;
mod rover;

use std::io::{self, BufRead};

fn main() {
    let stdin = io::stdin();
    let lines = stdin.lock().lines();

    for line in lines {
        match line {
            Ok(content) => println!("{}", content),
            Err(error) => eprintln!("Error reading line: {}", error),
        }
    }
}

This foundational setup acts as our mission control interface. Think of it as a radio receiver - it picks up incoming transmissions (user input) and echoes them back for confirmation. The std::io module serves as our communications array, carefully monitoring each incoming signal and reporting any transmission errors.

To verify our communication systems, I ran some basic diagnostic tests:

cargo build

Followed by:

cargo run

Perfect clarity - the system faithfully relays every message it receives, confirming our communication link is operational.

Mapping the Terrain: Parsing Plateau Dimensions

A rover without terrain data is like a ship without a map. I needed to interpret the first transmission - the dimensions of our Martian plateau:

// src/main.rs

// ...

fn main() {
    let stdin = io::stdin();
    let mut lines = stdin.lock().lines();

    if let Some(Ok(plateau_dimensions)) = lines.next() {
        let plateau_parts: Vec<i32> = plateau_dimensions
            .split_whitespace()
            .map(|s| s.parse().unwrap())
            .collect();
        println!("Plateau dimensions: {:?}", plateau_parts);
    }
}

The process here is like a surveyor reading coordinates. When Mission Control transmits the plateau dimensions, my code acts as a digital cartographer. It takes the raw input string, splits it at the spaces (like separating latitude and longitude), and converts each piece into a numerical value our rover can understand. The result? A precise digital map of our operational territory.

Setting the Scene: Parsing Rover’s Initial State

With our terrain mapped, it’s time to establish our rover’s starting position. Each rover deployment needs three crucial pieces of information - its x and y coordinates on our digital map, and which way it’s facing when it touches down:

// src/main.rs

// ...

fn main() {
    // ...

    if let Some(Ok(rover_initial)) = lines.next() {
        let rover_parts: Vec<&str> = rover_initial.split_whitespace().collect();
        let x: i32 = rover_parts[0].parse().unwrap();
        let y: i32 = rover_parts[1].parse().unwrap();
        let direction = match rover_parts[2] {
            "N" => Direction::NORTH,
            "E" => Direction::EAST,
            "S" => Direction::SOUTH,
            "W" => Direction::WEST,
            _ => panic!("Invalid direction"),
        };
        println!("Rover initial position: ({}, {}), Direction: {:?}", x, y, direction);
    }
}

This setup phase is like a pre-launch checklist. The code carefully parses the deployment coordinates, treating them like a spacecraft’s landing coordinates. The direction indicator - N, E, S, or W - gets translated into our rover’s internal compass, ensuring it knows exactly which way it’s facing when it begins its mission.

Commanding the Rover: Parsing Movement Instructions

Next came the most critical part of our mission control interface - interpreting the sequence of movement commands. Each instruction is like a carefully choreographed dance move, telling our rover to pirouette left (L), right (R), or march forward (M):

// src/main.rs

// ...

fn main() {
    // ...

    if let Some(Ok(instructions_line)) = lines.next() {
        let instructions: Vec<Instruction> = instructions_line
            .chars()
            .filter_map(Instruction::from_char)
            .collect();
        println!("Rover instructions: {:?}", instructions);
    }
}

Think of this as our rover’s mission sequence - each character in the instruction line represents a specific maneuver. The code transforms these simple letters into actionable commands our rover can understand, like translating Morse code into clear instructions.

Synchronizing the Mission: Integrating Components

With all our systems ready, it was time to bring everything together into a coordinated mission control center. Like launching a space mission, every component needs to work in perfect harmony:

// src/main.rs

mod direction;
mod instruction;
mod plateau;
mod rover;

use direction::Direction;
use instruction::Instruction;
use plateau::Plateau;
use rover::Rover;
use std::io::{self, BufRead};

fn main() {
    let stdin = io::stdin();
    let mut lines = stdin.lock().lines();

    let plateau_dimensions = lines.next().unwrap().unwrap();
    let plateau_parts: Vec<i32> = plateau_dimensions
        .split_whitespace()
        .map(|s| s.parse().unwrap())
        .collect();

    let rover_initial = lines.next().unwrap().unwrap();
    let rover_parts: Vec<&str> = rover_initial.split_whitespace().collect();
    let x: i32 = rover_parts[0].parse().unwrap();
    let y: i32 = rover_parts[1].parse().unwrap();
    let direction = match rover_parts[2] {
        "N" => Direction::NORTH,
        "E" => Direction::EAST,
        "S" => Direction::SOUTH,
        "W" => Direction::WEST,
        _ => panic!("Invalid direction"),
    };

    let instructions_line = lines.next().unwrap().unwrap();
    let instructions: Vec<Instruction> = instructions_line
        .chars()
        .filter_map(Instruction::from_char)
        .collect();

    let plateau = Plateau::new(plateau_parts[0], plateau_parts[1]);
    let mut rover = Rover::new(x, y, direction, &plateau);

    rover.execute_instructions(&instructions);
}

Like a well-orchestrated space mission, each piece plays its crucial role. First, we establish our terrain parameters, then position our rover, and finally load its mission instructions. Every component - from the plateau dimensions to the rover’s directional systems - comes together in a seamless integration.

Broadcasting the Results: Sharing Rover Outcomes

After each successful mission, Mission Control needs accurate position reports. I added some eyes to our rover:

// src/main.rs

// ...

fn main() {
    // ...

    println!("{} {} {:?}", rover.x(), rover.y(), rover.direction());
}

When I put this to the test with a sample mission:

5 5
1 2 N
LMLMLMLMM

The rover reported back:

1 3 NORTH

Tuning the Details: Refining Output Format

Mission Control protocols are strict - they expect position reports in a specific format. 1 3 NORTH wouldn’t do - they need 1 3 N. Time for some message formatting:

// src/direction.rs
#[derive(Debug, PartialEq)]
pub enum Direction {
    NORTH,
    EAST,
    SOUTH,
    WEST,
}

impl Direction {
    pub fn as_char(&self) -> char {
        match self {
            Direction::NORTH => 'N',
            Direction::EAST => 'E',
            Direction::SOUTH => 'S',
            Direction::WEST => 'W',
        }
    }
}

A quick update to our transmission format:

// src/main.rs

// ...

fn main() {
    // ...

    println!("{} {} {}", rover.x(), rover.y(), rover.direction().as_char());
}

Final Touches: Managing Multiple Rovers

The real challenge emerged when Mission Control revealed their master plan - coordinating multiple rovers! Each rover would receive its own set of instructions:

5 5
1 2 N
LMLMLMLMM
3 3 E
MMRMMRMRRM

Like an air traffic controller managing multiple aircraft, I needed to coordinate multiple rover operations:

// src/main.rs

// ...

fn main() {
    // ...

    let mut i = 1;
    while i < lines.len() {
        if i + 1 >= lines.len() {
            break;
        }

        let rover_initial = &lines[i];
        let rover_parts: Vec<&str> = rover_initial.split_whitespace().collect();
        let x: i32 = rover_parts[0].parse().unwrap();
        let y: i32 = rover_parts[1].parse().unwrap();
        let direction = match rover_parts[2] {
            "N" => Direction::NORTH,
            "E" => Direction::EAST,
            "S" => Direction::SOUTH,
            "W" => Direction::WEST,
            _ => panic!("Invalid direction"),
        };

        let instructions_line = &lines[i + 1];
        let instructions: Vec<Instruction> = instructions_line
            .chars()
            .filter_map(Instruction::from_char)
            .collect();

        let mut rover = Rover::new(x, y, direction, &plateau);
        rover.execute_instructions(&instructions);

        println!("{} {} {}", rover.x(), rover.y(), rover.direction().as_char());

        i += 2;
    }
}

When put to the test with our multi-rover scenario:

5 5
1 2 N
LMLMLMLMM
3 3 E
MMRMMRMRRM

Mission accomplished! Each rover reported its position perfectly:

1 3 N
5 1 E

Verifying the Expedition: Writing Integration Tests

Success is great, but in space exploration, we verify everything twice. I needed comprehensive tests to ensure our multi-rover coordination system worked flawlessly under all conditions:

// tests/integration_test.rs
use std::process::{Command, Stdio};
use std::io::Write;

#[test]
fn test_multiple_rovers() {
    let mut child = Command::new("cargo")
        .arg("run")
        .stdin(Stdio::piped())
        .stdout(Stdio::piped())
        .spawn()
        .expect("Failed to start cargo run");

    {
        let stdin = child.stdin.as_mut().expect("Failed to open stdin");
        let input = b"5 5\n1 2 N\nLMLMLMLMM\n3 3 E\nMMRMMRMRRM\n";
        stdin.write_all(input).expect("Failed to write to stdin");
    }

    let output = child.wait_with_output().expect("Failed to read stdout");

    let expected_output = "1 3 N\n5 1 E\n";
    let actual_output = String::from_utf8_lossy(&output.stdout);

    assert_eq!(actual_output, expected_output);
}

This test suite acts like a mission simulator. It sends commands just like Mission Control would and verifies that our rovers respond exactly as expected. Think of it as a dress rehearsal for the real Mars mission - every command must execute perfectly, every position report must be precise.

I run the full battery of tests with:

cargo test

When every test passes, I know our rovers are ready for their Martian adventure. The integration tests confirm that our entire command and control system - from receiving instructions to coordinating multiple rovers to reporting positions - works in perfect harmony. This comprehensive testing approach ensures that when our rovers touch down on Mars, they’ll execute their missions flawlessly, navigating the red planet’s terrain with precision and reliability.

The journey through this challenge has finally reached its conclusion, and what a gratifying experience it turned out to be. While Rust Analyzer flags a couple of minor issues, the robust test suite provides confidence that these will be straightforward fixes.

The code is available for perusal on Github, marking the end of this rewarding coding adventure.

To kick things off, I got my project set up using Cargo – nothing fancy, just the basics:

cargo new mars-rover-rust
cd mars-rover-rust

Charting the Course: Defining Directions

First up, I needed to figure out how our little rover would know which way it’s facing. I went with the classics here – good old North, East, South, and West. Here’s how I set that up in Rust:

// src/direction.rs
#[derive(Debug, PartialEq)]
pub enum Direction {
    NORTH,
    EAST,
    SOUTH,
    WEST,
}

Pretty straightforward, right? I added those Debug and PartialEq traits since I knew we’d want to peek at these values during debugging and compare them in our tests.

Steering the Rover: Implementing Turns

Now for the fun part – teaching our rover how to turn! I created a Rover struct and gave it some basic turning abilities:

// src/rover.rs
use crate::direction::Direction;

#[derive(Debug, PartialEq)]
pub struct Rover {
    x: i32,
    y: i32,
    direction: Direction,
}

impl Rover {
    pub fn new(x: i32, y: i32, direction: Direction) -> Self {
        Rover { x, y, direction }
    }

    pub fn turn_left(&mut self) {
        self.direction = match self.direction {
            Direction::NORTH => Direction::WEST,
            Direction::WEST => Direction::SOUTH,
            Direction::SOUTH => Direction::EAST,
            Direction::EAST => Direction::NORTH,
        };
    }

    pub fn turn_right(&mut self) {
        self.direction = match self.direction {
            Direction::NORTH => Direction::EAST,
            Direction::EAST => Direction::SOUTH,
            Direction::SOUTH => Direction::WEST,
            Direction::WEST => Direction::NORTH,
        };
    }
}

Of course, I had to make sure our rover could actually turn properly, so I wrote some tests to put it through its paces:

// src/rover.rs
#[cfg(test)]
mod tests {
    use super::*;
    use crate::direction::Direction;

    #[test]
    fn test_turn_left() {
        let mut rover = Rover::new(0, 0, Direction::NORTH);
        rover.turn_left();
        assert_eq!(rover.direction, Direction::WEST);
        rover.turn_left();
        assert_eq!(rover.direction, Direction::SOUTH);
        rover.turn_left();
        assert_eq!(rover.direction, Direction::EAST);
        rover.turn_left();
        assert_eq!(rover.direction, Direction::NORTH);
    }

    #[test]
    fn test_turn_right() {
        let mut rover = Rover::new(0, 0, Direction::NORTH);
        rover.turn_right();
        assert_eq!(rover.direction, Direction::EAST);
        rover.turn_right();
        assert_eq!(rover.direction, Direction::SOUTH);
        rover.turn_right();
        assert_eq!(rover.direction, Direction::WEST);
        rover.turn_right();
        assert_eq!(rover.direction, Direction::NORTH);
    }
}

A quick cargo test lets us know if everything’s working as planned.

Mapping the Terrain: Setting Up the Plateau

Here’s where things got interesting – I realized our rover needed some boundaries to roam within. Can’t have it wandering off into space! So I created a Plateau to keep it in check:

// src/plateau.rs
#[derive(Debug, PartialEq)]
pub struct Plateau {
    width: i32,
    height: i32,
}

impl Plateau {
    pub fn new(width: i32, height: i32) -> Self {
        Plateau { width, height }
    }

    pub fn is_within_bounds(&self, x: i32, y: i32) -> bool {
        x >= 0 && x <= self.width && y >= 0 && y <= self.height
    }
}

Advancing the Rover: Moving Forward

With our playground set up, it was time to teach our rover how to actually move around:

// src/rover.rs
use crate::plateau::Plateau;

impl Rover {
    pub fn move_forward(&mut self, plateau: &Plateau) {
        let (new_x, new_y) = match self.direction {
            Direction::NORTH => (self.x, self.y + 1),
            Direction::EAST => (self.x + 1, self.y),
            Direction::SOUTH => (self.x, self.y - 1),
            Direction::WEST => (self.x - 1, self.y),
        };

        if plateau.is_within_bounds(new_x, new_y) {
            self.x = new_x;
            self.y = new_y;
        }
    }
}

And naturally, we needed to make sure it behaves:

// src/rover.rs
#[cfg(test)]
mod tests {
    use super::*;
    use crate::plateau::Plateau;

    #[test]
    fn test_move_forward_within_bounds() {
        let plateau = Plateau::new(5, 5);
        let mut rover = Rover::new(0, 0, Direction::NORTH);
        rover.move_forward(&plateau);
        assert_eq!(rover.x, 0);
        assert_eq!(rover.y, 1);
    }

    #[test]
    fn test_move_forward_out_of_bounds() {
        let plateau = Plateau::new(5, 5);
        let mut rover = Rover::new(0, 0, Direction::SOUTH);
        rover.move_forward(&plateau);
        assert_eq!(rover.x, 0);
        assert_eq!(rover.y, 0);
    }
}

Commanding the Rover: Processing Instructions

Finally, the piece that brings it all together – teaching our rover to follow commands:

// src/rover.rs
impl Rover {
    pub fn execute_commands(&mut self, commands: &str, plateau: &Plateau) {
        for command in commands.chars() {
            match command {
                'L' => self.turn_left(),
                'R' => self.turn_right(),
                'M' => self.move_forward(plateau),
                _ => {},
            }
        }
    }
}

And here’s the grand finale of our test suite:

// src/rover.rs
#[cfg(test)]
mod tests {
    use super::*;
    use crate::direction::Direction;
    use crate::plateau::Plateau;
    use crate::instruction::Instruction;

    // Existing tests...

    #[test]
    fn test_execute_instructions() {
        let plateau = Plateau::new(5, 5);
        let mut rover = Rover::new(1, 2, Direction::NORTH, &plateau);
        let instructions = [
            Instruction::LEFT, Instruction::MOVE, Instruction::LEFT, Instruction::MOVE,
            Instruction::LEFT, Instruction::MOVE, Instruction::LEFT, Instruction::MOVE,
            Instruction::MOVE
        ];
        rover.execute_instructions(&instructions);
        assert_eq!(rover.x, 1);
        assert_eq!(rover.y, 3);
        assert_eq!(rover.direction, Direction::NORTH);

        let mut rover = Rover::new(3, 3, Direction::EAST, &plateau);
        let instructions = [
            Instruction::MOVE, Instruction::MOVE, Instruction::RIGHT, Instruction::MOVE,
            Instruction::MOVE, Instruction::RIGHT, Instruction::MOVE, Instruction::RIGHT,
            Instruction::RIGHT, Instruction::MOVE
        ];
        rover.execute_instructions(&instructions);
        assert_eq!(rover.x, 5);
        assert_eq!(rover.y, 1);
        assert_eq!(rover.direction, Direction::EAST);
    }
}

And there you have it! Our Mars Rover is now ready to explore its virtual plateau. I’ve got to say, as someone still getting their feet wet with Rust, seeing this all come together has been incredibly satisfying. The code might not be perfect by Rust standards, but hey, it works!

Next up on my list is handling user input and prettifying the output. But that’s a story for another day!

Setting the Scene

Imagine controlling rovers tasked with exploring the Martian terrain. These rovers need to navigate a rectangular plateau while sending visual data back to Earth. The challenge involves translating simple commands into precise rover movements, and dealing with positioning, orientation, and grid-based navigation.

The Challenge

A squad of robotic rovers is to be landed by NASA on a plateau on Mars.

This plateau, which is curiously rectangular, must be navigated by the rovers so that their onboard cameras can get a complete view of the surrounding terrain to send back to Earth. A rover’s position is represented by a combination of x and y co-ordinates and a letter representing one of the four cardinal compass points. The plateau is divided up into a grid to simplify navigation. An example position might be 0, 0, N, which means the rover is in the bottom left corner and facing North.

In order to control a rover, NASA sends a simple string of letters. The possible letters are L, R, and M. L and R make the rover spin 90 degrees left or right respectively, without moving from its current spot.

M means move forward one grid point and maintain the same heading.

Assume that the square directly North from (x, y) is (x, y+1).

Input:

The first line of input is the upper-right coordinates of the plateau. The lower-left coordinates are assumed to be 0,0. The rest of the input is information pertaining to the rovers that have been deployed. Each rover has two lines of input. The first line gives the rover’s position, and the second line is a series of instructions telling the rover how to explore the plateau. The position is made up of two integers and a letter separated by spaces, corresponding to the x and y coordinates and the rover’s orientation.

Each rover will be finished sequentially, which means that the second rover won’t start to move until the first one has finished moving.

Output:

The output for each rover should be its final coordinates and heading.

Test Input:

5 5
1 2 N
LMLMLMLMM
3 3 E
MMRMMRMRRM

Test Output:

1 3 N
5 1 E

Breaking Down the Requirements

Let’s analyze what we’re dealing with:

1. The Environment

   • A rectangular plateau defined by coordinates
   • Grid-based movement system
   • Origin point (0,0) at bottom-left

2. Rover Capabilities

   • Position tracking (x,y coordinates)
   • Cardinal direction orientation (N,E,S,W)
   • Three basic commands:
     • Rotate left 90° (L)
     • Rotate right 90° (R)
     • Move forward one grid unit (M)

3. System Behavior

   • Sequential rover movement (one at a time)
   • Position updates after each move
   • Boundary awareness required
   • Final position reporting

Why This is Great for Learning

This challenge touches on several fundamental Rust concepts:

• Enums (for directions and commands)
• Structs (for rover and plateau representation)
• Error handling (for boundary violations)
• String parsing
• Vector operations
• Testing

P.S. If you’d like to dive straight into the code, you can find the implementation on GitHub.