That’s the argument I get every time I dare criticize code and content that’s too close to the default weights of an LLM.

“Humans write slop too!”

If anything, this is an improvement, an increase of the baseline.

The kind of slop humans wrote is a lot sloppier than the off-the-shelf AI slop we get nowadays. Social media posts used to be full of grammatical errors, code used to be buggy and unstructured, and it barely got the job done.

I’ve written entire articles on the importance of good code comments and how to write them.

So I should be happy now.

I’m drowning in code comments.

Why get all nostalgic over organic grass-fed slop?

Because it’s proof of thought.

Someone did the thinking.

It may not have been a lot of thinking, it may not have been great thinking, not even good thinking, but some thinking happened.

Someone put their mind to it and birthed that monstrous code that pushes the Geneva Convention to its limits. And if you find the person who created it, they would most likely tell you the reason behind every cubic inch of that garbage.

The code I read today feels like it was written by Clean Code absolutists who were finally given free rein to write the overly abstract, generic implementations they’ve been dreaming about for a decade.

Communication is becoming more generic too.

Read some posts on LinkedIn.

Take a look at some of the long messages you get on Slack.

The text looks better, it’s grammatically excellent and well-structured, but sometimes I just can’t understand what people are trying to say. Every time I get a wall of text, I know I’ll be playing the game of finding the one sentence in the whole paragraph that’s relevant to me.

“Yes, this is true Alex, but let’s zoom out a bit and take a look at the bigger picture“

I don’t need Pangram to tell me who wrote this.

See, back in my day I’d just get one sentence.

It would be impolite, error-ridden garbage in the grammatical sense, but it would be the original thought.

The baseline has increased, but not everything needs to be at the new baseline.

I’ve been studying design this year (UI/UX/Interactions), and many of the interfaces that seem beautiful at a glance suffer from the same overly-abstract sloppification that we see in code and writing.

You don’t need an eyebrow over every section title.

The same way you don’t need the custom stringify method.

The same way you don’t need two paragraphs.

I was wondering if it’s the lack of taste showing through this, because once you develop an eye for code, UIs, and prose, the slop-era software feels like you’re interfacing with public administration.

A lot of overhead for no reason.

Maybe it’s the lack of care.

Every now and then I think about Taylor Otwell’s obsession with comments in the Laravel codebase.

Each implementation comment needs to be exactly 3 lines, and every new line must be 3 characters shorter than the one before.

“It is indeed intentional. I’m not sure if it’s awesome or neurotic either… :) Also, it is not just config files – it is the entire framework. Config files are the first impression of the framework once you have it installed. So, I want it to be pleasant to the eye. The symmetrical comments help with that. I don’t want your first impression of the code to “appear” disorganized or something. I dunno. It’s kind of crazy. I do it with all of the Laravel core code. If it doesn’t look pleasing to the eye, I keep working on it until it is.”

— Taylor Otwell

I started my programming career with Laravel, and I remember how well-structured Taylor’s code looked in some of the tutorial videos, and the haiku-esque comments contribute greatly.

Formatting text to make it look good is a lot of work.

Hyphenation and justification are hard to get right, so in the 1990s rs1n solved the structure problem in the Super Metroid guide with… word choice.

These are the kind of things I’m nostalgic about.

Writing is the by-product of a more abstract ability we call thinking.

“If you’re thinking without writing, you only think you’re thinking.“
— Leslie Lamport

Without writing, your thoughts remain abstract and scattered. When you put them into words, they need to take a specific, pristine shape that you can show to others. Code, by extension, has that same property.

With LLMs, we can front-load that thinking and skip the physical process of writing.

But if you don’t formulate that pristine thought, then you get a result that’s as abstract as it was in your head - no matter if it’s code or prose or design.

Because if you’re writing without thinking, you only think that you’re writing.

Coding agents are very good. No, they’re incredible.

But many of the arguments we had against them still stand.

Their software design is questionable and often optimizes for local maxima. They overcomment and write verbosely. They produce visual design focused on looking “designed” but struggle with usability.

But guess what?

The world is still spinning.

Yeah, it turns out that “good-enough” is good enough for most teams out there. You can say that people want good software, perfect software, exceptional software, and some do.

But a lot of people order from Temu, so you need to know your audience.

Great will always require a personal touch and attention, but this is not about making great software or even good software. We’re concerned with why we still haven’t created an assembly line for “good-enough“ software.

My running theory is that this is due to the constantly changing context required for baseline quality.

Second-order effects

Every change we make to a piece of software has obvious effects and secondary ones that are not as easy to predict.

When I worked at media, we redesigned a website and the natural result was better readability, accessibility, load times, and a more modern look.

The second-order effect (one we didn’t foresee) was a broken print format, which turned out to be important for some of our aging users who actually print the web page on paper before reading it.

The natural effect of coding agents is that people push more code.

The second-order effect is that GitHub’s uptime suffers because its load has increased tenfold. The third-order effect of this is that your own development workflow gets disturbed because of GitHub actions.

The expected effect of adding slick animations to buttons is to make the UI better.

The reality is that animations on frequently-used actions make it clunkier and harder to use. They create a delay before every action which does more harm than good. If you’re on a Mac machine, open the right-click contextual menu anywhere. You’ll notice that it appears instantly, but when you click outside it fades away. Its appearance is not animated precisely because of that.

This happens both with small-scale changes in a single product and large-scale industry shifts, and a big part of maintaining the quality of a software product is foreseeing or reacting to these second- and third-order effects.

Even “good-enough” software with no ambition of entering the software book of greatness needs to take care of these, and that’s what prevents it from fully turning into an assembly line.

There are small yet critical deviations from the base path.

Which is a context problem.

For a coding agent to consider some of these second-order effects, it needs broader context - about the company, about the users, about the world.

“So why don’t we pass the context to the agent?”

The relevant context changes as the software changes. There are different parts of the company and the outside world that are relevant to every new feature.

“So why don’t we pass all of it?”

Then the signal-to-noise ratio gets out of balance, and the agent can start over-engineering irrelevant bits of the codebase, which you once again need to review.

It’s very difficult to figure out why one embedding scored over another, for example, so the current generation of agents relies on search tools, but sometimes these second-order effects are not directly corelated and they’re not easy to spot.

I imagine that the companies working on context solutions are trying to solve this.

“But we can have another agent review the PR of the first one based on specific rules!”

Show me a setup that’s given you good actionable results and I’ll agree.

I think that quality can’t be automated.

Some of it can, of course.

It’s naive to think that quality doesn’t benefit from automation. We’ve been using tests, linters, and various static analysis tools to guarantee a quality baseline, but this is a part of QA, not the whole. The industrialist dream is to scale up this effort in a way that allows us to produce software en masse, and to my surprise we’re close to that.

The industry has become more capital intensive than before.

But throwing money at an agent doesn’t produce the same results like throwing money at new agricultural equipment would because the second-order effect management (still) requires manual effort.

And most importantly - it requires direction.

In Bulgaria, we have a saying that goes something in the lines of:

“The rushed work is a shame for the craftsman”

You use it when someone does something sloppily in a rush just so they can get the task off their hands. Fix a sink, paint a wall, build a backoffice application.

That kind of thing.

My grandmother has repeated this so many times when I wanted to rush through my chores. Her generation insisted on doing things right the first time, so she’d get me to tidy the desk drawers after I had stashed all my stuff in them just so I could go out and play.

“The rushed work is a shame for the craftsman”

We are obsessed with speed because quickness translates to profit for a business. But I’ve never seen someone who is focused solely on speed do great work.

I have it nailed in my head that speed on its own is not a virtue. Everybody on this Earth knows it as well, yet we still try to turn every job into a Doom speedrun.

Yeah, the best people I’ve worked with have always been fast.

But not because they’re rushing.

It was because their movements don’t have fat in them. They work deliberately, they don’t take unnecessary actions, they know what they’re aiming for.

It’s not speed but smoothness.

That smoothness comes predominantly from knowing what you want. Knowing what you need to do on the first try. That’s where the taste everyone is talking about comes in.

Teams are slow because they need more time to think, to try out approaches, to test. Thinking of the correct solution requires contact with reality, and some builders are slow because they make it infrequently.

If you don’t read the code, you’ll be a lot quicker.

But one of these things Rauch posted about will also be true:

The other day I asked Claude to create a shape for a subtle background accent on some pages, and it created an svg with polygons. Good if you’re in a rush and you don’t care, but when I started tweaking the shape to make it perfect, I found out how difficult it is to move polygons based on points.

Had I known what I wanted, I could’ve told it to use divs with a border and rotate them.

I meditate on this because I think you only become good by doing homework, by studying the tape. It’s easy to lie to yourself. I could’ve complained about the model not being good enough after the tenth polygon change, but the reality is that I didn’t know what I wanted.

I’m the slowest when I haven’t done my homework.

I’m quick when I’ve done some work beforehand. I’ve followed my curiosity, gone down rabbit holes without a need.

I’m fast when I have taste.

Otherwise, I stumble through an implementation like a pinball ball, bouncing from one solution to the next. That’s not necessarily bad. But I recognize it, and I don’t expect speed or smoothness. I expect iterations and learnings.

Try to be fast without knowing what you want and you’ll produce garbage.

“The rushed work is a shame for the craftsman”

The best showcase for human skill is the Dark Souls streamers who can beat all 3 games back to back on a naked level 1 character armed with a club. No clothes, no upgrades, no tricks. Just a man and a dream.

Kind of goes the same for software.

I’m sure that no matter the agents I have access to, I won’t be able to produce a design as beautiful as Josh Puckett.

I’ll make something good, no doubt about it. Through grit, careless permission approvals, and continuously renewing my usage limit, I’ll put something together. But someone better will make a more beautiful interface with nothing more than Sublime Text without a license and the Google search auto-generated AI response.

A few days ago someone posted a game demo on X that Claude one-shotted.

People say you should let the agent take care of the details while you control the broad vision.

Brother, it’s all about the details.

Anyone equipped with the same off-the-shelf tools you have can build that flashy demo. But someone good at game dev can put some basic assets together with a better game loop, and people will prefer it. Access to tools is not a competitive advantage in an industry that still finds ways to open source its critical pieces.

But there’s a sense that if you’re not focusing on tools you’ll be left behind, stuck out of time.

You won’t.

Everybody’s behind. If you’re not working in a frontier lab right now and you get your news from a blog post, you’re already behind. Who knew about harness engineering and agentic coding 3 years ago? Who knows how we’ll be writing software in 3 more years? Only those who are pushing the technology forward have an idea. The rest of us are following.

There’s a notion that using the tool is a skill on its own.

But mastering a new tool like agentic coding is much easier for the skilled. Models get better with every generation. They will understand you more and more easily as time goes on, but you need to know what to ask of the genie.

We gravitate around patterns and ideas until something happens and turns the whole industry on its head.

The arguments about programming languages, frameworks, testing, and code quality we had before November 2022 have now turned into arguments about coding agents, models, harness setups, and tool usage.

Because no one knows the best way to build software.

Yet those who are more skilled consistently make better creations than those who put their trust in tools.

Cynicism is a natural reaction to disappointment.

When I got neglected during a promotion cycle, when the feature I poured my soul into got scrapped without warning, when I had to clean up a mess I didn’t cause.

That’s when cynicism got hold of me.

The details I thought so much about amounted to nothing. The code will rot anyway. The effort is not worth it.

Companies are factories for cynicism.

Through ignored feedback and managers who say that care matters but do not reward it. There’s a structural dimension to this feeling that puts every builder to the test at some point in their career.

You can succumb to cynicism, collect your paycheck, and do the bare minimum.

But you know what beat the cynicism out of me?

No one admires the cynic’s work.

We admire those who continued to build and hope while the cynics in Greece walked around naked and slept on the streets.

Think about the most popular open source libraries in the ecosystem you’re working in. Do you think they were built by cynics?

“Cynicism is the intellectual cripple’s substitute for intelligence.” — Russell Lynes

I can’t allow myself to be negative about my work even on my worst days because that mindset spreads like wildfire. All it takes is for one builder to start, and the trend of carelessness continues.

The Broken Windows Theory in criminology states that unmaintained neighborhoods attract more criminal activity.

Lack of care when building software works the same way.

It’s even harder to resist cynicism in the age of slop.

You put care and effort into your work.

Then someone does a drive-by PR solely authored by an LLM without as much as looking at the final result, and they’re praised for their speed and token utilization.

How do I avoid becoming a cynic?

I go back to that same sentence.

No one admires the cynic’s work.

Every time I travel to Sofia (Bulgaria’s capital city), I pass by this typical Eastern European house that has a wooden porch, red roof tiles... and a mini Chinese pagoda in its front yard.

Has to be the most tasteless thing I’ve ever seen.

But what the hell is taste anyway?

“Taste has become as much of a Silicon Valley cliché as ‘disruption’ was in the twenty-tens.”

I’m convinced that the Rick Rubin memes are the reason we’re talking about taste so much. Every talk about the future of the software industry mentions it. Once technical ability is less needed, it’s your innate ability to recognize beauty that determines the outcome.

Taste is declining the implementation plan because it’s ill-designed.

Taste is removing the hover state from an element that’s not interactive.

Taste is avoiding the default LLM weights that appear everywhere (like italics in landing page copy).

Taste is knowing what to ask the genie so it doesn’t give you something messed up.

Matching the requirements for first contentful paint does not require taste.

Taste is unguided pattern-matching that teaches our neurons to fire when they see “good” work without explicit explanation as to why.

But how do you develop good taste?

Who decides that some patterns are better than others?

Why can’t you put a pagoda in your yard?

How good your taste is depends on how well it matches the economic, political, and societal environment.

A pagoda in your art is tasteless because it doesn’t match anything our culture is used to doing. There hasn’t been a need to match Eastern European and Chinese architecture before, and we haven’t figured out the best patterns to do this beautifully.

Taste is a recognition of the needs of the current time.

We don’t appreciate the SOLID principles in isolation. We think of extensibility as a sign of good taste because it contributes to maintainability. And maintainable software tends to be more efficient, cheaper to run, and easier to change. We value them because our heads hurt less when we have to modify smaller, focused functions rather than long ones. We value them because we sleep easier when the chance that our changes will cause a bug is smaller.

Taste in UI is not dissimilar.

We appreciate natural-feeling animations because they make an application feel like a physical product. A spring animation feels like pressing a real button on a keyboard with physical resistance and feedback.

Contrast makes for good readability. Symmetry and scale create order.

Taste is the qualities you are continuously exposed to.

Known is easy.

Easy is better.

When we find the patterns that work for our environment, we write and talk about them. We repeat them. This continuous exposure establishes taste (both good and bad).

But it creates a chicken-and-egg problem.

You need taste to recognize good work, but to build taste you need to get exposed to good work in the first place.

Yes, someone with more experience could give you a head start, but think about all these people who saw microservices as the pinnacle of architectural taste and put them to use at pre-PMF startups just because that’s the only way to build software they had seen.

To have good taste, you need to eat.

Read code, but not the prototype you generated with Cursor. Look at open source software with high integrity that doesn’t accept drive-by PRs en masse. Look at interfaces that people use every day without hiccups. Not the ones on Dribbble. They’re portfolio material. The software you use every day doesn’t look like this.

You don’t build taste through books and courses, but from real-world examples.

I always find it hard to tell recruiters about my background.

Many of them expect a straightforward reply containing no more than a couple of languages and a two-digit years-of-experience count.

So you’re a JavaScript developer?
Well, yes, but not exactly...
You’re a front-end developer?
Well, I currently build UIs, but I’ve also worked with Kafka
What position are you applying for again?

My career path looks like the worst possible implementation of the shortest-path algorithm.

I take detours, I go sightseeing, sometimes I get way too focused on the path, and sometimes I forget there’s even a path in the first place. So while a friend of mine can say he’s been a Java developer for the last decade, I have to kick off every intro call with:

It all started in the long winter of 2014

And the reason I’m the bane of recruiters around the world is that I’m constantly torn between beauty and challenge.

It’s obvious why challenging work is important.

It’s interesting, it’s fulfilling, it gives you bragging rights, it’s well-paid, and it has better job security.

I don’t need to tell you more than that.

Beauty is different.

You can have all the things above without your work having the abstract quality we call beauty. It requires effort to create and taste to appreciate it. Most importantly, it doesn’t guarantee you a higher salary.

Beauty is a cruel mistress, and I blame her for my inability to follow a linear, boring path into middle management.

But the underlying reason is soviet architecture (bear with me).

Why I need beauty in my work

I was born and raised in post-communist Bulgaria, where for half a century people prioritized utility over aesthetics. There are enormous neighborhoods made up of tall grey squares (the infamous panelka buildings) where the only important quality was their ability to stand upright.

Windows were a bonus.

And since the law allows people to manage their part of the building property as they see fit, they painted, insulated, and developed them without any thought for consistency or aesthetics.

Every building like this is a monument to misunderstood individualism and a counter-example for beauty.

When my eyes first felt the pleasure of seeing the colourful, consistent, playful architecture of modern buildings, I decided I needed more of that in my life. Not architecture per se, but beauty, aesthetics.

A long career of detours

My career has been a constant attempt to balance beauty and challenge.

I started off looking for beauty and applied for a front-end internship in a design studio, but on my first day, they told me I’d need to focus on back-end instead.

So I spent the first few years watching beauty from the sidelines.

When I finally got to do front-end full-time in 2017, it was amazing. I got to work on a design system and build beautiful pages while others sweat on configuring Zookeeper correctly.

It’s the kind of work that requires focus, study, and precision, but it’s not difficult in the traditional sense.

I can’t describe it.

It’s just as hard, but it doesn’t fire up the puzzle-solving part of my brain enough, and when it’s idle for too long, I get the itch to use it like I need a stretch after a long sleep.

Then, in 2019, I overcorrected.

I got a job writing CI pipelines and setting up cloud infrastructure, writing more VCL and YAML than JavaScript. Absolutely no beauty in sight there, and for some reason, I had little need of it for 4 years.

Looking back, it’s insane that they gave me a shot at infra without previous experience, but that company believed that engineers shouldn’t be siloed in disciplines, and I took the chance to un-silo myself from front-end work as quickly as possible.

Whenever I had a yin-yang episode and needed beauty, I’d spend time on software design, design patterns, and maintainability practices to put some beauty in the logical work, to sneak some art into the science.

But all in all, I was careermaxxing like a madman at that time.

My tunnel vision on challenging work turned into a speedrun into engineering management, and there I felt like I was in the Soviet-era neighborhood again - all utility, no beauty.

In 2023, I noped out of management and got a job as an individual contributor focused mostly on front-end work.

Where I’m finding challenge and beauty now

That’s a long way to say I find way too many things interesting and can’t focus on one of them for more than 3-4 years.

Lately, LLMs have turned my reward system inside out, and that doesn’t help either.

They have put difficulty, logic, and beauty all together into the blender, and I’m not sure if the result tastes good. There’s more difficulty everywhere, beauty is less commercially appreciated, and the sense of fulfillment lives in smaller corners of the work.

One positive development is that the people who actually appreciate beauty long for it so much more when everyone is drowning in mass-produced software.

I’ve identified web animations with Motion as an intersection of the Venn diagram between difficulty and beauty, and I’m spending disproportionate amounts of time on them right now.

Complex front-end work seems to be the cure.

But more on that in the follow-up article, I guess.

I used to get excited by major library releases like a child on Christmas morning. I’d open the docs and look at all the new APIs I could use like a new Lego set. A new addition to the standard library, a new public function that saves you some writing, changes to the language’s type system.

I’d be all over them.

I haven’t felt like this in the last couple of years, though.

It’s all AI now.

It’s all about the latest model, and every announcement sounds like an Apple keynote. It’s always the best model yet. It outperforms the previous one by an order of magnitude, and reduces the amount of code we write even more.

I wish I could get excited about such news.

I really do.

But they’re just not concrete products.

Software that relied on the models in the early days now has exposure to the complex agentic architecture that powers it. It’s no longer one model anymore, but an entire system.

So the concept of a product is quite fluid in frontier models.

Anthropic makes a tweak, and suddenly it starts underperforming in some areas. They make another, and it gets better. They can hinder specific use cases like model training (just read a blog post about this).

we’ve implemented new interventions that limit Claude’s effectiveness for requests targeting frontier LLM development (for example, on building pretraining pipelines, distributed training infrastructure, or ML accelerator design). Using Claude to develop competing models already violates our Terms of Service, but enforcing this restriction through our safeguards avoids accelerating the actors most willing to violate these terms. Unlike our interventions for cybersecurity, biology and chemistry, and distillation attempts, these safeguards will not be visible to the user. Fable 5 will not fall back to a different model. Instead, the safeguards will limit effectiveness through methods such as prompt modification, steering vectors, or parameter-efficient fine-tuning (PEFT).

So you can intentionally get a worse version of the tool you’re using without any versioning, API change, or even cost change.

I’m not excited about this because I don’t own it.

I can’t package it in my build.

It’s an unversioned external dependency that changes under my feet.

But it’s hard to follow other tools because the development in models has a far greater impact on my work than a JavaScript library.

Code generation impacts my productivity and maintainability more than a new API or framework. It’s becoming even more sensible to stick to popular tools that LLMs are already trained on, which makes me even less incentivized to follow small new libraries.

Never thought I’d become the conservative one in this industry.

New APIs and tools mean problems with code generation. It means that I can’t correctly review the agent’s code quality. It means that I don’t know the correct patterns to use.

It means change.

And things have been changing so much lately that I long for a little stability and boredom.

This article is a part of a long series on distributed systems fundamentals:

• Introduction to distributed systems

• Scaling

• Latency

• CAP theorem

• Consensus protocols

I found my old collection of Terry Pratchett books last week. I used to buy them for a couple of euros each in high school, and through fantastical satire, they were my first encounter with many real-world problems and ideas.

“Thief of Time” was my favorite.

It’s about inter-dimensional beings who find the world too messy, so they try to stop time to put everything in order once and for all. At 17 years old, I didn’t know how messy time can be, and I didn’t understand the antagonists’ obsession with it.

Now at 32, after working in tech for a decade, I do wish I could stop time.

Clocks

Any article, book, or paper on distributed systems starts with three pieces of information:

1. The system works concurrently on multiple nodes

2. They communicate over an unreliable network

3. There’s no shared clock

I found this last one confusing at first.

In the real world, time flows in one direction. This happens, then that happens. Two things can’t happen at the same time, and they can’t happen out of order.

But in a distributed system, every service is its own universe with its own time.

Services may live on different machines, and their clocks can drift from one another. Any attempt to perfectly synchronize them would be futile because they communicate over a network that takes an arbitrary time to deliver messages.

This wouldn’t matter if we were running a monolith on a single EC2 instance, but at scale, one machine is rarely enough to serve a whole product. The moment we add more machines to our system, we add more clocks, and any attempt to order events based on physical time would not work.

Why?

Clocks lie

You’ve got two people editing the same document.

One person makes an edit, it goes to service A, and gets written. After that, the other person makes an edit, and it goes to service B. However, service B’s clock is running behind, so the system thinks this is an old edit and doesn’t accept it.

In the real world, these events happened one after another.

But the clocks can make them feel out of order.

If we rely on clocks, the one that’s running the fastest always wins, and there are numerous edge cases like this one.

We don’t need time to create order

Time matters because it tells us what happened after what.

We don’t necessarily care about the exact millisecond something happened, but how it fits into the sequence of events and actions. Leslie Lamport, whom I’ve already written about in the previous article, concluded that we need logical clocks, not physical ones

We can use a counter that shows how events relate to one another.

A counter can track the version of each entry, so if the clocks drift or the network distorts the order of messages, we still know if we’re receiving an old entry version or the latest one.

• If the entry’s counter is at version 6, and we receive a smaller number, we know this is an old request.

• If we receive a higher version, we accept it because it moves the entry forward.

At this point, we know that distributed systems are an endless exercise in edge case handling, and while this helps us catch some problems, it doesn’t work out of the box for all of them.

Concurrent requests

Imagine that we accept a clock that bumps an entry to version 6, but then we get another request that wants to update it to the same version.

Clocks alone cannot solve this.

They help us figure out sequencing, but some requests can still happen concurrently. Two people may attempt to update the same entity at roughly the same time, without their clients having the chance to sync the data.

How we solve this problem is a business decision.

• We can say that the latest write wins. But this means that one client may lose their entry without notice.

• We can decline and ask them to reload the data and make a new update.

• We can decline the request, tell the client there’s a conflict, and ask them to merge both changes.

To cover more complex merge and sequencing scenarios, we can use more complex logical clocks - vector clocks or Cockroach DB’s hybrid logical clocks.

Vector clocks store the exact chain of versions that led to the latest update, so if the business requires you to merge conflicting versions, you can do that. If you recognize that two update requests share a common history, the unlucky client whose request came in second can merge them the same way they resolve a git conflict.

Clocks live with the data

One misconception I had when I first read about clocks was where they live.

If every replica needs to keep its own logical clock as an in-memory state, they’d need to be synchronized, which introduces the network again, and that wouldn’t work. And it wouldn’t be just one because you most probably work with many entries, so you’d need to keep all of them. Do this enough times, and you’ve reinvented a distributed database.

So every entry keeps its own logical clock that lives in storage.

It can be a version column, for example. When we update an entry, we first check whether we’re updating it against the current or a higher version. If not, we use one of the policies we outlined above.

This is where all the “there’s a new version of this file“ messages come from.

I even got this error on Substack as I’m writing this:

It’s hard to hold a normal technical conversation about AI.

It’s either dooming or worshipping. The doomers think the worshippers are bad software engineers, and the worshippers think the doomers aren’t using the right harness or don’t have the right agentic skills.

Both sides refuse to listen to each other, but the worshippers seem to be more prevalent.

It’s the engineer’s obligation to walk the middle path. To be able to see the technological marvel that LLMs are, but think about the second and third-order effects of their application.

That’s where true virtue is.

I came across this talk yesterday, and I found it refreshing. It’s a level-headed take about how the industry is changing, devoid of hype, cynicism, or praise.

It’s an engineer’s take.

This is how I expect people to think about technology. This talk raises the question of whether companies can withstand an order-of-magnitude increase in code output:

• You cannot produce so much code and rely on the same culture, strategy, and infrastructure that you currently have.

• Code is a liability. Every engineer knows this. Ten times more code means a tenfold increase in liability.

• Do we have the documentation to teach our agents the caveats about our domain and systems? How are we going to review their work at scale?

• An increase in the code output means more pipeline runs, more tests, more resources, more merges, and more deployments. Do we have the infrastructure for that? Do we have the culture to support it?

• Producing orders of magnitude more code will force us to rely more and more on end-to-end tests. How happy are you with your e2e test suite?

• How are we going to ensure security at such a scale? What precautions do we have to take?

• The DORA State of AI study shows that teams with good engineering fundamentals get the most benefit out of AI, while in others, it just amplifies their lack of understanding. What knowledge are we investing in?

All interesting points to think about.

I’m not half the developer that Mitchell Hashimoto or Adam Bender is, but when I see the bright minds of our field saying that fundamentals matter, I tend to listen.

No one knows where the field is headed and how we will be building software in twenty years. In the 2000s, we were shipping software on CD-ROMs, and they’re non-existent now.

But I do know that I need to have a good answer to the questions above.

For the past year, my dog and I have been writing a book in secret. One hour every single morning, and we're finally done. I haven’t mentioned it to my friends, not even to my mom.

I wanted to write The Creative Act, but for programming.

The Pragmatic Programmer, but with a more philosophical tone.

A Ryan Holiday-esque technical book you can turn a few pages from every morning.

An equivalent to Seneca’s letters to Lucilius, but from me to an imaginary friend in tech.

This is how I came up with The Thinking Builder.

It contains 60 short letters (300-500 words) about the habits of good builders in the age of thinking machines.

I intentionally use the word builder as a catch-all term for all the developers, designers, and founders who are finding their way.

It’s not a guide.

It’s the things I’ve noticed the good builders around me do.

And my dog and I would love it if you give it a read ❤️

Links

• The Thinking Builder Website

• The Thinking Builder Gumroad

Letters from the book

Beware, this is a weird book… I have used a very specific phrasing that you don’t see in technical texts.

It’s definitely not to everyone’s taste.

To get a feel of my writing in this book, here are three of my favorite letters from the book. If you like them, you will like the rest.

1. The Thinking Builder Strives to Be Good, Not Great

They know they may be above average on a good day, but they want to be more. They want to be better. They are the person who cares too much about what they do.

Being exceptional at any craft is a result of many forces, some of which are outside our control. Our environment, our timing, our upbringing, the people we happen to meet, the problems we happen to encounter - these shape greatness as much as talent or effort do. We can do everything right and still not reach it.

But we can control the work we put in, the care we bring to it, and the standards we hold ourselves to.

The thinking builder knows they cannot be great and have a life at the same time. Exceptional results demand a long-term commitment that often turns building from a profession into a lifestyle. Builders who want to be great sacrifice relationships, health, and the colors of life itself. They give up other hobbies and pursuits to tunnel vision on one specific craft.

There is nothing wrong with that choice, but it is not the only one worth making.

The builders with families, the builders with busy evenings, the builders who have aspirations outside their work - the engineers, the designers, and the founders who love their craft but cannot spend every waking moment in front of a screen - they may not sit among the greats, but they can become good builders who make the world better through their work.

There is immense fulfillment in being good, even if it is only a stepping stone to greatness. Even if one decides they’re ready to work for greatness, they must first become good. No one skips this step.

Good is not a consolation prize. Competence, care, professionalism, and completeness are virtues worth pursuing.

Building software is a form of building interactive art. Practical interactive art. With enough time in the software industry we forget what a marvel it is to be able to create something from nothing, from an empty file to a script that works for you. The builder can use their skills in every job, field, and industry to make their life better.

In fact, more people are building than ever before. The digital world is wide open. Engineers and designers are no longer the sorcerer gatekeepers they once were. The barrier to creating something has never been lower. But the barrier to creating something good has never changed.

Good still requires judgment, taste, and the willingness to think beyond the first solution that works. Good means the software does not just function but solves a problem. The design does not just look beautiful but guides the user.

Not everyone can be great, but anyone can be good.

The Thinking Builder Knows That Priority Is Binary

Something either matters right now, or it does not. There is no middle ground. There is no “low priority.” There is high priority and there is nothing.

Organizations love granularity. Five levels of priority. Color-coded labels. Matrices with axes for urgency and impact. These systems feel productive because they give every item a place. But giving something a place is not the same as making a decision about it.

It seems so logical.

Builders can work on tasks in order of priority. Start with what is urgent, then go down the backlog. If something more urgent appears, they can return to it and pick up “low priority” tasks during downtime - a holiday code freeze, a slow sprint.

Labeling a task “low priority” feels like a decision. It is not. It is a way to avoid making one. It is a polite way of saying “we do not want to say no, but we do not want to do it either.”

The task sits in the backlog, gathering dust, while the product moves on without it. By the time someone revisits it, the world has changed enough that the task no longer makes sense. It was never going to get done, but no one had the courage to admit that at the time. Low priority is where scope creep goes to live quietly.

Open your backlog and find those low priority tasks that have been sitting there for months. How many are still relevant? How many are still needed?

Backlog pruning sessions exist precisely for this - to surface the tasks that were never really needed.

The good builder would rather hear “no” than “low priority.” A “no” is honest. It frees you to focus. A “low priority” is a false promise that clutters the mind and the board alike. Priority is not just a matter of what label we put on the task. An honest backlog enforces discipline and clear thinking - we can’t keep adding future work endlessly.

The thinking builder knows that the high priority label is a dangerous tool as well. Once everything is urgent, then nothing is. Priorities work only if urgency is applied with care and only when needed.

Products are not built like puzzles. They are built like paintings. There are layers, and the parts are connected to the whole. When you treat development as a conveyor belt of independent tasks - each one ranked and queued - you lose sight of that whole.

It shows in the implementation. Tech debt accumulates. Architecture becomes a matter of chance rather than intent. It shows in the design. Screens feel stitched together rather than planned.

That is what “low priority” does to a product.

The good builder knows that some things take precedence over others.

But everything else is equal.

The Thinking Builder Does Not Need the Room to Notice

The industry has built a whole mythology around the builders who give talks, ship side projects, rack up followers, and turn their job title into a personal brand.

We have confused broadcasting with building.

Jimmy Iovine once said that the number one reason music is not as good anymore is that musicians want to be famous, not great. And now you can get famous without being great.

The same disease runs through software.

There are builders who optimize for recognition. They work on things people can see, they articulate their impact loudly, they know how to perform the role. They are not frauds - they produce real work. But they value applause more than good work.

And then there are the quiet builders.

They fixed the thing that was silently breaking for months before anyone noticed. They wrote the documentation that helped their junior colleagues get onboarded. They absorbed the chaos of a hard quarter so the team could keep moving. These things often don’t make it to the performance review.

The quiet builders may fix a performance problem when they have a free afternoon just because they know it is right to do so. Their work will slip by unnoticed while everyone reaps its benefits. The loud builder, on the other hand, will wait until the next all-hands meeting to present their solution and market it as a massive improvement regardless of how small the fix was.

Career ladders were not built to see the quiet builders.

Silently preventing a crisis will not give us recognition. Solving a crisis once it arises will. The quiet builder fixes problems before they become projects, which means the project never exists, which means there is no evidence of their contribution.

We never notice the best software we have ever used. Good technology becomes invisible because it solves a problem so well that using it feels natural. We never stop to think about the people who built it.

The builder may occasionally participate in performance theater to reap the rewards of their work. But they do not let it take focus away from the act of building, because that produces better work than any amount of self-promotion ever could. They want to be distinguished, but they do not yearn for fame. There is a difference between the two.

If a quiet builder becomes a manager, they learn to notice the other quiet ones. They take care of these people because they understand that those steering the ship are too busy to take credit for their work.

The thinking builder has made peace with this. They know their work will speak for them. Maybe not today, maybe not to the people who decide their salary, but to the people who depend on what they have made, and to the engineers who will one day open their code and find it clean and considerate and honest.

That is enough.

Links

• The Thinking Builder Website

• The Thinking Builder Gumroad

Subscribe now

Early in the vibe coding boom, founders claimed that their 10x-ers are shelling out 10K+ lines of code per day. Enormous amounts of logic by all means, even if half of it is boilerplate, schemas, and markdown.

Agents are a typewriter on steroids, but I kept wondering how these people reviewed all their work.

Most of us don’t work on pacemakers or rockets, so failure isn’t the end of the world, but it’s still detrimental. You still need to be able to make sense of what’s going on inside these 10K lines of code, right? They’re not a black box, right?

Wrong.

People were reviewing it like the required reading for literature class - a quick diagonal glance to get the gist in case anyone asks. I admit, I tried it too. But I quickly went back to shipping at the speed of my understanding.

Reviewing is the bottleneck

If I measure my productivity by the speed at which I get code into the IDE, then I’ve become significantly more productive. If I use voice instead of writing, I can shortcut this even more.

But if I measure it by how often I ship actual code, it’s marginal.

I’m still the bottleneck.

But the selling point of LLMs is shipping quickly, iterating, answering requests, and addressing feedback faster. However, if I need to review their code, I still ship at the speed of my understanding, and I simply can’t improve that tenfold.

When LLMs do software design

Models are great at outputting code that looks well-designed. It has abstractions, structure, comments even. But there’s a non-zero chance that they leave a logical flaw somewhere under that beauty, and without a good review, I won’t catch it.

The Broken by Default paper (published last month) claims that 55% of LLM-generated code contains at least one vulnerability. Machines propagate the same mistakes we do, and they still need the reviews we give to humans.

Their code can be so good at times that I feel awkward reviewing it.

But I’ve already found myself sitting on a design problem I didn’t catch because I didn’t pay attention, and this matters for software that can’t trade correctness for iteration speed.

At least the parts of the software that can’t do that trade.

Even companies working on highly available systems have internal applications that are prime targets for experimentation and coding agent freedom.

But it seems irresponsible to ship code to humans without validating it, and some of the people in this industry I admire the most are researching ways to solve this through formal verification.

Formal verification

If we have to review the code the LLM generates, then we’re not getting the maximum possible productivity improvement. We’re becoming more efficient, but we’re not raising the level of abstraction.

I first saw this mentioned by Leslie Lamport while researching his Paxos consensus algorithm. But when I came across the “AI will make formal verification“ article by Martin Kleppmann, I thought I should pay more attention

I did not study computer science in university, so I’ve never had to prove theorems.

But with languages like Lean 4, we can turn our algorithms into theorems that we can prove formally and verify that the code behaves as expected. The only problem is that writing the proof takes as much effort, if not more, than writing the code itself.

Because of that, it’s been largely contained in academia.

But on an abstract level, writing a proof that’s detached from the implementation sounds like a good way to validate LLM code without going through it.

In practice, I’m not sure how it would happen for actual application code with all its side effects. Also, will a formal proof be easier to review than the code itself? What if you can write them in natural language?

But every sufficiently detailed spec is a form of programming, isn’t it?

Automated formal verification

On a theoretical level, something like formal verification sounds reasonable. But, at least with the current tooling, it doesn’t seem applicable to how commercial software is built.

AlphaVersus is a project that aims to automate this.

“While LLMs have shown great promise in generating code, ensuring the correctness of generated code remains a significant challenge. Bugs and vulnerabilities can have serious consequences. Formal verification offers mathematical guarantees of correctness but is hindered by data scarcity and proof complexity.”

But if the model makes a logical flaw in the implementation, how can we trust that it doesn’t work around it in the proof as well? Will reviewing a formal proof be easier than reviewing the code?

Cost

I never liked the idea of having a paid tool in the core of my software development workflow.

“What, you don’t have $20?”

That’s what people told me.

But we’re slowly seeing the real cost of AI as prices rise. Teams are burning through thousands of dollars per month. Yes, a startup with three engineers can afford to throw money at Anthropic to make their prototype faster, but a corporation with a few hundred engineers will get their CFO sweating very quickly.

I’ve worked at companies that took down the dev cluster at 5pm to save money, and now we have spending leaderboards that are widely celebrated as a proxy for productivity.

I’m not an economist, but without a breakthrough in the models, they will only get more expensive, which means that reviewing and polishing will be even more important. When you can’t just throw everything at Claude and you need to be more selective, you need to understand the codebase.

But doesn’t this make us the bottleneck once again?

Finding beauty in software is easier when it’s visual - that’s the sense we use the most.

Before we touch anything, before we hear it, we see it. The eye is surprisingly well-trained at recognizing what has good aesthetic qualities.

But in places where the visual aspect is not dominant, or doesn’t exist at all, recognizing beauty takes more than intuitive taste.

There’s nothing less visual than a distributed system, a set of computers attempting to act coherently. The diagrams we make to illustrate such systems are the closest we can get to a visual representation of them, but even they are just abstract projections.

These services don’t exist. They’re not ordered like they are in the diagrams we draw on whiteboards.

What is beauty when it comes to processes?

What’s elegance when it comes to network communication?

Subscribe now

Consensus protocols

Distributed systems need to behave like a single organism, and a prerequisite for that is the ability to agree on things like the shape of the data that lives in a database’s replicas.

Consensus is easier to achieve if your means of communication are reliable.

But these systems communicate over an inherently unreliable network, which creates opportunities for data to diverge.

Consensus protocols create rules that help services to communicate and agree on things, even if some of them lag or contradict each other. While many developers told me that Paxos shouldn’t be the first protocol I start reading about, I decided to look for beauty in it.

The part-time parliament

I had heard about the notorious “The Part-Time Parliament” paper before, but never read it myself. I knew it wasn’t the typical academic paper, and the archeological immersion starts from the first sentence.

This submission was recently discovered behind a filing cabinet in the TOCS editorial office. Despite its age, the editor-in-chief felt that it was worth publishing.

It’s a (fictional) story about how the (real) island of Paxos is governed, but it’s so convincingly written that I had to double-check if it’s actually true.

Early in this millennium, the Aegean island of Paxos was a thriving mercantile center. Wealth led to political sophistication, and the Paxons replaced their ancient theocracy with a parliamentary form of government. But trade came before civic duty, and no one in Paxos was willingto devote his life to Parliament

The paper was originally written in 1989, but it wasn’t considered serious enough because of its narrative style, so it took a decade for it to get published.

It’s quite an unusual approach for a computer science paper.

Much of the wisdom we have as a species we pass down through stories and fables, but the academic world usually sticks to more formal language that’s not widely accessible.

The first requirement of the parliamentary protocol was the consistency of ledgers, meaning that no two ledgers could contain contradictory information. If legislator Φισ∂ ρ had the entry 132: Lamps must use only olive oil in his ledger, then no other legislator’s ledger could have a different entry for decree 132.

This writing style allowed Lamport to be precise in the things he wanted to highlight and remain vague where he didn’t. A technical spec would’ve forced him to write out everything.

Writing about a lost civilization allowed me to eliminate uninteresting details and indicate generalizations by saying that some details of the parliamentary protocol had been lost. To carry the image further, I gave a few lectures in the persona of an Indiana-Jones-style archaeologist, replete with Stetson hat and hip flask.

I did something similar when I published Tao of React a few years ago. Many people asked me to show them a boilerplate, some repo with all my principles implemented in it.

But specifics steal from the abstract, and I still refuse to make one.

The narrative abstraction of “The Part-Time Parliament“ is beautifully written. It’s incredibly immersive. But you need to map everything Lamport describes to a computer concept.

I was trying to think of examples with every word I read, and it is a bit difficult.

A messenger could be counted on not to garble messages, but he might forget that he had already delivered a message, and deliver it again. Like the legislators they served, messengers devoted only part of their time to parliamentary duties. A messenger might leave the Chamber to conduct some business—perhaps taking a six-month voyage—before delivering a message. He might even leave forever, in which case the message would never be delivered.

I understand what this means, but I have to jump a few mental hoops to get there.

A few years later, Lamport finally succumbed to industry pressure and wrote a version of his paper called “Paxos Made Simple”, which focused entirely on the algorithm and removed the narrative layer.

I got tired of everyone saying how difficult it was to understand the Paxos algorithm, published in [122]. Although people got so hung up in the pseudo-Greek names that they found the paper hard to understand, the algorithm itself is very simple…The current version is 13 pages long, and contains no formula more complicated than n1 > n2.

This is how the paragraph about messaging which I mentioned before sounds without the Greek narrative:

Messages can take arbitrarily long to be delivered, can be duplicated, and can be lost, but they are not corrupted.

Yeah, it’s much simpler.

Apparently, Dijkstra’s “Dining Philosophers” concurrency problem has been an inspiration for Lamport, but Dijkstra’s scope in this problem is more limited, and you need to do less mental mapping when you’re reading.

Paxos’ narrative style just quickly gets out of hand:

After receiving a LastVote(b, v) message from every priest in some majority set Q, priest p initiates a new ballot with number b, quorum Q, and decree d, where d is chosen to satisfy B3. He then records the ballot in the back of his ledger and sends a BeginBallot(b, d) message to every priest in Q.

Once you’re familiar with the algorithm, you can follow through, but again, you need to map every term. I take into account that I’m a bit denser than the intended audience for this work, but if it took a decade to accept it, there might be something to it.

One touch I appreciated is how he added multiple proofs with different parameters for his quorum algorithm, almost as if it were a unit test suite:

Paxos made even simpler

If we strip down the Greek flavor, Paxos comes down to three roles that any service in a distributed system can play (and they can play multiple at the same time):

• Proposers - suggest a value

• Acceptors - vote on values

• Learners - learn what value was chosen

And a simplistic summary of how it works would be:

1. A proposer picks a value and sends a prepare message to a majority of acceptors. Since two majorities have at least one overlapping member, this means that if we can reach a majority quorum, we can’t have contradictions.

2. Each acceptor responds whether they agree with that value or they’ve already agreed to a different one. If the acceptor has agreed to something different, they respond with the value they’ve agreed to (this is how services that lag behind learn what they’ve missed).

3. If the proposer receives a different value from an acceptor instead of an accept message, they propagate that value.

4. The proposer then sends an accept message to a majority of acceptors, and once each of them commits the value, it is chosen.

The clever thing (and the part that confused me the most) was that if a value was already chosen, any new proposer would discover it when they suggested a new value.

Since they will send accept messages to a majority, at least one of them will have accepted the new value already.

Paxos successors

Historically, Paxos has served as more of an inspiration than a ready-made solution.

Lamport left many engineering decisions open, and different systems answered them differently (Google Chubby, Zookeeper). Two products can be built on a foundation inspired by Paxos, but they can differ greatly in their implementation and be incompatible.

In practice, services need to agree on a sequence of values, not a single one.

There are Multi-Paxos algorithms that build on top of Paxos to support this, and they introduce optimizations like skipping the proposal step if there’s an elected leader.

Raft is another consensus protocol, created by Diego Ongaro and John Ousterhout - the same Ousterhout who wrote “A Philosophy of Software Design”, a book I greatly admire.

At the time of this writing, I haven’t read the Raft paper, but from what I understand, it reduces the complexity by relying on a strong leader and introducing well-defined leader election mechanisms.

In contrast to Paxos, Raft is focused on being understandable.

Even the paper is called “In Search of an Understandable Consensus Algorithm”.

Beauty

These are the stories I love in tech.

After reading excerpts from the Paxos paper, digging through explanations and examples, I’m convinced that this is one of those problems where you can’t have a simple explanation.

The problem is just too complex.

But Lamport made it fun.

There are many moving pieces, many things that could go wrong. It’s an area of computer science that warrants its complexity.

But Lamport’s paper is elegant. It shows mastery. It shows that the author cared about presentation, not just the idea. The paper itself is an interface to the underlying idea.

Raft has what you’d call a serious paper.

It’s not fun, it doesn’t have Greek names or a narrative structure. It has diagrams, bullet points, and empirical studies. It’s a feat of engineering knowledge, but it’s not the kind of paper I’d tell my friends about over coffee.

I tell them about Paxos, though.

People told me not to start with Paxos, but I’m glad I did.

It showed me that the interface matters to people working in distributed systems, too.

I’m in the middle of a thirty-day sabbatical away from work. A full calendar month without programming - something I never thought I’d need.

I feel exhausted.

I had planned to take this break later in the year, when the days were longer and the weather a bit better. But I was too tired to wait. I couldn’t get through a full workday without falling asleep.

I thought that twelve years of programming had caught up to me, but it was more than that.

I think I’m experiencing what some people are calling AI fatigue.

How I used to work

In the past, when I had a challenging feature or a hard architectural problem, the process was clear. I’d sit down, make a cup of coffee, read the documentation, and tunnel-vision into the problem.

Deep focus.

One thing at a time.

If the problem was big enough, I’d sleep on it and let the background process in my mind do its work. That’s how I’ve always operated.

I loved those afternoons where I had a big, gnarly problem ahead of me and no idea how I’d solve it - researching, reading, trying one approach until it failed, then trying another. I’d lose all track of time. The whole afternoon would pass just like that. I’d forcefully pull myself away from the computer to have dinner.

The threshold for problems that can suck me in like this is so high now.

How I (try) to work

AI finds solutions more quickly than I can keep up.

That space where I used to lose myself, that deep exploratory space, has shrunk almost to nothing.

Here’s the problem. Here are the constraints. Here’s what I think.

And just like that, I have a solution to review.

Is it good enough?

Hard to say because I haven’t gotten to it on my own.

I have the input and the output, but I haven’t spent enough time in the in-between.

It’s very difficult for me to keep a deep understanding of codebases (without losing my mind) with the speed at which they get created now. AI can design a solution more quickly than I can understand it and think about the trade-offs and future needs.

I try to be the reviewer, the manager, the DJ.

But surface-level understanding is not enough to build good software. If I don’t want to be the bottleneck, I need to review quickly, but reading is not reviewing. To review properly, I need intense focus, and that, combined with the speed of AI output, is exhausting.

Why don’t I slow down?

Honestly, the industry peer pressure got to me.

Everyone is talking about how quickly they’re building things, how many agents they’re using at the same time, and how much time they’re saving.

I feel like if I’m working at a regular speed, I’m not doing enough.

And this is probably true to an extent.

Coding agents are a time-saver, no doubt about that.

But when I tried juggling three agents at once - one updating dependencies, one working on an easier task, and discussing a more complex feature with another - my mind felt like mincemeat.

I’m not sure if I can train myself to do this all the time.

Maybe if it’s the only mentally-intensive task I do the whole day, but I have other things I want to focus on after I close the laptop. I want to read challenging books, write these articles, explore art and science.

Adapting

How much longer do I have in the industry if performing at the top level requires both intensity and higher speed?

I don’t know.

But the fact that I’m asking this question at all says something.

I don’t think I’m wired for this, but I think I can adapt. Maybe if I have a large mental library of solutions and architectures, I can recognize patterns and good solutions more easily? If I can do the mentally-taxing part upfront?

Maybe not knowing what I want from the start is the problem?

But every domain is so special and different. Every business has its own peculiar problems that you can’t find in a public repository to learn in advance.

These are questions to think about after my sabbatical.

There’s nothing I want more from my career than the chance to create beautiful things (and get compensated adequately).

But to create beauty, I first need the taste for it.

Unfortunately, this is not something I was born with. I don’t have the innate ability to know the perfect border radius, so I had to learn to notice it. The more beauty you notice, the more your eye develops. That’s the advice I got from my designer friends (and Interface Craft).

I started with what I could see.

Learning to notice visual beauty is easier because the eye is the first thing to make contact with the world.

And I realized just how desensitized I had become to the wonders of technology. I go through the workday, and the beautiful interfaces blend in the background. Just like you don’t notice the pretty sunset on your commute home.

How to notice the sunset?

Look at the software you use every day.

Do you like how it looks?

How it feels?

Ask yourself why.

“Because the UI is good” is not an answer. Be more specific. “Because it uses shadcn” is not a good one either. What exactly do you like?

Why do you like this font? Is it the subtle way the lowercase “l” curves? Do you like how they use both serif and non-serif fonts?

Why do you like the colors? What feeling do they give you? Do they fit together well? Does the UI feel like it has enough spacing?

Then look beyond the screen.

Notice the label on the coffee bag, the typography on a clothing tag, and the arrangement of the actors on a movie poster.

Just stop and notice. That’s all there is to it.

Then you’ll start noticing the products that lack beauty. The ones whose fonts you don’t like. The ones whose colors don’t work well together. You’ll start noticing the places where your work lacks beauty.

There’s no course you can take, no book you can read.

One morning, you’ll wake up, and your neurons will be wired just right.

Color

Color was always a mystery to me, partly because my eyes mix up green and grey.

I was fascinated by how designers find the right combinations. Somehow, they know where to place each color so it looks balanced.

I’ve tried using color palettes in my work, but my UIs looked like blankets stitched together from whatever scraps were left in the drawer.

So I decided to notice.

I spent time looking at every application I opened, every website, every label, every billboard.

Colorful patterns

I noticed that most good-looking software is built on a neutral base color.

A white or black variation that doesn’t strain the eyes. A subtle, slightly warm or cool color (also called off-white or off-black because it’s slightly different) that you can use as a canvas.

There’s always an accent color.

Something that pops out on the neutral base and complements it. It’s used sparingly and draws attention because it appears so rarely. If you use your accent color everywhere, the human eye won’t know where to look.

Then there are a few complementary colors that add depth. They’re often variations of the neutral base or something that works well with it. They’re used for the headers of a card component, a sidebar, or elements that don’t need to be accented but distinguished from the others.

A practical rule that falls out of all this theory is the 60-30-10 principle.

Sixty percent of your palette is the dominant neutral.

Thirty percent is a secondary color, used for surfaces, sections, and supporting elements.

Ten percent is the accent.

The ratio is simple. Following it gives even an untrained eye a structure to work within. But how do you pick these colors?

Newton’s color wheel

There’s a whole discipline around what colors go well together.

Between calculus and gravity, Isaac Newton invented the color wheel. He organized colors by their relationship to each other, and the placement of a color relative to others determines whether they harmonize or fight.

Just how much more could Newton have invented had he not dabbled in alchemy?

Based on what we know about the wheel, we can combine the colors to create a palette. This showed me why I subconsciously used monochromatic palettes in the past.

You can’t get color combinations wrong if you rely on variations of a single color.

So it’s not just noticing after all?

The things you piece together will turn out to have a term for them. But this is not a sign that you can skip the difficult part about learning to notice and training the eye.

It just shows that you’re on the right track.

“Ethics and aesthetics are one and the same.”
— Wittgenstein

“If you crush a cockroach, you’re a hero. If you crush a beautiful butterfly, you’re a villain. Morals have aesthetic criteria.”
— Nietzsche

For some reason I can’t quite understand, I keep going back to front-end development. I wrote some Go for a couple of years, then I went back to UIs. I did some cloud and infrastructure work, then went back to React.

Other fields are better organized, their communities are less fragmented, they’ve got better tooling and fewer problems with dependencies.

But there’s something satisfying in rounded corners and box shadows.

There’s beauty in it.

A theorem can be beautiful, an algorithm can be beautiful, a system can be beautifully designed, a database schema can be done so well it gives a sense of beauty. But that’s abstract.

Visual aesthetic is something you don’t need to be an engineer to appreciate.

It speaks to the caveman in me who stares at a drawing on the stone wall after a long day of chasing mammoths.

What exactly is beauty?

Christopher Alexander called it the quality without a name. Paul Graham tried to formulate the different qualities that contribute to beauty.

It’s a combination of qualities that pleases the aesthetic senses.

The spoken language remains too poor to explain it.

They say that beauty is in the eye of the beholder, but we’re all looking for the same features. We know how to recognize it. We value symmetry, proportions, clarity. We know how to recognize it.

It sounds subjective, but it isn’t.

We know when it’s missing. We know when something feels designed but isn’t.

To say that beauty is entirely subjective is to

Recognizing beauty requires taste

They say that beauty is in the eye of the beholder.

No, that’s just how developed one’s taste is.

Taste means your neurons are wired so that they fire when you see beauty.

Rick Rubin talks about taste a lot.

But the topic has entered the mainstream lately because of AI.

When development speed is accelerating, and you’re prototyping twice as fast, having a beautiful end goal is the difference between people marvelling at your work and calling it slop.

In the past, I never allowed myself to chase beauty.

I chased employment, I chased a promotion, I chased productivity.

You’d see software, and you’d see great software. Teams knew that building great software was out of reach for them because it required the technical time to implement it and taste.

Iterating to make something great just took too long.

And as a side effect, people couldn’t improve their taste.

But in the year 2026, chasing productivity and trying to build more of the same okay software (only quickly) seems foolish. Trying to orchestrate agents like StarCraft armies to release more shovelware in the world is absurd.

The thing to chase is beauty and taste.

I’ve never been a part of a world-class engineering team. I’ve never worked at a FAANG company. We knew we couldn’t create beauty.

We mostly settled.

We did our best with the knowledge we had and attributed our shortcomings to resources and time.

But time isn’t an excuse anymore.

I go through my work, I look at other people’s work, and it still lacks aesthetic. It was created more efficiently. People had more time to think about it. But it still lacks beauty.

I see the same level of work produced with less energy.

Creation itself is a virtue, but creating beauty is a higher one.

“Can beauty be just a skill in a markdown file that you load to your agent?”

It might be.

But until we can formulate it clearly using spoken language, you still have to rely on your own neural network.

The bottleneck

We argue about the bottleneck in software engineering.

Is it writing code? Thinking about structure and abstractions? Is it reviewing code?

It just might be taste.

You will waste hours and tokens if you don’t know what good code or a good UI is.

Taste is now a competitive advantage in a way it never was before.

Being the IT support of the family, I’m on call 24/7 to help with forgotten passwords, printers, online payments, bad UIs, and confusing error messages. A few weeks ago, I got paged because my mom had a problem with a web app she has to use at work.

“Hmm, when I create a new document and it says there are 6, but when I open the page there are only 5”

So she immediately clicks the button to create a document again.

“Wait a moment, this might be eventually consistent. Can you refresh again?”

And there it is. The document’s there.

“Why does this happen? Is it because my computer’s slow?”

The law of leaky abstractions doesn’t apply only to code, but to systems too, and because this product didn’t hide its architectural decisions well enough, I had to talk about consistency with my mom.

For the engineers and product people, prioritizing availability over consistency was an easy trade-off. But for anyone outside of their social circle, this behavior can be utterly confusing.

Why we need trade-offs

Up to a certain level of scale (organizational or technical), you can run everything on a single machine, but scale naturally leads to distribution.

I’ve written another article about that, so I won’t go into details here.

Increasing the number of REST API replicas may not be good enough if all your requests end up in the same underlying database. If your bottleneck isn’t in the processing, serving all your users from the same store, which is bound to a specific geographical region, isn’t optimal.

Some of your users will consistently experience higher latency than others because their data will have to travel longer or because the database got winded.

So, again, this leads to distribution.

We can create read replicas of our storage in different regions and serve data from multiple sources instead of one.

For the sake of simplicity, imagine that each replica can hold a copy of the entire database.

Write requests will go to the leader replica (also called the master in older resources), and they then get replicated to the read replicas. The traffic is split between them, and the latency is low.

But this replication needs to happen over an inherently unreliable network.

So the communication is bound to fail at some point.

Network problems aren’t frequent enough to cause constant disruptions because that would make any distributed system unusable, but they’re bound to happen. When they do, for a short period of time, one part of our system will become separated from the others. Our leader replica won’t be able to communicate with the followers and replicate data.

This is what we call a network partition.

Not to be mistaken with partitioning a database. When DBAs talk about partitions, they mean splitting data across multiple nodes for performance or storage reasons.

Writing data that can’t be replicated

The leader receives a request, commits the write, but then the network blips, and it can’t send that data to its replica. Both nodes are up and running, but the communication between them has failed.

And the moment this happens, the data in the read replica becomes stale. It doesn’t have the latest data.

Now, we’re forced to pick between two bad truths.

• We can keep serving read requests from the read replica (which is stale). Our application will continue to work, but some users will see old data.

• We can refuse to serve reads from the read replica until it can talk to the leader again. We avoid returning stale data, but for some users, our application will randomly stop working.

This is the fundamental trade-off in distributed systems.

We cannot always have the latest data and be available to return a response.

We have to pick one.

Engineers working on financial software would most likely prefer consistency because in their domain, the correctness of every digit is crucial. Those working on social media feeds would favor availability because the exact number of likes on a post isn’t that important.

The CAP theorem

In July 2000, Eric Brewer gave a keynote called “Towards Robust Distributed Systems”, introducing the CAP theorem.

At that time, I was still in kindergarten, the internet was a very different place, and downloading a song took a full day.

Brewer’s personal webpage looks just like you’d expect from someone with an enormous impact on the industry. When you see unstyled HTML, you know the person is for real. I’m not that good of an engineer, so I still need to write CSS for my blog.

In 2002, Seth Gilbert and Nancy Lynch published a formal proof of Brewer’s idea.

This paper is important for the software engineering field because it establishes the CAP trade-off as a theorem. It described this fundamental idea that many developers would’ve had to tackle on their own as the scale of software increased.

Brewer described the fundamental qualities of distributed systems:

• Consistency. Every read request receives a response indicating success and reflecting the value of the most recent write request or a response indicating failure.

• Availability. Every read request receives a response indicating success (not necessarily reflecting the value of the most recent write request).

• Partition Tolerance. The system continues to work when parts of it become unreachable due to network failures.

But because of the problem we described earlier, we cannot have all three at the same time.

We can only pick two.

If this is the case, can’t we decide to be both consistent and available?

While the CAP trade-off is frequently cited as a “pick 2 of 3” problem, we always need partition tolerance (P). If your application can’t handle network failures, it will only work until the first packet loss.

Partitions will happen.

So we have only two possible choices when we’re making this trade-off.

Our system can be:

• AP - available, but shows stale data when the network fails.

• CP - shows the latest data but occasionally stops responding.

These words don’t mean what you think

For the last 20 years, the CAP trade-off has cemented as a fundamental idea that anyone dabbling in distributed systems needs to be familiar with. But despite the focus on it, the terminology has been a source of confusion (at least to me).

It uses familiar terms with a different meaning than the one I was used to.

We already mentioned that the term partitioning has two separate meanings, but the same goes for consistency and availability.

CAP-Consistency ≠ ACID Consistency

When you hear “consistency”, you might think of the C in ACID - ensuring transactions move the database from one valid state to another.

CAP-consistency means linearizability.

“If operation B started after operation A successfully completed, then operation B must see the the system in the same state as it was on completion of operation A, or a newer state.”

Every read should return the most recent write. CAP-consistency is about the order of operations, not about transaction validity.

CAP-Availability ≠ High Availability

When we define a system as highly available, we usually mean that it’s up and running 99.9% of the time, or that it has failover and redundancy.

CAP-availability means that every request to a non-failing node must receive a response.

It doesn’t matter how fast the response is, whether it returns the latest data, or whether your system meets an SLA. A system can be “unavailable” in CAP terms while still meeting a 99.99% uptime SLA.

Single-Leader Replication

Databases are often described as CP or AP.

They’re either consistent or available. Single leader setups (like Postgres) are often cited as being CP. You will have one primary node (the leader) that will accept writes, and one or more read-only replicas (followers) that will copy these changes.

The leader sends a WAL (Write-Ahead Log) that describes the way the data needs to be mutated to reach the same state.

This WAL is sent to the replicas, and when they acknowledge it, the write is committed, and the data becomes available. So, no matter what replica future requests are handled, all of them have the same data.

And if there’s a network partition, you can decline writes.

But there are nuances.

This setup uses synchronous replication, but it can be configured to be done asynchronously. When the leader receives the request, they immediately commit it, and the replication is done in the background.

A follower may be a little behind, but it can still handle requests.

In the asynchronous replication case, our system will not be CAP-consistent (not linearizable), but it will be available.

This was one source of confusion to me. After I’ve read databases described as CP or AP, I found it confusing that they can be both. Even Martin Kleppmann believes that we shouldn’t describe them using these abbreviations.

Other Replication Philosophies

To get a better understanding of these trade-offs it’s worth looking into alternative replication philosophies. While single-leader databases make CAP-consistency more easily achievable (or at least more intuitive), multi-leader databases lean more towards the other side of the trade-off, CAP-availability.

DynamoDB is one such database.

It’s a database running on multiple nodes, and each piece of data is replicated on a few of them (but not all). When we write to Dynamo, the write goes to a quorum of replicas. There isn’t a single entrypoint that initiates the replication. Any of the replicas that have the data can do it.

While these nodes sync, they will continue serving read requests, so some of them may return stale data while the updated data gets to them.

When we say stale data, this sounds like they’d be serving your old documents for a couple of days, but in reality, the inconsistency window is very brief.

Dynamo favors availability and offers what we call eventual consistency.

Sooner or later, all nodes will have the latest data, but if your request comes before they sync, they will give you whatever they have at the current point in time.

But much like single-leader databases can do asynchronous replication, Dynamo can be configured to offer stronger consistency guarantees.

“It depends on your settings. If you accept a single replica for reads and writes (R=W=1), they are indeed CAP-available. However, if you require quorum reads and writes (R+W>N), and you have a network partition, clients on the minority side of the partition cannot reach a quorum, so quorum operations are not CAP-available (at least temporarily, until the database sets up additional replicas on the minority side).”

I’d love to write in detail about how eventual consistent systems sync data, but I don’t understand it well enough myself.

The CAP Spectrum

The more I read about these trade-offs, the more I see the wisdom in Kleppmann’s words. Labeling databases as CP or AP is an overly simplistic way to think about them.

Consistency and availability (in the context of CAP) are a spectrum.

“Even Eric Brewer admits that CAP is misleading and oversimplified. In 2000, it was meant to start a discussion about trade-offs in distributed data systems, and it did that very well. It wasn’t intended to be a breakthrough formal result, nor was it meant to be a rigorous classification scheme for data systems. 15 years later, we now have a much greater range of tools with different consistency and fault-tolerance models to choose from. CAP has served its purpose, and now it’s time to move on.”

The examples with Postgres and Dynamo show how both can offer various levels of consistency based on their configuration, and the same goes for other databases.

Amazon’s SimpleDB can provide both consistent and eventually consistent reads. If you want strong consistency, you will, however, experience higher read latency and a reduction in read throughput.

“In the research community over the past thirty years, a number of consistency models have been proposed for distributed and replicated systems. These offer consistency guarantees that lie somewhere in between strong consistency and eventual consistency. For example, a system might guarantee that a client sees data that is no more than 5 minutes out-of-date or that a client always observes the results of its own writes. Actually, some consistency models are even weaker than eventual consistency, but those I ignore as being less-than-useful.”

Some engineers go as far as challenging whether CAP is still a useful way to think about distributed systems nowadays, but I believe that it absolutely is.

It’s the fundamental idea that all these tools are built around.

PACELC

Whether we prioritize consistency or availability has consequences beyond network partitions.

If we want strong consistency, even when the system is working normally, latency will be higher because synchronous replication requires more time, and coordination between the nodes will make operations slower.

So it’s important to consider how these trade-offs affect a system even when there is no network partition.

The PACELC design principle is an extension of the CAP theorem that goes into these trade-offs.

“PACELC states that in case of network partitioning (P) in a distributed computer system, one has to choose between availability (A) and consistency (C) (as per the CAP theorem), but else (E), even when the system is running normally in the absence of partitions, one has to choose between latency (L) and loss of consistency (C).”

So, during a network partition, you need to choose between consistency and availability. But when there’s no partition, you need to choose between availability and high latency.

You’re constantly tuning how much consistency you’re willing to trade for how much availability and latency.

Again, engineers working on banking software would prefer consistency even at the cost of higher latency in normal conditions. And those working on user-facing products prefer higher throughput.

What this means for me

The truth is that I’ve never had to implement these trade-offs myself.

I’d love to get the chance to do this in a large-scale production environment one day when my nervous system can once again handle the pressure of working on such software.

But the reality is that I’ll probably never have to implement a consensus algorithm myself.

These trade-offs are put under beautiful YAML-controlled abstractions or hidden behind the magic of the cloud provider.

But you still need to make educated decisions when you’re building software and picking technologies. When your application scales and your architecture is getting distributed, you need to know how far you ned to lean to each side of the spectrum.

“That’s why your document doesn’t appear immediately, mom.”

But it wasn’t complex software that was doing it. It was code written thousands of times already - websites, newsletter signup forms, payment integrations, and various CRUD apps.

The thing was that suddenly everyone needed such software.

So we brute-forced its development by putting more hands on keyboards.

Academia took 3-4 years to produce engineers and problem solvers, but the industry needed writers.

We needed people writing code, people who could find a solution that matched the problem and reproduce it, people who spoke the language of the CPU well enough to translate somewhat optimal instructions to it.

But, again, these problems have been solved numerous times by countless developers around the globe, and there’s not that much problem-solving to do, but researching and pattern matching.

I was a product of that time.

On a subconscious level, I realized that I was doing a subset of what real software engineering was fairly quickly.

There’s this exact moment that kicked off a chain of neurological events in my mind.

My colleagues were discussing how the services in a new project would communicate with each other, and when someone asked me what I thought, another colleague said:

“Pfft, Alex, doesn’t even know what a pointer is...”

And he was right.

I didn’t know what a pointer was.

I could write code, I could build applications, but I didn’t know this fundamental piece of knowledge you learn in CS 101.

I was a fucking code monkey.

My job was to scour the web for solutions for my problems, remember a few pieces of syntax, and produce them again and again on the assembly line.

I was building applications without knowing what a pointer was.

My work was that simple.

I was a cook in a fast food restaurant who had no idea how to make a proper meal, but knew how to follow a system. I was tossing already-flavored meat on the grill, defrosting soups, and seasoning salads with an off-the-shelf mix.

But I wanted to be more.

I wanted to talk about microservices named after Greek gods (as was the fashion of the time), module structure, load balancers, and API design.

In the last decade, I saw the industry promise thousands of people that it doesn’t care about logical principles, that the fundamentals were a waste of time, that they could memorize APIs, and specialize in a technology as a career.

But that was a false promise, and a lot of people are feeling it.

People have long mistaken writing code for building software, and the industry now needs builders.

I’ll be honest, I loved writing code.

Maybe I loved it a little bit too much.

For a long time, that was the outlet for my creative aspirations, and I’d find places to express myself even in the margins of very simple code.

But I’m rarely doing this anymore.

I don’t explore technologies and problems with the depth that made me fall in love with this craft. It’s so tempting to gloss over library APIs, ask the LLM to summarize them, make a couple of changes, ensure maintainability, avoid a bug, and ship.

This isn’t an existential write-up about job security.

It’s about meaning and fulfilment.

The act of orchestrating agents is too... managerial for me. I moved away from engineering management and went back to being an individual contributor, but it seems this was an illusion of free will.

All roads lead to the same place.

I was watching “The Bear” the other night, and one of the characters said something that stuck with me.

“You found something that you love and it’s completely okay if you don’t love it anymore. Because the most special part about it is that you were capable of that love.”

I really feel like I’ve been forcing myself to love programming lately.

Don’t get me wrong, it’s fun to build things, it’s nice to see your ideas come to life quicker, to have a never-ending source of debugging ideas, to see computers doing new things.

But a part of me feels like it’s back to being a code monkey, only differently.

Writing code by hand gave me the pace of thought I needed to understand a problem deeply. After a couple of years at a company, I knew the codebase by heart, every corner of it, every service, and every script.

I find it difficult to say the same thing now.

“If you’re thinking without writing, you’re only thinking you’re thinking.”
― Leslie Lamport

I’ll miss the days when the Tab button was used to add a tabulation, not to accept a Cursor suggestion.

In many cases, it just doesn’t make sense to write code by hand anymore.

Agents are faster, cheaper, and they let me try out more ideas before I settle on a solution. I make small changes by hand, and I write the code myself when it’s too specific to explain.

But when I’m kicking off a new feature, I scaffold it with an agent. I tell it what interfaces I need, what structure I’m expecting, and then I fill in the blanks.

This makes me feel like I’m working in someone else’s codebase, though.

So I’m taking solace in learning more about distributed systems, UX, and how to be more of an editor and less of a writer.

I’m looking for that sense of meaning and creative satisfaction in different places.

It’s not easy.

But one day I’ll be telling my younger colleagues how I wrote entire applications by hand.

“Kids these days don’t know what real work is.”
— Me, in the future

I’ll be insufferable.

Well, in the year 2026, AI has finally become a dev tool.

The promise of it replacing your engineering team remained unfulfilled (at least for now), and coding agents seem to work best in the hands of someone who speaks the language of the machine.

What happened?

All the defensiveness that engineers had about AI evaporated as soon as models became better. All the complaints, all the bitterness, are slowly disappearing. Once you reduce the time people spend fixing a model’s mistakes, they’d happily use it.

I don’t know if it’s emergent abilities, parameter tuning, larger data sets, or some agentic wizardry, but models like Claude Opus 4.5 feel significantly better than previous ones.

I don’t have the benchmarks, I don’t have a qualitative proof, but the temperature of the room feels different.

There’s less pessimism and more curiosity.

But as AI becomes a dev tool, engineers start treating it as one.

We try to min-max its usage like any other technology.

What’s the best workflow? What’s the best prompt? Is Claude Code marginally better than Cursor? How do you do TDD now? Should you review your code with AI? Can you now build software from your phone?

I find these questions largely insignificant, though.

The AI landscape seems to be changing far too often for them to have a meaningful answer. Last year, people were obsessing over adding the right context to the coding agent. Now it just figures it out on its own through a combination of human-like searches (like grep).

If we get too fixated on a model’s ability to one-shot a request, we miss the real question, which is what exactly you’re trying to one-shot.

You can get so focused on doing the cool thing that you forget that the goal is to build good software.

But what does good software look like?

What is good UI? AI is great at making something that looks designed but feels off to a real person. I need to learn what a good interface looks like.

What qualities does a good system have? I need to be better at understanding what underlying qualities a system needs to have to match the product I’m building.

What does maintainability look like in the future? At some point, you won’t be starting from scratch every morning. The services need to keep running.

And these questions are answered with fundamental software engineering knowledge.

Greenfield and brownfield development are fundamentally different. Once you need the system to keep running and pay the bills, you need to be a little bit more careful, and while UIs get fixed with a browser refresh, the same isn’t true for data.

You need to get used to these tools, but they remain as such.

Knowledge about how good software needs to behave is non-negotiable.

Maybe I’m just coping a little bit, so I don’t feel like I’ve wasted thousands of hours thinking about the intricacies of software design and architecture only for the industry to slap an abstraction over it.

I’m still not 100% sold on code being a black box. I still can’t quite detach myself from the idea that I need to understand what is going on. I need to learn how to use these tools productively, but also keep myself grounded and familiar with their work.

I’ve read too much Asimov, so I’d rather be a step behind. When you’re on the bleeding edge of technology, it’s you who’s bleeding.

Where to?

Those with a more entrepreneurial spirit are having a blast. The inner Henry Ford must be speaking to them like the green goblin mask, telling them that the software assembly line is right there for the making.

But on the builder-trader spectrum, I’m still leaning too far into the former.

The bottom line is that someone still has to be the bridge between the analog world and the digital one, but Ira Glass’s gap has been greatly reduced in size.

“Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you.”
— Ira Glass

The skill you need to develop to match your taste is now less. How much less, I don’t know. But as the engineers at Anthropic are doing their magic, this gap is slowly shrinking.

And this makes the destination on its other side that much more important.

When I know what output I’m aiming for, things are easy. I know exactly what I expect, and I can ask the agent about the specific thing I need. The trouble comes when I don’t know what I want to achieve.

That’s when I need to rely on the model and hope its weights are in my favor.

I’ve learned to apply the age-old principle of abstraction in these scenarios. I put boundaries around the code that the model will generate. I put it in a separate file, a separate module, and create an interface around it.

Then I let the model go wild inside.

I can treat its output like a black box, but I make the box.

I need a better understanding of what I’m trying to make. I need to be able to recognize good designs, good architecture, and good software.

Otherwise, I’d just be putting more shovelware out into the world.

And while I believe that creating anything is a noble pursuit, I’ve given the world my fair share of shitty software, so I’d much rather contribute to something more meaningful.

If code becomes less and less of a bottleneck, then design becomes the next frontier, both system design and user interface design.

I want to get better at recognizing when a UI looks good.

I want to know what it lacks, how it needs to be structured, and what needs to be removed. A designer friend of mine recommended the Interaction Design Foundation for a more structured approach to studying UI/UX, and I’ve been liking it so far.

And I want to learn the same about larger, more complex systems, so I’m re-reading Designing Data-Intensive Applications for I don’t know which time (I should just keep it on my desk at this point), and I’m reading papers about distributed systems.

The second-order effects

The industry shift is not limited to the way we code.

Every change has second and third-order effects that are difficult to predict. One of them is that people seem less interested in low-level (if we can even call it that) programming educational content anymore.

I recently saw a post from an engineer and content creator who got laid off from Laracasts.

I guess it’s hard justifying spending money on learning something that Claude can one-shot for a fraction of the price.

Adam Wathan shared how Tailwind has been struggling, so he had to lay off 75% of his engineers as well.

Honestly, it leaves a bitter taste in your mouth to see some of the best developers out there struggle. Especially Adam, because Tailwind is the LLMs’ favorite way to write CSS.

But it’s difficult to monetize these tools when code reusability is not that much of a problem anymore, and people don’t even open the docs.

Personally, as someone who has self-published a few programming books, I can attest that I’ve heard fewer Gumroad sales notifications in the last 6 months.

Management and delegation

I stepped back from engineering management a few years ago because I was afraid that I was getting detached from programming.

I didn’t want to get rusty and become unable to code. But now this seems like an irrational fear. It may be possible to have your cake and eat it, too. When coding agents don’t require you to be that hands-on, retaining a good intuition about good software may be enough.

Jason Fried from Basecamp posted something that made me think.

This is certainly something I’m getting used to.

Not only are you delegating to total competency, but to someone who will follow your directions. It’s rare to make a technical request that doesn’t get questioned, dissected, or argued about. That’s our job at the end of the day.

But now I can ask for something specific and obscure, and actually get it.

Somehow related to that, Boris Cherny (the creator of Claude Code) posted about how he uses coding agents.

It seems like the best base for programming is not mathematics but Starcraft.

If you’re good at context switching, you can manage a whole economy of agents to build things. I don’t have the focus of a pro gamer, but I watch Serral playing Zerg from time to time for inspiration.

Where’s the speed?

While corporate software engineers are slowly feeling increased benefits from AI, it still feels like there are two Stranger Things-esque parallel dimensions between startups and corps.

Developers may be faster, but companies don’t move as quickly because they’re bottlenecked by processes - approvals, holidays, regulations, and budgets.

“Great progress. Let’s catch up next week and continue.”

You may be able to generate your code more quickly, but the company moves with the speed of the weekly sync.

Also, the more niche your work is, the less assistance coding agents can give you.

Go ask an engineer at SAP whether they feel the boost in productivity as they’re wrestling with their tailor-made highly scalable infrastructure and in-house programming language.

The uncomfortable truth is that once you can start working productively with a coding agent, it’s very hard to come back from heavily assisted development.

I can feel the tension in my programming-related braincells reducing with each prompt I send Claude, and some days I’m half-tempted to ask it to change a button’s color. But it’s unethical to contribute to melting the ice caps for a prototype.

Regardless, I will be doing my best to build good products.

“Don’t waste time thinking how to build good software. Build good software.”

Or whatever Marcus Aurelius said.

Growing up in Eastern Europe, the superhero culture was limited to mainstream characters. No one was translating comic books at the time, and they were nigh impossible to find, so you'd better hope you catch that early morning Spider-Man episode that airs when you’re getting ready for school.

When I played my pirated copy of Watchmen during the superhero movie boom, I expected a story that followed the formula I’d seen many times over. A villainous entrance by the bad guy, an initial defeat for the flawless heroes, only for them to return stronger and win in the end.

Watchmen’s nothing like this.

It gives a gritty twist to the superhero genre, and it was the first time I saw “superheroes” portrayed as imperfect beings with human flaws, needs, and personal agendas.

But Alan Moore didn’t create this story by accident.

Read Everything

Moore broke the formula because he knew it better than anyone else. He reinvented the superhero not because he ignored the genre’s history, but because he understood it well enough to twist it into something new.

And that was Alan Moore’s advice to future writers - read everything. Read the classics, poetry, philosophy, pulp, comics, newspapers, and obscure esoteric texts. Read good books, but read bad ones as well.

The bad ones, especially, are instrumental in forming your taste in writing.

“Read terrible books as well, because they can be more inspiring than the good books… By analyzing why they are doing so badly, this will immensely help your own style. You’ll find out all of the mistakes not to make.”

— Alan Moore

Writers read hundreds of books before they try to write their own.

We, as developers, on the other hand, take the equivalent of a grammar course and set off to write “War and Peace”. Imagine writers not reading the classics. Not pushing through “Moby Dick”, nor suffering with “Crime and Punishment”.

Nothing great will come out of such a writer. At most, a superhero story that follows the formula I outlined in the beginning.

Subscribe now

Programming is More Art Than Science

Paul Graham has this great essay called Hackers and Painters in which he argues that programming is closer to creative disciplines than to traditional engineering because our work is driven by taste, iteration, and intuition, not rigid processes.

Programmers refuse to accept that their work can be art, and artists struggle to acknowledge that their work is applied mathematics.

But if you read the essay and it manages to convince you even in the slightest, then we should take Alan Moore’s advice seriously and treat our improvement in this craft just like writers do.

“I don’t think there’s really any difference between art - or writing, or music - and magic. And I particularly draw the link between magic and writing. I think that they are profoundly connected.”

— Alan Moore

Good grammar is a prerequisite, but there’s more to writing a good story - plot, characters, voice. The same way, knowing a programming language is non-negotiable, but there’s more to building software - architecture, scale, maintainability.

Like artists, we build our intuition about good software through iteration, working on real, lived-in software, not isolated code snippets.

When I started writing, people told me I needed to read Camus, Dostoevsky, Chekhov, and Steinbeck, but no one told me the codebases I should read to see how people build.

Building Intuition

Most developers build their taste for good software naturally as they change companies - they see which patterns work and which don’t.

That’s why I still think years of experience somewhat matter.

The more time you spend in the industry, the more projects you get to see. You learn how their domains are modeled in the codebase, the challenges, and how real software looks.

You will see terrible failures and spaghettified codebases, but they, too, are important. Like pulp fiction and airport books whose endings you know before you open up the first page, the negative data points are just as valuable.

“There is no substitute for practical experience, and if you want to write about people you ought to put down that comic book and go out and meet some of them rather than studying the way that Stan Lee or Chris Claremont depict people.”

— Alan Moore

I find that developers who quickly become good at building software have unintentionally found a way to fast-track this learning experience and build their intuition.

Working on their own side projects, taking up freelance gigs, and contributing to open source - all these expose them to more domains, more collaboration problems, more obscure edge cases.

Reading Open Source

I had no trouble doing my 9-5, then coding until the AMs when I was 22, but now, with a family and responsibilities outside of work, I find it difficult to follow the same schedule.

I can’t continue building things in my spare time or moonlighting in a second company anymore. It’s too draining, and I’ve been dancing with burnout way too much.

But open source is a goldmine for good reading material, and I can enjoy going through projects like a good book. I don’t have to study them like a textbook, analyze them, or even run them. I can take in the codebase like I’d read a book in the morning.

Open source seemed daunting to me.

I felt unworthy of even reading it. Code that sits out there in the open to be reviewed by everyone must surely be complex and written with extreme care.

Yes, trying to read React’s codebase without prior knowledge will probably leave you more confused than enriched.

But think about all the small libraries and tools you use daily, the joints that keep the whole thing together.

I find that they’re very much worth reading.

Reading Lodash

The first open source library I gathered the courage to explore beyond the README was Lodash - a collection of utility functions that were invaluable in the past when the JS standard library was poorer.

I started with it because I hoped it would be simpler, but I didn’t expect that the entire library would be kept in a single JavaScript file that’s 17K lines long.

That’s a library with 80+ million downloads per week.

They don’t publish this enormous file, though. It will stretch out the network cable it travels through. The complexity in Lodash is in its build process. They have a CLI that mangles the file into different formats and builds.

In the industry, such a file would be considered a massive anti-pattern, and I never would’ve seen working software implemented this way.

Did I like it? No.

But I learned that what you deliver doesn’t have to be the same as the thing you write.

Reading React-Query

Some time later, I did the same with react-query, a popular data fetching library in the React ecosystem.

I wasn’t sure where to start with a large, complex, unfamiliar codebase, so I did what I do at work - I followed one of its public-facing APIs.

I found where their most widely used function was exported, and I followed its implementation all the way down, command-clicking through functions and layers until I reached the bottom.

And I found that it actually used classes underneath.

Yes, classes.

In a JavaScript library used on the front-end. Lightweight functional programming has been dominating the ecosystem for years, and object-oriented code was the last thing I expected.

Did I start using classes in my React projects? I didn’t.

But reading this codebase taught me that you can work with data outside of the React component lifecycle.

The Software Engineer’s Vocabulary

This is not the kind of knowledge that will help you pass FAANG interviews. It’s the kind that will help you build actual software.

If you don’t read, you won’t have a vocabulary to write with, and if you’re not studying real software, you won’t learn patterns to build with.

Engineering blogs are a great source of information, but I find them to be too curated. Every sterile, over-engineered REST API that has more boilerplate than domain logic has been inspired by a blog post.

Wins and breakthroughs are interesting to read about, but real software sometimes has 17K lines-long JS files that no one is eager to write about.

We study theoretical best-case scenarios and then expect to build actual production software based on ideas discussed in a vacuum. This is unrealistic. Software failures are most often a failure of imagination and our inability to handle complexity, and this imagination gets fostered as you read more and more.

Getting familiar with new ideas only when you change companies is the same as only reading a book every few years.

We need to constantly study existing projects until we understand the shape of quality and develop a taste for good software.

Because that taste is what lasts.