Hey everyone, Alex here. Welcome back to another edition of Coding with Alex on sysseder.com.
If you've been hanging around Hacker News lately, you might have noticed a classic essay resurfacing on the front page: Paul Lockhart's famous 2002 paper, "A Mathematician's Lament". If you haven't read it, Lockhart presents a devastating critique of how mathematics is taught in schools. Instead of showing students the beautiful, creative art of pattern-hunting and problem-solving, we force them to memorize dry, bureaucratic formulas and perform mindless procedural tasks—like painting by numbers without ever seeing a canvas.
As I reread his lament this week, a cold realization hit me: modern software engineering is facing its own Lockhart moment.
Too often, we treat coding not as a creative craft of modeling reality, but as a bureaucratic exercise in connecting enterprise APIs, writing boilerplate YAML configurations, and mindlessly applying design patterns we don't fully understand. We’ve traded the joy of elegant abstraction for the safety of rigid checklists. Today, we’re going to look at Lockhart’s philosophy through the lens of modern software development, explore why "bureaucratic code" happens, and look at concrete ways we can bring the artistry, elegance, and pure joy back to our codebases.
The Two Types of Code: Artistry vs. Bureaucracy
In his essay, Lockhart describes a nightmare scenario where music is taught entirely by rote memorization of sheet music, without students ever being allowed to hear or play an actual instrument. He writes:
"Since sheet music is to be played, not read, what is the point of learning to read it if you’re never going to play? ... The musician’s lament is that the art is gone, replaced by a tedious, soul-crushing exercise in notation."
In web development and cloud infrastructure, we do this all the time. Think about how we onboard junior developers. Do we sit down and marvel at how a recursive algorithm can elegantly parse a nested JSON tree? Or do we hand them a 40-step setup guide, tell them to copy-paste a 300-line Webpack configuration, and warn them not to touch the dependency injection framework because "it just works, don't ask why"?
When code becomes bureaucratic, we lose the ability to see the underlying architecture. Let’s look at a concrete example of this contrast in action: handling API integrations.
The Bureaucratic Approach
Consider a standard enterprise pattern for fetching and processing user data. In many modern frameworks, the "standard" way to write this involves layers of abstract factory factories, strict DTOs (Data Transfer Objects), and excessive boilerplate that obscures what the code actually does.
// The Over-Engineered, Bureaucratic Way
class UserFetchService {
private HttpConnectorInterface $connector;
private UserHydrationFactory $hydrator;
private LoggerInterface $logger;
public function __construct(
HttpConnectorInterface $connector,
UserHydrationFactory $hydrator,
LoggerInterface $logger
) {
$this->connector = $connector;
$this->hydrator = $hydrator;
$this->logger = $logger;
}
public function executeFetchAction(UserFetchRequestDto $request): UserResponseDto {
$this->logger->info("Initiating fetch sequence for ID: " . $request->getId());
try {
$rawPayload = $this->connector->send("/users/" . $request->getId(), 'GET');
$userEntity = $this->hydrator->createFromRawPayload($rawPayload);
return new UserResponseDto(
$userEntity->getId(),
$userEntity->getFullName(),
$userEntity->getEmailAddress()
);
} catch (Exception $e) {
$this->logger->error("Fetch sequence failed: " . $e->getMessage());
throw new UserFetchException("Failed", 500, $e);
}
}
}
Is this safe? Sure. Is it highly decoupled? Arguably. But it is also incredibly sterile. The actual idea—fetching a user's details and mapping them—is buried under a mountain of structural scaffolding. The developer who wrote this wasn't thinking about the beauty of data transformation; they were thinking about satisfying the static analyzer and the architectural guidelines document.
The Creative, Expressive Approach
Now, let's look at how we might express the same intent in a functional, data-first manner. Let's use modern TypeScript to treat the data and the operation as first-class citizens, focusing on clarity, type safety, and readability without the administrative bloat.
// The Expressive, Creative Way
import { z } from 'zod';
// Define the shape of our data transparently
const UserSchema = z.object({
id: z.string(),
name: z.string(),
email: z.string().email(),
});
type User = z.infer<typeof UserSchema>;
// A clean, composable function that does one thing beautifully
export async function fetchUser(userId: string): Promise<User> {
const response = await fetch(`/api/v1/users/${userId}`);
if (!response.ok) {
throw new Error(`Failed to fetch user ${userId}: ${response.statusText}`);
}
const rawData = await response.json();
// Runtime validation ensures our system's boundaries are safe
return UserSchema.parse(rawData);
}
Notice the difference? The second example isn't just shorter; it's honest. It uses functional composition, treats validation as a first-class mathematical constraint (via Zod), and doesn't hide behind interfaces that only have a single implementation. It allows the next developer to instantly grasp the developer's mental model.
The Fallacy of "Paint-by-Numbers" Architecture
Lockhart argues that by giving students the answers (formulas) before they even understand the questions (the geometric puzzles), we destroy their natural curiosity.
In DevOps and cloud engineering, we fall into this trap constantly with infrastructure as code (IaC) and microservice architectures. How many times have you seen a startup with three developers and fifty active users build a fully decoupled, multi-region Kubernetes cluster running twenty microservices communicating via an asynchronous event bus?
They did this because they read that this is "how modern software is built." They adopted the formula (Kubernetes + Kafka + gRPC) without actually experiencing the pain point that the formula was designed to solve (massive organizational scale, independent team deployment cycles, high-volume write bottlenecks).
Reclaiming the Narrative: An Incremental Architecture
Instead of starting with the "formula," we should start with the "problem." Let’s look at how we can model our architectural evolution organically. Instead of jumping straight to a complex distributed system, design your applications to be modular monoliths first. Keep your domains separated at the code level, not the network level.
Consider this simple architectural flow of a cleanly separated modular monolith:
+-------------------------------------------------------------+ | MODULAR MONOLITH | | | | +------------------+ +----------------------+ | | | Order Module | --(Event)-->| Inventory Module | | | | | | | | | | - CreateOrder() | | - ReserveStock() | | | +------------------+ +----------------------+ | | | | | | +-----------------+----------------+ | | | | | v | | Shared Database | | | +-------------------------------------------------------------+
By keeping the modules in the same codebase and database but strictly decoupling their logical boundaries, you preserve your ability to split them into microservices later if and when scale demands it. You aren't paying the "microservice tax" (network latency, distributed tracing, complex CI/CD pipelines) on day one. You are allowed to play with the shapes of your domain before committing them to hard network boundaries.
How to Foster "Mathematical" Play in Your Daily Dev Life
If you want to escape the corporate boilerplate and bring the joy of pure problem-solving back to your daily workflow, here are three actionable shifts you can make today.
1. Write Code That Explains the "Why," Not Just the "How"
When writing comments or documentation, don't just restate what the code does. The compiler already knows what it does. Instead, explain the beauty of the solution or the historical context of the constraint.
// BAD: Restating the obvious (bureaucratic)
// Increment the retry counter and save to DB
this.retryCount += 1;
await this.save();
// GOOD: Explaining the elegant compromise (creative)
// We use an exponential backoff here to prevent "thundering herd"
// problems on our legacy auth server during peak traffic recovery.
const delay = Math.pow(2, attempt) * 100 + Math.random() * 100;
await sleep(delay);
2. Lean into Declarative Paradigms
Imperative programming forces you to write the exact step-by-step instructions for the machine to execute. Declarative programming, on the other hand, allows you to describe what you want, leaving the runtime to figure out the most efficient way to do it. This is highly analogous to the difference between mechanical arithmetic and elegant algebraic proofs.
Compare this imperative array manipulation with its clean, functional, declarative counterpart:
// Imperative: Messy loops, state mutation, highly error-prone
const activeAdmins = [];
for (let i = 0; i < users.length; i++) {
if (users[i].isActive) {
if (users[i].roles.includes('ADMIN')) {
activeAdmins.push(users[i].email);
}
}
}
// Declarative: Elegant, pipeline-based, readable
const activeAdminEmails = users
.filter(user => user.isActive)
.filter(user => user.roles.includes('ADMIN'))
.map(user => user.email);
3. Ruthlessly Prune Your Dependencies
In his essay, Lockhart complains that school curriculum is cluttered with "terms and definitions" instead of active mathematical play. In modern web development, our NPM lockfiles are the ultimate equivalent of this clutter. We import thousands of packages we barely understand to solve simple problems we could write ourselves in ten lines of clean code.
Next time you go to install a package for a simple utility, pause. Try writing the utility yourself. Explore the problem space. You’ll gain a deeper understanding of the runtime, improve your native API skills, and keep your production bundle sizes beautifully lean.
Conclusion: Rejecting the Assembly Line
Paul Lockhart’s warning to mathematicians is a warning we must take to heart as software engineers: if we let our craft become entirely defined by frameworks, rigid standards, and mindless compliance, we will burn out. We will stop seeing software as a medium for human expression and start seeing it as an assembly line.
The next time you sit down at your IDE, don't just focus on getting the ticket to pass QA. Take a moment to look at the architecture. Is it elegant? Does it tell a story? Is there a cleaner, more creative way to express your logic? Treat your code as a canvas, not a spreadsheet.
What are your thoughts? Have we lost the "art" of programming to enterprise bureaucracy, or do rigid frameworks actually free us up to solve bigger problems? Let’s talk about it in the comments below!
Until next time, keep your code clean and your abstractions elegant.
— Alex