This is a quick update chronicling my journey with fonts in MonoGame. Like the XNA Framework before it, it comes with decently robust support for creating sprite fonts from .ttf files as part of its content pipeline. You can then use those fonts to render text to the display very easily.

However, also like XNA, it’s notorious for making those fonts look like absolute garbage - especially at lower resolutions.

The Problem with Stock SpriteFont

MonoGame’s SpriteFont has serious limitations. It makes several assumptions about how the font should be rasterized, and most of them can’t be disabled in the font’s definition file. It applies some pretty fuzzy anti-aliasing, and the smaller you try to render the font, the worse the effect gets. Take a look at this example:

I put this together using Roboto Medium at 12pt, rendered onto a 480x270 internal surface. (The actual display has been scaled up to 960x540.)

You’ll notice that it looks… wrong. Obviously it’s a competently rasterized font, but it almost looks like you’re reading it through a magnifying glass, or like it’s been scaled up using a non-integer method. Alas, no - that’s just how fonts look in MonoGame.

The sprite font configuration (an XML manifest in a .spritefont file) is very straightforward:

<?xml version="1.0" encoding="utf-8"?>
<XnaContent xmlns:Graphics="Microsoft.Xna.Framework.Content.Pipeline.Graphics">
    <Asset Type="Graphics:FontDescription">
        <FontName>Roboto-Medium.ttf</FontName>
        <Size>12</Size>
        <Spacing>0</Spacing>
        <UseKerning>true</UseKerning>
        <Style>Regular</Style>
        <CharacterRegions>
            <CharacterRegion>
                <Start>&#32;</Start>
                <End>&#126;</End>
            </CharacterRegion>
        </CharacterRegions>
    </Asset>
</XnaContent>

If you’re looking for additional properties to configure the font’s rasterization further… too bad. There aren’t any.

Now, if you’re rendering at higher resolutions, like 720p and up, the blurry effect is far less noticeable. In fact, smoothing might even be desirable at those scales; 12pt font isn’t actually very big on a 720p display. However, what if you don’t want any smoothing at all? What if you’re making a retro game where the chunky pixels are a feature?

Introducing Bitmap Fonts

I am, of course, not the first person to make this observation about MonoGame. Being a relatively well-loved and proven framework, tons of developers have identified common faults in MonoGame and its abandoned predecessor, and they’ve sought to correct them. One such improvement is the MonoGame.Extended library. It brings implementations for several common idioms, but most relevant to this discussion, it provides support and extensions for bitmap fonts.

So what is a BitmapFont as compared to a SpriteFont? Well, in both cases the font gets rasterized to a texture by a tool ahead of time. Then, to draw a string at runtime, portions of that texture are rendered to the screen, glyph by glyph, by the framework. It knows all the texture coordinates, character spacings, kerning pairs and so on. The most pertinent difference is that you have full control over how the texture gets produced for a BitmapFont, and the framework doesn’t do anything to the glyphs aside from render them to the display directly.

Sounds great! You just need to produce a font texture using some kind of tool and write nice, chunky text pixels to the screen… right?

Most Fonts Are Not Pixel Fonts

Yeah, about that. It turns out that the overwhelming majority of fonts are absolutely not meant to be rendered at low resolutions, and even then definitely not without some kind of smoothing. The documentation for MonoGame.Extended recommends an ancient tool called BMFont for rasterizing your font. In BMFont, you’re asked to provide the size of your font in pixels. I don’t know as much about computer font rendering as I should, but I do know that font “points” are not the same as pixels. Still, if you’re anything like me, you’ll experiment with a few different pixel sizes on your desired fonts. If you’re targeting low resolutions with a chunky pixel aesthetic, you might want your font to be somewhere between 8 and 12 pixels tall. Here’s what Arial looks like at 12px in BMFont’s preview:

And here’s what it looks like in-game:

At first glance, it’s not bad! It’s appropriately chunky and the fuzzy anti-aliasing is completely absent. Unfortunately, it falls apart when you start looking at the details. For example, look at the 0 (zero). It looks like a D. Note the strange spacing on the lowercase z and uppercase X. See how the * (asterisk) is garbled and missing the top prong? How the - (minus) character is too short? None of these flaws are acceptable for a “production” font. The smaller you go, the more garbled the font gets.

In fact, it turns out that going below 12px with almost every font I’ve tried produces completely illegible garbage. Here’s Arial again at 8px:

That’s not a squished image (I mean, probably not - I don’t know how you’re reading this). It’s just mangled. Unfortunately, it seems most fonts won’t work straight out of the box, even with BitmapFont.

Putting in the Work

Remember how I said that with a BitmapFont, you have full control over how the texture gets produced? For better or worse, it’s true. From here, you basically have two options to make a polished pixel font:

Modify the BMFont Output

If you followed the instructions in the MonoGame.Extended docs, BMFont produces two files. The first is a .fnt file whose format you specified in the Export Options. The second is a texture whose format was also specified there. MGE wants you to output the .fnt file as binary and the texture as .png. However, if you instead output the .fnt as XML, the MGE content pipeline extension can still parse it but you can also edit the output after it’s produced.

Combined with your ability to edit the .png file in an external editor, you can hand-correct the mistakes made by the BMFont rasterizer. It won’t be fun, though. BMFont packs the texture pretty tightly and out of order, and the .fnt file is dense and precise. Any changes you make will need to be painstakingly accounted for in the texture coordinates and offsets it produced for you. You can give yourself some space to work within by adding spacing between the characters in BMFont (in the Export Options), but you’ll still need to be meticulous about it.

Or…

Design Your Own Font

When you read through the XML .fnt file, you’ll realize that although the spec is dense, it’s not complicated. Here’s an excerpt from our Arial 12px font produced by BMFont earlier:

<?xml version="1.0"?>
<font>
  <info face="Arial" size="12" bold="0" italic="0" charset="" unicode="1" stretchH="100" smooth="0" aa="1" padding="0,0,0,0" spacing="1,1" outline="0"/>
  <common lineHeight="12" base="9" scaleW="256" scaleH="256" pages="1" packed="0" alphaChnl="4" redChnl="0" greenChnl="0" blueChnl="0"/>
  <pages>
    <page id="0" file="arial_12_0.png" />
  </pages>
  <chars count="191">
    <char id="32" x="197" y="26" width="3" height="1" xoffset="-1" yoffset="11" xadvance="3" page="0" chnl="15" />
    <char id="33" x="232" y="17" width="1" height="7" xoffset="1" yoffset="2" xadvance="3" page="0" chnl="15" />
    <char id="34" x="163" y="26" width="3" height="2" xoffset="0" yoffset="2" xadvance="3" page="0" chnl="15" />
    <char id="35" x="251" y="9" width="4" height="7" xoffset="0" yoffset="2" xadvance="5" page="0" chnl="15" />
    <!-- ... -->
  </chars>
  <kernings count="59">
    <kerning first="32" second="65" amount="-1" />
    <kerning first="121" second="46" amount="-1" />
    <!-- ... -->
  </kernings>
</font>

The <info> element contains metadata about the font. <common> has information about the font as a whole - lineHeight is how many pixels tall the font is, base is where the base line of the font falls within that line height, scaleW and scaleH are the size of the output texture, and so on.

The character definitions are even more straightforward.

• The id refers to the character’s integer Unicode representation (e.g. 32 is space, 33 is !, 34 is ", etc.) and the x/y coordinates are texture coordinates for this glyph.
• Combined with the width and height, this defines a rectangle for the glyph that will be used to render it to the display from the texture.
• I’m not entirely sure how the xoffset and yoffset work - presumably it offsets the character on the display by the given amounts when rendering - but you can configure BMFont to rasterize the font such that the offsets are always zero anyway.
• xadvance defines how many pixels to advance forward after rendering this character.
• page refers to which texture (defined in the <pages> section) this character comes from.
  • This is only important if you select a ton of characters for your font. Otherwise it’ll be 0.
• chnl has something to do with the RGBA layout of the characters as defined in BMFont (alongside the alphaChnl, redChnl, greenChnl, and blueChnl settings in the <common> element).
  • I didn’t bother to fully wrap my head around this, I just followed what BMFont did based on the presets I selected. You can apparently mask multiple characters into a texture by layering them in the RGB channels, but this was never pertinent for my use case.

With this knowledge in mind, it’s not complex to build your own font following this spec. You may not be able to pack the texture as optimally as BMFont (although you could always lean on a tool like TexturePacker to do it for you, if you need to optimize it), and you’ll definitely want to write a script or a tool to produce the XML .fnt file, but it’s pretty straightforward. You’re more-or-less just defining the texture regions for each glyph in your texture.

Drawing your own font isn’t as hard as you might imagine, depending on how complex you need it to be. You basically just need to draw characters in a grid onto a PNG file. A tool like Aseprite will make it quite simple, especially if you’re creating a monospaced font. Variable width fonts are more difficult, of course, and if you try to get the kerning right too, you’ll spend quite a lot of time tweaking it.

Now, if you’re making a text-heavy game, the font is one of the most important visual elements of your game. It’s worth putting the time in to get it right. If not, you can probably get away without kerning and with minimal tweaking. Either way, once you’ve got your font prototyped, it’s worth setting up a script to produce the XML automatically. You should absolutely test the font in a real scenario - rendered by the BitmapFont extensions in MGE - frequently to make sure your texture coordinates, offsets, and other settings are working properly.

Tricks and Workarounds

Personally, I have already drawn a few pixel fonts in PICO-8 and Picotron and I found that workflow to be better than drawing them in Aseprite. These low-resolution environments are perfect for building and testing a small pixel font since you can iterate and test basically instantly. As a proof-of-concept, I wrote a cart in Picotron to export fonts in BMFont format:

As far as I can tell, this is a pixel-perfect recreation of Picotron’s variable-width and mono fonts. If you want to see it in action, you can run load -u #picotron_bmfont_exporter. It exports the texture to the /desktop folder alongside the XML .fnt spec. (If you use this tool, make sure to remove the pod annotation from the top of the XML document when you take it outside of the fantasy environment.)

Going into detail on how to build fonts in Picotron or PICO-8 is outside the scope of this article, but thankfully it’s a well-documented and supported process (load #font_snippet in PICO-8 will get you started).

Alternatively, you can also find fonts which are designed to be rendered very small. This is obviously the path of least resistance. Several pixel font packs on itch.io, for example, come pre-rasterized and with XML specs already written.

Fonts are Hard

Turns out it’s not easy to get a pretty, well-formed pixel font appropriate for low resolutions. It takes some work, especially if you’re trying to go smaller than 12px. I imagine this explains some of the reasoning behind the trade-offs inherent to the stock SpriteFont: they might not be pretty, but they’re legible and very easy to create.

Thankfully, the tools are out there to make your perfect chunky pixel font look great. I hope this little journal helped you learn something new about fonts in MonoGame - it certainly took a bit of discovery for me to get the results I was looking for.

If you’re interested in picking up this adventure where I left off, one piece of software I never looked into was Font Forge. Supposedly, it gives you full control over the design and implementation of true-type fonts, so perhaps the most “complete” solution would be to build your font from the ground up as one which scales to any size. That way, if you need multiple font sizes in your game, you’re not stuck having to scale or re-draw your original font.

I wrote my first game when I was 12.

I had grown up on video games—my parents tell me I was playing Mario before I was 3 years old—and I always wanted to make my own. But, to make video games, I had to learn how they were made. My 12-year-old self managed to figure out that I needed to learn programming, and games were usually written in C++. So, naively, I assumed that if I could just learn C++, I could make games. My parents and I were at a bookstore one weekend and I spotted a book: Sam’s Teach Yourself C++ in 21 Days. “Wow,” I thought. “Just 21 days? I’ll be making games in no time!” I begged and pleaded for them to buy it for me, and after some discussion, they did.

I was lucky enough to grow up in a very technology-rich household, much to the chagrin of my parents’ credit ratings. They loved having hi-fi stereos, game consoles, and of course, multimedia PCs… whether they could afford them or not. But as a result, I had grown up surrounded by games: NES, SNES, Genesis, Playstation, and PC games. My dad was also particularly proficient (for the time) with this stuff, and he taught me how to play MUDs via Telnet. Eventually, he introduced me to EverQuest; it lit up my young brain like a Christmas tree.

So, 12-year-old me sat down in front of the computer with an outdated (even at the time) C++ book and started reading. I don’t know what the curriculum is today, but at my school in 2000, I had only just started learning algebra (and even then, only because I opted into an accelerated learning path). So when I first got started, I didn’t really even understand the concept of variables. Instead I did what most starting programmers used to do: I typed out all the examples and started tweaking them.

I noticed that all the examples in the book focused on text-based output. That wasn’t exactly what I wanted; where were the flashy graphics and explosions? But, since I had some experience with MUDs, I knew I could make a text-based RPG. I did all my editing in a DOS-based environment called DJGPP, because that’s what the book shipped with on the included CD. My code was probably one long int main() function full of the kind of cyclomatic complexity that would make your head explode.

Yet, there it was. After reading (parts of) the book and really committing to the task, I had debatably learned to program. It took longer than 21 days, that’s for sure, but I made my first game. It had an enemy that could attack you, you could attack it back, and the stats all worked. If you defeated the enemy, you got a little “congratulations” and then the program ended. That’s it. Baby’s first game.

Obsession

The itch to write more games hit me hard. I sent my game to all my friends, who undoubtedly never bothered unzipping it but told me it was cool anyway. Then, I started thinking about what comes next. I had grand plans in my mind of starting a game studio in my garage with my friends and acquaintances. Some of them played music, some of them drew, and some had expressed interest in level editors for games like Half-Life. It felt like we had all the ingredients.

My friends and I had LAN sleepovers where we’d play games, of course, but also have little game dev jams. I discovered DarkBASIC, a BASIC interpreter stapled onto a DirectX helper API, and it blew my mind. Not only was BASIC so much easier than C++, DarkBASIC had all these graphics and sound commands built in, and it even loaded Half-Life maps straight out of Hammer! All the pieces were there.

My friends and I put together several stupid little games over the next few years. We tried building an FPS, we did some experimenting with a Final Fantasy-style RPG, we had a trivia puzzle game, and we even started a Castlevania-style action platformer. This was an era before Unity, Unreal, or Godot had commoditized game toolkits. As the only programmer for most of these projects, I had to learn a lot. Game engines, realtime simulations, asset pipelines, data structures—as the games got more complex, my skills had to grow to accommodate.

I dabbled in OpenGL, DirectX, various open source game engines, and learned a little bit of 3D math to try and make it all make sense. I wrote code in BASIC, C, C++, C#, Lua, and probably more. We found copies of 3DS Max and Photoshop, discovered Blender, and tooled around with RPG Maker 2000. There was so much to explore, so much to learn, and so much time to spend on it. After all, we were relatively privileged teenagers. What else did we have to do? Schoolwork? Psh.

The Real World

All told, we probably started and worked on 15 different games over 6 years. We only really “finished” a few, and they were all messy hobby efforts full of copyrighted assets and bad ideas, but that’s how you forge a real skillset. You learn by doing new things… and we did a lot of new things.

By the time we graduated high school, I had become a legitimate programmer. Even for a couple years following, we kept going, getting more and more professional and developing our talents. I think if we’d managed to get better a little faster, take it a little more seriously, and make a few different decisions, we could’ve really achieved that dumb little childhood dream of starting a game studio in the garage.

Unfortunately, the real world is harsh to naivety. We all went off to college after high school, and our interests wavered as they had to compete with things like… you know, relationships, jobs, other hobbies, stuff like that. Suddenly we had responsibilities. I also hit a severe bout of depression for a few years which made it hard to do much of anything at all.

By the time I was 21, not even a decade after I started making games, I had stalled out. When I was 22, I decided it was time to “get a real job.” Until then, I had been going to college and working various part time jobs, splitting an apartment with my then-girlfriend (now wife). I considered getting a job in the game industry, but by 2010 it was widely known just how miserable the working conditions were. I made the painful decision to let game development remain a hobby and start a traditional IT career instead.

A Real Job

Never let it be said that I don’t commit. When I decided to get a “real job,” I went at it pretty hard. Thanks to my prior game programming experience (and some SQL fundamentals in college), I entered the industry as a Software Engineer II. From there I made my way up the ladder for 15 years, learning and growing along the way, until suddenly I found myself as a Senior Director of Engineering.

Being a professional engineer, leader, and mentor taught me more than I could possibly write here. I could fill a pretty fat book with the lessons I learned, decisions and mistakes I made, values I came to hold dear, and so on. The most important thing I took from it, though… is that I’m worthy of being a leader. Even as far back as my “garage game studio” days, I doubted whether I was the right person to lead such a thing. I never saw myself as a leader.

Even once I made my way into a career leadership position, I still didn’t see myself as a leader. I was just the guy who did what needed to be done, whether that was setting direction for a team to align with business goals or working out the architecture for a new project. It took a long time of gradual self-reflection for me to realize being a leader isn’t about any of that shit you read on LinkedIn. It’s about being trustworthy and responsible, about being decisive and knowledgeable, and about putting your team over yourself.

I’ve met too many so-called leaders who fail at this. Miserably.

Reflections

At time of writing, I recently lost my “real job.” Don’t worry, I’ll be fine - but for the first time in 15 years, all the noise and anxiety of my day job has gone quiet. I’ve finally had a chance to stop and think about that decision I made so long ago.

At various points since that decision, I’ve worked on games in my spare time. I still write down all my ideas. I’ve made multiple concerted efforts to spend nights and weekends on game projects, and while I don’t have much worth uploading here to my site, I constantly feel that itch in the back of my mind: make video games. It’s the one aspiration on which I’ve never really wavered.

Of course, tech evolves fast. To keep up with my career, I’ve had to devote many long nights and weekends to working late, being on call, or just keeping up with the latest advancements. I devoted so much of myself to my day job that, by the end of the day, my brain was empty and I didn’t want to sit in front of an IDE for another 4-6 hours. Hell, sometimes I just wanted to sit down and watch a movie with my wife.

Some particularly grind-minded individuals would probably call those excuses. Others would accuse me of not really enjoying game development, if I don’t feel like doing it after a 10 hour work day. I’m sure there’s some small amount of truth to those statements - that I could be more passionate - but like most gatekeepers, they hold everyone to an unreasonable standard to make themselves feel better. It’s reasonable to be human.

But what if now is the time?

The Exceptions Which Prove The Rule

If you haven’t already, you should read LocalThunk’s timeline of his development on Balatro. It tells story of a man who made games as a hobby for a long time, ended up quitting his job to work on his passion project, and found massive success.

Or how about the story of poncle (Luca Galante), developer of Vampire Survivors? A man who made games both as a hobby and professionally, ended up quitting his job to work on his passion project, and found massive success.

Go back far enough and you might even recall the story of Notch, and a little game called Minecraft. He turned out to be a real piece of garbage, but few can deny the wild success of his passion project. How did he make it happen? Well, he quit his job to work on it.

If you were starry-eyed enough, like me, you might read stories like these and think, “Wow, all I need to make it as an indie dev is a passion project, hard work, and some luck! I can do this!” You might even be correct, technically… but it’s not what you think. Here’s my estimated breakdown:

• 0.1% passion
• 0.2% hard work
• 99.7% luck

For every LocalThunk, poncle, and Notch, there are 1,000 aspiring indie developers whose games rot in the back catalog of Steam. Some of those games are trash, certainly, but some of them are fantastic gems. They just haven’t sold. No streamers have played their game yet. No publishers were interested in picking them up. Most of those games will fade into the ether, and their developers will end up back at their day jobs (or worse).

Balatro, Vampire Survivors, and Minecraft are exceptions which prove the rule: the indie game market is unimaginably overcrowded. Your chance of success in this market is almost zero. Are you financially dependent on your game being successful? Don’t become an indie dev. It’s more akin to playing the lottery than working a day job.

That’s the general guidance, anyway. Hell, even several successful indie developers have said the same thing. After reading this article about Slam Bolt Scrappers on Penny Arcade back in 2011, I reached out to the studio head, Eitan, for advice. He responded (props to him) and more-or-less told me exactly what I already knew, deep down.

I wouldn’t recommend quitting your day job unless you really have a game plan for it.

I only learned while doing research for this article that his studio, Fire Hose Games, ran out of money and went out of business last year. Their final game, Techtonica, has a Mixed rating on Steam. Their socials are silent… it appears they petered out unceremoniously.

I can’t say anything. I didn’t buy the game either.

Existential Conflict

The raging existential conflict which has agonized me for 15 years is this: you miss all the shots you don’t take, but it’s super risky to take the shot. I can never be successful if I don’t try, but it’s extraordinarily likely I won’t be successful even if I do. It’s gambling.

Am I willing to gamble away my livelihood for the chance to fulfill my childhood dream?

One of the recurring elements among all the stories I told earlier - LocalThunk, poncle, and even Notch - is that they worked on their games in their spare time. Nights and weekends, while working a day job, until some threshold was crossed where they began to see a legitimate chance of success. Eitan from Fire Hose warned me 14 years ago not to quit my day job.

Earlier I said that it’s reasonable to be human. Maybe, though, if I really want this so bad… it’s not. Perhaps, until I can find the energy and focus within myself to power through my day job for 8-10 hours and then stare at the IDE for another 4-6, I don’t have what it takes. Am I really “obsessed” with game development if I only want to work on it while my brain is fresh? Do I even deserve it?

I don’t know. I’ve never known, and it’s part of why I originally made the decision. It gnaws at me constantly.

So Now What?

A small peek behind the curtain: this article took me a long time to write. I decided to take a few weeks off work between jobs—my wife and I just moved 4,000 miles across the entire continent of North America and I wasn’t, originally, going to get a break to rest. Starting this article is one of the first things I did after we moved into our new place. Other posts have taken longer, but none have been so personal.

This has been my way of reminding myself why I decided, in 2010, to get into traditional IT instead of trying to be an indie game developer. It’s been me painfully navigating the same decision yet again. As a kid, all I ever wanted was to start a game studio with my friends and make games for a living. How naive and selfish.

Still, despite all the advice to the contrary, all the obvious signs that the industry is flooded, and all the common sense and risk assessment telling me it’s stupid, there’s a huge part of my inner self tied up in the desire to make games. To get something creative out there that people enjoy and leaves an impact on their lives in some way… that’s what drives me.

The tech industry right now is so far abstracted from making products people want to use. It’s all caught up in hype cycles and massive bubbles; meanwhile, the products we actually depend on day-to-day are rotting away or being hollowed out to make room for AI. I hate it. I just want to make cool things that make people happy.

I don’t yet know where I’m going to end up. Professionally and personally, it’s a time of major change for me at what might end up being one of the worst possible times in history to make major changes. All I know is that wherever I land, it’s going to be somewhere that I can meaningfully contribute to, and perhaps even lead, a product that actually impacts someone.

That’s all I want: to make a positive impact on the world, however small. Is that outmoded now? I guess I’ll find out. Check back here in a few months to see if I’m starting a GoFundMe to help pay my bills…

Like most software engineers in the futuristic year of 2025, I sometimes use LLMs like ChatGPT to help me write code. Especially for tedious, but well-solved problems like writing common regular expressions, I give my brain a break as a little treat. The LLM acts as a glorified search engine and strings together something which is good enough for what I need in the moment. It’s a win/win: I didn’t need to exert any real brain power, and the problem got solved. Really, that’s what software engineers are. We’re problem solvers. And the problem got solved.

Right?

… Right?

Yeah, you know where this is going.

(Edit 2025/07/30: I don’t usually edit my articles after the fact, but the previous version of this one contained a particularly vitriolic admonition of the start-up/venture capital game which probably wasn’t entirely fair. This new version tones down the bile a bit.)

What is Vibe Coding?

If you aren’t aware already, let me introduce you to an idea which has gained popularity lately: vibe coding. To summarize, it’s a term for when someone isn’t actually writing any code; they’re simply prompting an LLM to generate code for them based on a description of their intent. Then, they copy/paste that code into their editor and tweak stuff until it builds and produces the results they’re looking for. Repeat ad nauseum until the task is complete.

The vibe coder has completed their work without ever needing to engage the engineering part of their brain. They probably “produced” more lines of code in less time than another developer who wrote it all themselves. However, perhaps controversially, I’m going to argue that if you’re a professional developer, you need to stop solving problems and instead become a problem solver. Let’s talk about the difference.

First, we’re going into this conversation with a few assumptions. Most importantly, note that I specifically call out professional developers. A hobbyist or general user who needs a script or a custom application gets no judgement from me, no matter how they achieve their goals. This (one-way) conversation is between me and engineers working for companies, producing software on a daily basis. Presumably, that software is used by a customer or stakeholder of some sort to create value, and they are paid for their labor, making them a professional.

Another foundational principle here is the idea that software engineering is a discipline worthy of refinement. I don’t want to engage in this conversation with tech bros who lack respect for the trade which pays their bills. Those people are often incapable of having a good faith discussion on this topic because their fundamental philosophies do not align with long-term goals. Their objectives are usually very short-term, lack an overarching strategy, and originate from a mindset geared toward playing a very different game. It goes without saying that vibe coding is very popular with the sorts of people who see programming as a necessary evil on the path to getting bought by Amazon.

The Difference Between Solving Problems and Being a Problem Solver

You know who gets left in the dust when hype bubbles burst? You and I. Thankfully, we can pick ourselves back up, get back on the job market, and go apply our skills elsewhere as engineers—as problem solvers. Unless you’re not a problem solver.

Using an LLM to vibe code certainly takes more skill than browsing the internet. You’ve got to have some intuition on how programming might work, and enough sense to generally grok the syntax of whatever language you’re using. You need enough to make minor changes, at least. But don’t fool yourself. Software engineering, architecture, infrastructure, data science, etc. are all extraordinarily complex and nuanced fields. They’re packed full of decades of hard-learned lessons forged in the real pressure of projects where millions of dollars are at stake. Your own experience comes from passively absorbing the mentorship of your senior colleagues, making your own mistakes, active learning, contributing to projects, and slowly diamondizing.

The most important experience, though, is problem solving. It’s a mindset like a muscle, and you have to train it. Anyone can vibe code because everyone can more-or-less wrap their head around what a programmer does on the surface: write instructions to make a computer do something. The ability to proficiently solve complex problems—to break down confusing, nuanced, sparsely detailed, or misleading issues and turn them into achievable and actionable objectives—isn’t something an LLM can do for you. Your value as an engineer isn’t your ability to write code, it’s your ability to be a problem solver. You can only exercise the muscle if you use it.

Interestingly, you’ll find that being a problem solver is important in more than just programming. It’s a skill applicable to your entire life and across every career. Employers need problem solvers because someone has to figure out what to do when unexpected things happen. Science needs problem solvers to discover the undiscovered. The world needs problem solvers to navigate the unprecedented.

Vibe coding robs you of valuable problem solving experience, because you’re not solving any problems. The LLM is. In order to survive in this industry, you can’t be disposable. You need to be indispensable. You need to be a problem solver.

Prompts != Problems

I’ve had a couple of discussions very similar to this with colleagues and… let’s call them “industry pundits.” Frequently, there are two counterpoints to my perspective on vibe coding.

1. Good faith argument: successfully writing prompts to coerce the LLM into giving you the results you need is similar to writing code, and therefore contributes to one’s problem solving experience.
2. Bad faith argument: the tech industry is in a post-principle state; no one cares about any of this stuff anymore. The only thing that matters is slinging code well enough to get to the next round of funding, or to keep operations running, or whatever.

Let me be very grim and serious for a moment. We’re going to talk about #1 later, but anyone who tries to legitimately pitch #2 to me? They can fellate a firehose. Like so many of the problems plaguing the world at time of writing, the toxic idea that we’re in a post-discipline world is a dangerous lie. It comes from a) people actively invested in devaluing your skills to drive down their labor costs; b) grifters looking to maximize their short-term gains at the expense of overall customer satisfaction or long-term sustainability of the business; or c) hawkers looking to increase the perceived value of AI. The degradation of principles in the tech industry is directly correlated to the enshittification of the products and services it offers, which is itself inseparable from a market ruled by the FAANG-like goliaths terrified they can’t keep the financial line going up forever. I won’t be gaslit by these people, and neither should you.

We good? Okay. Let’s talk about prompts vs. problems.

Perhaps the biggest difference between solving a problem yourself and crafting a prompt is in how you engage your brain. Engineering is a declarative action. Compare it to building a bookshelf. You understand what the bookshelf should look like, what kinds of tools and supplies you need to build it, and—if you know what you’re doing—viable dimensions and construction methods that are likely to result in a stable piece of furniture. Then, you express your will upon the world directly by crafting the supplies, your knowledge, and the tools together to produce a bookshelf. You’ve exercised your spatial reasoning, planning, tool discipline and technique, and so on.

Engineering should be just like that: you know what the software needs to do, what sorts of platforms and languages are appropriate to express the requirements, and with experience, the design patterns and architectures that are likely to result in a stable piece of software. Then, you express your will upon the computer directly by crafting syntax, your knowledge, and infrastructure together to produce the application. You’ve exercised your problem solving, planning, architecture and design acumen, and so on.

Now imagine you’re trying to tell an LLM to build a bookshelf. What skills are you exercising? You’ll learn the particular quirks of that model and how to phrase prompts with enough detail that it understands what sort of bookshelf you’re looking for. Then, if you’re lucky, you end up with a bunch of mismatched prefab pieces that you have to assemble like you went dumpster diving at Ikea.

As I’ve already alluded to, if you’re a hobbyist and you just need a dang bookshelf, there’s nothing wrong with an Ikea bookshelf. But if you’re a professional furniture manufacturer and all you do is bash pieces of prefab furniture together and call it a product worthy of sale to a client? It doesn’t cut it. You’re scamming your customers, and you never learned how to actually build bookshelves. You don’t know how to plan for materials because the pieces were prefabricated, you can’t figure out how to fix problems because you don’t understand how they’re made, and you don’t have any tool discipline or technique so you’re highly likely to chop off your fingers trying to cut the wood.

(Before you take this all too literally and tell me that furniture companies source their prefab pieces from multiple manufacturers and resell them as a cohesive unit, yes. I understand that. However, someone had to understand how a bookshelf is made well enough to know that the pieces would fit together, look good together, where to source them from, how to forecast supply from their vendors to meet the demand for their downstream product, and so on. If you want to keep abusing the metaphor, though, and you think you’re the reseller instead of the manufacturer of the pieces, then try this. Pretend that you’re building a SaaS website. You don’t write your own database, web server, application framework, infrastructure framework, or any of that. But you still have to understand how to build your service’s bespoke value-generating logic and how to utilize those “prefab” components to do it.)

Who Are They?

If vibe coding is so detrimental and generates such poor problem solvers, you might be asking who are these so-called vibe coders then? Do they even exist, or are they just a figment of the imagination in the minds of AI tycoons? No, it’s indisputable that they exist. If you’re working in the industry today, chances are very good you know one or more of them.

Sometimes, they’re burnt out or distracted, but obviously need to keep their job. So they turn to LLMs as a way to keep producing code without having to engage. Other times, they agree with the (toxic) mindset that the only priority is churning out code without much regard to any of the principles or disciplines of engineering. You know, the stuff we worked for decades to figure out was absolutely necessary for the longevity of software.

The vibe coders that worry me the most, though, are the new developers entering the industry now. As an unregulated, uncertified discipline, software engineering is incredibly vulnerable to cargo cult practices and cynically-motivated fads. These newbies are getting fed all kinds of counterproductive codswallop by an industry that absolutely does not have their best interests in mind. One of the more public meta-voices of the tech industry, The Primeagen, reported on how the overreliance on LLMs is stripping junior developers of the critical foundational “muscle memory” they need to succeed.

Ten years ago, we used to accuse bad developers of just copy/pasting code from Stack Overflow. Vibe coders are a similar phenomenon, except now they’re not even getting exposed to the community interactions around those posts. But so long as IT remains a lucrative career, there will always be people looking to get in without doing the prerequisite work. Just like with Stack Overflow, LLMs are a crutch, and some people never get back on their own two feet.

Good Vibrations

Vibe coding doesn’t teach you to be a good programmer, engineer, teammate, or problem solver. It only teaches you how to be a good LLM-wrangler, and no one arguing in favor of vibe coding today is arguing that it generates quality code. They’re not even arguing that it’s easy; most vibe coders acknowledge that they have to spend a decent chunk of time fixing issues it creates. They’re only arguing that it’s good enough, and I think that’s demonstrably false. That doesn’t mean you should necessarily avoid LLMs wholesale. My point is that they should be just that: tools in your broad arsenal of problem solving strategies. At least for now, an LLM can’t be a problem solver, and you can’t be a problem solver if you rely too heavily on them.

I still have hope. There’s still time for us to influence new devs to engage with the principles of engineering. We can still hold ourselves accountable to being the best versions of ourselves. I also know that this “race to the bottom” era will end as soon as the consequences start piling up. Investing in yourself is never a bad investment; you’ll want to be primed for the rebound instead of lagging behind.

Perhaps most importantly, don’t betray yourself. Problem solving is as much a creative expression as it is a scientific one, and LLMs are still purely derivative. This is your advantage in the AI-obsessed industry we find ourselves part of today.

Nostalgia has a lot of haters. “Move on,” people say. “Things now are better than they were. You think you do [want old stuff], but you don’t. You’re just wearing rose-tinted glasses hiding the flaws of all those things you used to enjoy.” Kind of like obesity, it gets attributed to personal weakness or lack of discipline. Being nostalgic is childish, right? It’s a yearning for a time which has passed and for a world that no long exists.

Frankly, I can see their point. I don’t miss VHS tapes getting eaten by a screwy VCR, or having to wait for them to rewind. I don’t miss internet speeds measured in bits per second rather than megabits. I don’t miss the Cold War. I don’t miss the times when various diseases which are now curable were death sentences. Culture, society, science, technology—we’ve made so many amazing advancements in innumerable areas that we have the amazing luxury of getting to take for granted today.

And yet… it’s weird. I actually do miss the era before streaming video services had completely taken over and then fractured, leaving my ability to access media at the whims of Hollywood execs. I fondly recall that brief window before the Internet was a massive advertising duopoly transforming misinformation and anger into profit. I remember a time when politics weren’t entirely a red vs. blue clown show. Beyond all that, though, I kind of miss being bored—or perhaps I miss having to make the most out of my limited options.

The Argument for Nostalgia

I’m certain this is not a new idea—there are areas of academic study entirely dedicated to nostalgia—but I would wager that it’s not always an “overfondness of the past.” Instead, I posit that that nostalgia is frequently a manifestation of dissatisfaction with the state and direction of culture, entertainment, or even society itself.

Before we proceed, let me be clear on the term nostalgia in the context of this article. There are, to me, two definitions of nostalgia which refer to related, but slightly different, phenomena. First is in the same vein as déjà vu: a reflexive feeling one experiences circumstantially, evoking the wistful and sentimental aspects referenced in e.g. the Merriam-Webster definition of the word. In this post, however, I want to focus on something more specific: the desire to evoke that feeling intentionally.

As a feeling, nostalgia might seem unattractive. For many, it carries elements of melancholy and ennui. This is the dissatisfaction I alluded to earlier: contrasting how things were with how they are.

• “Star Wars used to be good, now it’s bad. I miss when it was good.”
• “Video games used to be full of secrets and fun stuff to unlock, now they’re all microtransactions and Skinner boxes. I miss when they were more straightforward.”
• “Politics used to be much more balanced and professional, now it’s a bunch of jokers appealing to the lowest common denominator. I miss when politicians worked for the people.” (Yes, I hear you out there. Yeah, you, the cynical person screaming at their screen that politicians have always been garbage. I’m aware, thanks.)

The common factor here is the desire for a previous state. However, those who actively choose to immerse themselves in nostalgia aren’t focusing on those negative aspects. Instead, they’re purposefully evoking a happiness found in that previous state. Those who seek nostalgia as a feeling are hoping to experience some combination of sentimental reflection and wistful comfort in the way things used to be as a coping mechanism against the way things are today. To put it another way, many of those who indulge in nostalgia are using it to process the trauma of living in the modern world.

Nostalgia as a Vice

Of course there are those who take their nostalgia too far. Some folks will get lost in the past, losing sight of the real world and creating a fantasy for themselves. They craft a version of their ideal world which never really existed, whose scale and scope depends on financial constraint more than self-restraint. Overuse of any sort of coping mechanism is a problem—some people drink too much, some folks spend every non-working hour in an MMO, and others drown themselves in nostalgia. This cannot be held against nostalgia exclusively unless one is willing to start moralizing all coping mechanisms, and I suspect that’s a glass house which can’t withstand too many thrown stones.

It could perhaps be argued that nostalgia is a particularly addictive feeling. An innate emotional reaction with strong psychological effects which can be triggered simply by exposing oneself to the correct stimuli is indeed powerful. It’s a double-edged sword; it’s accessible (for the most part, though hyper-monetizing nostalgic media is becoming more common), effective, and in most cases harmless. But it’s also habit-forming in the same way people can literally become addicted to misery. It’s an unfortunate truth that most of us have some kind of vice. Thankfully, I imagine immersing oneself in nostalgia is healthier than snorting coke, though self-destructive behavior of any kind is still a problem.

Perhaps that’s the only important takeaway here: nostalgia is often referred to as a weakness, an immaturity, or a refusal to let go. I think, for those seeking it out, it’s just like any other hobby, legal vice, or habit. It has its positives and negatives, but often it’s a reactionary defense created to help shield the seeker from some kind of distress (in the scientific sense).

Responding to Change

In my examples earlier, I said that I don’t miss the inconvenience of rewinding VHS tapes. However, I do miss what those tapes represent for me. They’re emblematic of a time before the very concept of ownership was being eroded. When you owned a VHS tape of Star Wars, you owned it. You could watch it over and over, on your own terms, so long as you had a working TV, VCR, and tape. DVDs were largely the same, but Blu-Rays started introducing draconian DRM schemes which often made it challenging to watch the movie without a stable internet connection or a new enough player. Now, much of the media created in the past few years will likely never see a physical release at all, forever to be locked away behind a monthly subscription which will keep going up in price for the foreseeable future. Don’t you kind of miss owning things?

In fact, no one enjoyed rewinding VHS tapes. It was tedious, frustrating, and another point of failure in a system with too many moving parts. But, the instant gratification and expanded capacity of DVDs made entertainment slightly less special. Instead of watching a couple episodes of a TV show at a time, you could catch up on entire seasons with only a few disc swaps. Now, with streaming, you can binge entire shows without ever leaving your couch. Combined with the crippling social media addictions many of us have, well… don’t you often find yourself tuning out the show you just put on? It becomes background noise while you scroll on your phone instead. Don’t you kind of miss being bored?

Smart home devices are another example: to get the weather, you used to have to read the newspaper or catch the forecast on TV at the right time. Now you can just ask the friendly little puck to tell it to you… so long as you’re fine with it also listening to every word you say and selling that data to advertisers. Don’t you miss the days before every device in your house was spying on you and boiling you down to advertising metrics?

Each of these examples is part of the nostalgia puzzle. They represent subtle but substantial changes in the ways we experience our lives. I’ve focused primarily on media, but in many ways, fundamental assumptions about the way the world works are being challenged across the board. We’re losing rights, privacy, ownership, and livelihood in a measured erosion, and it’s impossible not to feel that on some level. Some people cope by seeking out nostalgia.

Rejection

Nostalgia is a rejection of the consequences of what we’re told is progress. It’s intentionally putting oneself backwards in time in order to, just for a moment, escape the “dystopic future” it sometimes feels like we’re in. It’s immersing oneself in a context before all of the very real pressure being exerted on us by the numbing manufactured serotonin hits of social media, the glamorous but soulless games full of psychologically-manipulating microeconomies, the dishonest Twitter performances of two-faced politicians getting rich and fat off our division, and so on. Often, it’s allowing oneself to mentally relax within a period of one’s life that was, in some tangible or intangible way, “better” than it is now.

Truthfully, that’s the danger of nostalgia. It’s not the feeling itself, nor the seeking of it, which is harmful. It’s the retreating into the past and giving up on the now. Responsible nostalgia is healthy escapism, but too often nostalgia becomes an excuse to not try and make things better today. It’s easier to just wistfully look backward than to sternly march forward, even though the things we want from the past could, theoretically, exist today in harmony with the very real progress we’ve made. We’ve just got to fight for it ourselves rather than wish for a golden time that never actually existed.

So, Wait… Are You Pro- or Anti-Nostalgia?

My stance is simple: excessive nostalgia in a population is a symptom that something is wrong. Things will never be perfect, and therefore nostalgia will always exist. We, as people, love to focus on the negatives of today and the positives of yesterday. However, I propose that an abundance of it is a strong indicator that something is fundamentally damaged in society. Like with Neo in The Matrix, it’s a sensation you feel almost subconsciously; a reaction to a stimulus you weren’t even fully aware of. And when you’re choosing how to react to it, you can either choose to escape the Matrix to fight for a better real world, or you can be Cypher, longing so hard for the memory of what used to be that you’d do anything to have it back.

This is where I arrived after reflecting on my own nostalgia. I’ve spent far too much money on 30-year-old video games, dusty old computers, movies from my childhood recorded to a format so outdated they might as well be etched in stone tablets, and keyboards emulating “the good old days.” I even bought a 50-pound hunk of glass, plastic, and analog electronics they used to call a CRT TV—look it up in your history books next to the dinosaurs. And while I will continue to indulge in my escapism from time to time, I recognize that there is a line across which lies a dangerous place full of comfortable wistfulness I could uselessly wallow in for the rest of my life.

So, is nostalgia dangerous? Probably not. Is it healthy? Also probably not. It’s like any other vice or habit: take it in moderation, and use it responsibly. Remember that you can’t go back in time, that the fog of the past makes everything seem simpler than it was, and that no matter what, you still live in the now and have a responsibility to work toward a better today. Maybe if all us nostalgic fools work hard enough to make a better world, future generations will create a lot fewer of us.

Over three years ago now, I wrote an article titled The Inertial Deathblow where I theorized that having decision makers mired deep in their own inertia is a critical hindrance to a competitive business. Time has only strengthened my experience here—since the original article, I’ve seen some very promising projects get flushed because of a few myopic leaders. Once those folks left or were removed from decision-making roles, I watched as newer and better solutions flourished.

One thing continually struck me as odd, though. I alluded to this at the end of that first piece: the “correct” option is usually to build on top of the old stuff… sort of. However, despite it being “correct,” it’s not what I saw happen. Let me show you why it didn’t happen that way, and at the same time you’ll come to understand what I mean when I say “sort of.”

Legacy Resists Change

Instead of happening within the old code, all the cool new stuff got created entirely around the old code. Sometimes modules would get broken off to live somewhere near the old behemoth and speak its arcane, dead language, but most of the time the developers of the shiny modern systems avoided it like the plague. If you’ve worked in software engineering for long, you’ll already understand why this happened, but if not, let me explain.

The first iteration of any system is almost always a monolith, especially when it’s being written by a start-up team and/or by newer developers. Monoliths are not, inherently, bad. In fact, from an architecture perspective, I’d wager all solutions should begin as “trivial monolith” and only become more complex as necessary from there. However, monolithic applications have some key weaknesses. One of the most impactful is the tendency for them to slowly acquire their own gravity. As they grow, and as things get bolted onto them, they act as Katamaris, growing bigger and sucking up more and more things until eventually they become their own little planets with complex ecosystems. As soon as you run into a snag, stuff starts breaking.

The sheer force which can be exerted by a large monolithic application is unmatched. Skilled developers can defend against it, but most shops don’t exclusively employ folks trained in the art of anti-gravity. These systems can create vast wells of tribal knowledge, which makes them resistant to training and documentation. Since all the application logic lives in one place, devs tend to store all the data in one place too, creating monolithic databases. These behemoths are huge single points of failure often only mitigated by vast, expensive backups and wasteful failover clusters. Straddling all this is the inertia created by having such a large, tightly-knit system. Despite the technical debt it generates, it was created as a single infallible unit and, by its very nature, has tightly interwoven its various units and created omniscient dependencies which become nearly impossible to unwind.

As a result of this tendency, it becomes very challenging to change the monolith. Often, logic within it depends so strongly on other pieces of itself that it cannot be meaningfully reused anyway—so developers don’t. They just write new code which does functionally the same thing any time they need to interact with a piece of the legacy system. However, as hinted earlier, these monolithic systems have their own arcane language. They often do not present any sort of API at all; the monolithic logic directly manipulates its components. So, if your external software wants to interoperate with the system, it must either:

1. Directly manipulate the monolith’s components as well, causing the new software to take a transitive dependency on the monolith anyway. It must “play nice” with the monolith and access the system the same way, but without being able to use the same code modules due to a spider web of internal dependencies. Or…
2. Throw away the old system and reimplement it from scratch. Or…
3. Carefully operate on the monolith, excising and enhancing pieces of it to create an API where one never existed before.

It’s this third option which we’re going to focus on as the superior strategy.

A Cybernetic Organism

Perhaps the most important lesson to learn about monolithic systems is that they were almost never intended to be so gravitational. Do not make the mistake of hating the original developers—instead, try to understand them. Put yourself in their mindset. Why would they have created the application/service/system the way they did? What forces were acting on them which kept them from making better decisions? When were these decisions made and how does that affect the context? Answering these questions will help you avoid making the same mistakes, sure, but it will also inevitably lead you to a dire conclusion.

All software, long-enough lived, will eventually become a monolith.

It is crucial that you understand this; otherwise, it cannot be countered. All designers, developers, and stakeholders on a piece of software must keenly grasp this truth. The mitigation requires cooperation from everyone, from the architects and product owners through the most entry-level engineers.

Armed with this knowledge, you will come to understand a universal law: monoliths are a part of real-world software systems and must be handled. They emerge from well-intentioned systems after years of bolt-on additions, quick ‘n dirty hacks, inexperienced developers making poor or uninformed decisions, and late night crunch time. Whether it was designed as a monolith or was once a tiny little microservice, the unyielding entropy which bloats and contorts software in the production world nudges it ever closer to its fate.

So, how do you handle monoliths? Many junior devs will argue for scrapping the whole thing and starting from scratch. This works for trivial applications, unimportant systems, or for companies with ludicrous amounts of expendable capital, absolutely. But, most commonly, an application which became a monolith evolved that way because it was too integral to the business. Even if you tried to run the new system in parallel with the old, the chance of introducing critical regressions at that scale of change nears 100%. Most stakeholders aren’t going to accept that level of risk. Of course, risk aversion and risk management are all pieces of the puzzle which agile development and DevOps try to address… but that’s another topic for another time.

No, the answer is not to scrap the monolith. You must instead replace its organs with cybernetic enhancements.

Living Tissue Over a Metal Endoskeleton

Fundamentally, all units within a piece of software can be replaced… eventually. The nature of most programming languages means that coming into a given unit of logic, you have a few inputs:

• “Global” state (e.g. global variables, static fields)
• Module-level state (e.g. instance fields/properties)
• Local state (e.g. parameters to the unit, variables in the unit scope)

…and a few outputs:

• Side-effects on shared (global or module) states
• I/O operations
• Return values

Well-written code will likely be very careful about how these inputs and outputs flow through a unit, usually tending toward a functional style, but sadly not all code is well-written. Legacy, monolithic code very often tries to manipulate any state it can legally touch, all across the system, without any consideration to how those side-effects might affect anything else. This makes the proposition of trying to replace any given unit a daunting one. Often, it can feel impossible to unwind the various layers of dependencies a method might take. However, it is possible. You just have to be willing to accept some compromises and commit to a vision. And, in the spirit of agile, make sure each iteration is bringing its own value, because you never know when conditions will change and your vision will get shelved.

Thought Exercise

Let’s take a close look at a fairly trivial example. Pretend this code lives in a monolithic three-tier MVC service (WARNING: intentionally bad code ahead):

// This code is intentionally very bad in so many ways
public AssetOperationEvent CreateAsset(AssetViewModel asset)
{
    using (var repo = Repositories.CreateRepository<AssetRepo>())
    {
        var newAsset = this.AssetConverter.MapViewModelToModel(asset);
        var img = repo.LoadImage(asset.Image);
        img = ImageHelpers.Validation.SizeLimiter(img);     // throws if invalid
        if (newAsset.Name.Trim().Length > 0)
        {
            repo.SaveImage(newAsset, img);
            newAsset.ImageData = img;
            repo.SaveAsset(newAsset);
            return AssetOperationEvent.Successful(newAsset);
        }
        else
        {
            throw new InvalidOperationException("Name is required");
        }
    }
}

If you’ve been tasked with creating a new Asset Management REST API, but the old asset-related functionality in the monolithic application must persist, how would you approach it? Would you…

1. Move the asset creation logic into a library which can be shared by both the API and the monolith?
2. Rip the logic out of the monolith entirely, put it into the API, and have the monolith call the API?
3. Change the front-end to call into the new API instead of the monolithic back-end when creating assets?
4. Rewrite the asset creation code in the API, have it integrate with the same tables as the monolith, and maintain both code paths?

Seriously, stop reading for a minute and decide which one you’d choose. I’ll wait.

Have you decided? Good. Let’s break down the pros and cons of each of these options.

Option 1: Move the asset creation logic into a library which can be shared by both the API and the monolith
If you picked this one, you’re going to end up unwinding spaghetti for a long time. Your library is going to have to introduce a new transitionary DTO between AssetViewModel and Asset, know about the repository class (and therefore the database connection), contain all of the image validation (which isn’t necessarily only used here), discover and reimplement the implied business rules enforced by exceptions that could be thrown by your transitive dependencies, and so on. Going down this road is a path to pain. That being said, it’s also one of the only options which keeps you from needing to rewrite the business logic, which lessens the chance of regressions.

Option 2: Rip the logic out of the monolith entirely, put it into the API, and have the monolith call the API
This might seem like the most straightforward approach at first glance, but you’re still saddled with needing to understand and reimplement various layers of business rules which are not immediately obvious. On top of that, you’ve also introduced another network hop—calls to create an asset now must travel from the client, to the service, to the API, and back again. Perhaps a single additional hop both ways isn’t so bad, but when this gets out of hand, it can be catastrophic. This isn’t even considering that, assuming your new API is following some semblance of best practices, you’ll also need to worry about service-to-service authentication and authorization.

Option 3: Change the front-end to call into the new API instead of the monolithic back-end when creating assets
Perhaps the “cleanest” of the four options (in the sterile sense), this option still requires that your new API reimplement all of the business rules, and as we’ve found, this is not trivial. It can also create fragmentation on your front-end application as those developers hack in branching paths for each of the operations your API supports vs. the ones it doesn’t yet. However, it removes the need for multiple back-end code paths, and doesn’t introduce an extra network hop.

Option 4: Rewrite the asset creation code in the API, have it integrate with the same tables as the monolith, and maintain both code paths
Frankly, it turns out that most of the other options are going to have you rewriting a significant portion of the asset creation code anyway. Unfortunately, this option introduces the highest amount of additional maintenance cost. Now you’ve got two separate, completely distinct logical paths trying to implement the same business rules against the same backing tables. They must target the same tables, or else operations against the API won’t show up in the monolithic application and vice versa. Any deviance between them could violate business rules and cause hard-to-diagnose errors in either system. Maybe the most damning disadvantage of this approach is that it doesn’t do anything to discourage the monolith. Since both code paths continue to exist, the default one will continue to be the monolith’s version. Your new logic will always just be a copycat.

None of these options are ideal. Everyone has their particular philosophy which probably leads them down one path over another. Personally, I propose that any approach which results in supporting and maintaining two code paths is unacceptable, no matter the cost otherwise. The risk of divergence is so high, and it can manifest in so many subtle ways (and even if you did have unit tests, those would diverge as well), that almost anything else is better. Which option you chose isn’t the most important part, though.

The important part is that they all have something in common. They each create a new component which does the same thing, but better in some way. One way or another, you’ll wind up moving out the capability from the old thing and hooking up all the connective tissue to the new. That’s why I call this the Cyborg Strategy: it’s an approach based in maintaining or enhancing legacy systems by slowly upgrading them, unit by unit, towards a fundamentally different architecture.

Looking In the Mirror

The important part of this strategy isn’t just ripping functionality out from a monolith and replacing it with a newer, better, modular component. It’s the idea that over time, more and more pieces of the system will work this way, all while maintaining the veneer of the old system. At the beginning of this article I asked, “where is the threshold across which you become something else entirely?” The philosophy behind this approach is that eventually, you’ll reflect back on the old code and realize that it’s not the same application anymore—like our hypothetical cyborg looking in the mirror and realizing they’re no longer truly human.

I’ve made this whole thing sound pretty amazing, but this strategy is not without its downsides. The act of surgically removing the “organs” of your old code gets easier as more and more units are removed, but early on it can be a massive investment fraught with compromises. You’ll often find yourself taking less desirable routes—like in our trivial example above, you might need to reimplement small pieces and find ways to keep it all working together without bringing down the house of cards.

These compromises are acceptable so long as you’re continuing to bring value with each surgery, but what about when you can’t? What about those scenarios so intertwined or fragile that you can only remove large, interlocked chunks at a time? In these situations, I’ll cite Martin Fowler, from his article Is High Quality Software Worth the Cost?:

The annoying thing is that the resulting crufty code both makes developers’ lives harder, and costs the customer money. … High internal quality reduces the cost of future features, meaning that putting the time into writing good code actually reduces cost.

Code that can only be operated on in massive, expensive chunks is absolutely overgrown with cruft. At some point, the value proposition for that surgery overwhelms any counter-arguments. There’s no way that your legacy code could simultaneously be so easy to maintain and update that it remains cheap to do so, yet so hard to split apart and modularize that it must be tackled in huge projects. They’re mutually exclusive.

The mechanics of pitching this value to the business are out of scope here—a topic for another article. Maybe I’ll write that one in 2025. Nevertheless, you will find yourself at a point where your path leads you here: removing and replacing components of a legacy application with augmented pieces in order to evolve it toward a better architecture over time. Your objective is to look back on yourself and your team and realize that the application you started with is gone, replaced by the cybernetically enhanced version you’ve been piecing together over months or years.

The Sacrifice 👍

Once you’ve finally created a cyborg, what should you do with it? It still wears the face of the application it used to be, and probably still hosts some amount of the original logic, but most of the truly valuable pieces have been modularized. Ultimately, there are three possible fates for this wayward hybrid.

1. Continue supporting it until deprecation. There is a strong argument for keeping it alive, serving its original purpose until the business no longer needs it. You’ll continue paying technical debt on those leftover bits, but eventually, conditions and requirements will change enough that the app can be retired. New systems can come in and take advantage of the APIs you’ve created in a harmonious way, the extracted logic continuing to provide value for years.
2. Transplant everything that remains into a new, more suitable form. By the time you’ve reached this stage, the facade of what the app once was is now vestigial. All of the value generation occurs elsewhere. There is even more value to be gained by “finishing the job” and moving the leftovers into a more accommodating form, essentially just continuing the augmentation you’ve been doing until almost 100% of the old code is gone.
3. Sacrifice the old shell. This is a good opportunity to revisit the original business needs served by this hybrid system. You may find that it’s time to cast aside the potentially ancient assumptions that fed into its creation and start fresh with a new set. After all, the valuable parts have been removed and can now be leveraged by the new shell.

Which option is correct for you depends on the requirements, the application, your roadmap, and more. You’ve painstakingly bought yourself these opportunities. Choose wisely.

Finale

Did I abuse the whole “cyborg” metaphor too much? Obviously I don’t think so, but I’m biased. I wrote the damn thing.

I’m aware that these ideas aren’t new—though I haven’t read them yet, I know there are books by Martin Fowler and Michael Feathers which cover these topics in much greater detail, I’m sure. However, I wanted to share and express my philosophy and mindset behind how best to break down monolithic legacy applications. It’s a topic about which I have a lot of passion and, I believe, some unique perspectives.

I truly hope this helps someone wrap their head around an often overwhelming and difficult problem, and gives them some hope that it can be done. If you want additional reading, I recommend checking out everything I’ve linked within the article—there are some amazing resources out there on this topic, since it’s something almost every engineer runs into during their career.

Next time, I’m going to follow up on another of my teased articles and discuss how certain hiring practices and team structures feed into failure and promote the development of these nasty monoliths.

Doom Eternal is a strange game. Despite being a huge fan of the Doom series since I was a kid, and even though I greatly enjoyed Doom (2016), I bounced off of Eternal for a while. I loved the Heavy Metal aesthetic (and soundtrack), found the weapons incredibly satisfying, and connected well with the new movement mechanics, yet something didn’t click with me at first. The hype died down pretty quick and I was left frustrated, racking up a lot of deaths.

The game is hard. I started playing on the “normal mode”, Hurt Me Plenty. By the fourth level, I cranked it down to easy mode (I’m Too Young to Die) and still kept getting wrecked. Sure, I was making more progress, but I could tell something wasn’t right. My initial reaction was that the game was just too damn difficult. I’ve played difficult games before, but Doom Eternal felt different. I put the game down for a while.

Speedruns to the Rescue

My inability to enjoy the game didn’t stop me from watching its speedruns. Specifically, I started tuning into Byte’s stream and watched his Ultra Nightmare 100% attempts. He’s not the best Eternal player out there, but I found his style entertaining and had enjoyed his Doom (2016) run at AGDQ 2020. At first, I was just wowed by his mastery over the mechanics. While watching, though, I started to pick up on some patterns.

He used the flame belch (lovely name, right?) far more than I did, and on the weakest enemies. He never ran out of ammo, somehow, while I was always low. He seemed to throw freeze grenades at heavy demons and then move away from them instead of closing the gap to kill them. Noticing all this inspired me to get back into the game and start experimenting more with the tools at my disposal.

Instantly, I was 1000% better at the game and beat it, no problem, on Ultra Nightmare… is what I hoped would happen. Instead, I still got my ass kicked repeatedly on easy mode. But I was learning. I figured out that the flame belch doesn’t spawn armor shards just because. It spawns them as a renewable way to refill your armor, and armor is better than health. The chainsaw regenerates a charge of fuel because you’ll quickly run out of ammo if you don’t replenish it; the ammo limits are significantly lower than the previous game for a reason. The freeze grenade is a crowd control tool, offering you an opportunity to get some distance and reevaluate your situation.

Perhaps most importantly, I started having fun again. Where before the game felt difficult to the point of frustration, now it felt like it was challenging me to do better and learn more about its mechanics. I kept improving until eventually I felt comfortable moving back up to normal mode, where I promptly got stomped again. But I didn’t feel too bad about it this time. I understood the game on a much deeper level than I did initially, and knew that success was within reach. I just had to get good, basically.

Difficulty and Challenge Are Not the Same

I’ll be honest: the “correct” way for my Doom Eternal story to end would be for me to say that by understanding it, I was able to beat it. It would feel like the natural conclusion. But no, I actually never beat it. Don’t get me wrong: I got much further, and I didn’t stop playing because of that original frustration this time. I probably will eventually circle back around and finish the game—like a lot of folks, I’m spoiled for choice when it comes to entertainment, and other things grabbed my attention.

Despite having not finished it, my experience with Eternal left an impression on me about the contrast between difficulty and challenge. People tend to use the words interchangeably, but I think there’s a very clear distinction between them. Indeed, a challenging game is difficult, but a difficult game isn’t necessarily challenging.

Difficulty in a game (or in most activities, for that matter) is when something requires a great deal of investment to achieve. The difficult action is non-trivial to complete successfully. Critically, however, there is no implication that the investment be tied to skill, talent, or practice. Something can be difficult to do simply because it’s very time-consuming.

• Hitting the max level in Final Fantasy VII is difficult, but it’s not challenging. If you spend enough time grinding, you’ll get there, and the grinding is mindless busywork (i.e. it requires little thought or input).
• Finishing Dragon Quest II is difficult. Many of the enemies in the end game can kill your party in a single action. Luck is more of a factor here than anything else.
• Many roguelike games (e.g. Nethack) are incredibly difficult to complete. The difficulty lies in deep randomness, but challenge can be found in strategies to mitigate it.
• Battletoads is a difficult and challenging game, but many facets of its difficulty originate from unrealistic and unfair mechanics which can only be addressed by rote memorization.
  • This is true of many older arcade- and NES-era action games. These games were designed to keep you playing even when the quantity of game content was low. This is especially true for arcade games, where the goal is to keep you pumping quarters into the machine.
• Hundreds of mobile games (and, increasingly, big budget retail releases) are very difficult, but can be made easier through purchases or time-gated resources. This difficulty cannot be overcome through skill; it requires an investment of time and/or money.

I don’t mean to imply a lack of challenge in these games. Going back to the Final Fantasy VII example, a skilled player with a good strategy will complete the game more quickly than one without. But ultimately, the game can be completed, more-or-less, by anyone.

Challenge, on the other hand, is when the action cannot be accomplished successfully until you perform it better. “Better” usually means past a designated threshold of skill, but can sometimes be on a sliding scale of judgement based on the goals of the game (think the scoring system in Devil May Cry). Some difficult games can be brute-forced, while by definition a challenging game cannot—unless the repetition results in skill improvement, of course, but then we just call it practice.

• Doom Eternal turned out to be a very challenging game for me. Until you understand the rules of the game and gain some skill at the necessary tactics and mechanics, you will reach a point where you can no longer progress.
• Dark Souls is famous for being a highly challenging game.
• The mainline Mario games often offer a natural scale of selectable and/or optional challenge, but even at the lowest levels, almost the entire game design is built around challenge.
  • The required challenge may not be very high, but it’s there nonetheless, especially for newer players who possess less baseline skill. Not everyone is intimately familiar with the hand-eye coordination and mental mapping necessary to move a character in 3D space with a controller.

To put it succinctly, challenging games are literally encouraging you to get better at them through their design.

Challenge Is Not Necessarily Fun

So far, this article has painted a fairly negative picture of games that possess a high level of difficulty without necessarily having challenge. I even said that once I discovered the challenge of Doom Eternal, I started having more fun. The truth, though, is that the fun factor of a game is not exclusively tied to its challenge or difficulty.

Let’s look at the Final Fantasy VII example again. It’s a highly regarded classic, often topping peoples’ “best games of all time” lists, but as I said earlier: the game can be beaten by pretty much anyone. This means it has no challenge, right? Well, maybe not in the core game, but players seeking a challenge actually have several options.

• They can take on the optional superbosses, whose defeat requires more than just grinding XP and reaching max level.
  • Ruby Weapon and Emerald Weapon are much more challenging fights than anything in the core game.
  • Today, the age of the game plus the drastically increased availability of internet access has made strategies for killing them commonplace.
  • Back in the day, though, everything was hearsay. They were shrouded in rumors and even the strategy guides didn’t have great tips for how to beat them. Finding someone that had was genuinely impressive.
• They can just force themselves to play more intelligently and optimize their gameplay more.
  • For example, rather than just leveling up every time you lose to a boss, these players might retry several times with different tactics.
• They can enforce their own gameplay restrictions.
  • This is a niche audience, to be sure, but it’s one that enjoys taking otherwise “easy” games and making them challenging through intrinsic objectives such as not equipping Materia or shooting for the lowest possible character level at the end of the game. Speedrunning falls into this category as well.

But what if you just don’t want to be challenged? Isn’t it valid to want to enjoy an experience like Final Fantasy, with its intricate story and elaborate cutscenes and grand adventure, without having to get good? What about players with disabilities, or those with little capacity to practice a video game for long periods of time? Many games are tailored around the experience of playing them without necessarily requiring a show of skill to “earn” that experience, and that’s okay too.

Not every game needs to be challenging. Presenting an obstacle to overcome is only one of the many tools in the design toolbox that can make something fun. Sometimes, challenge is a barrier to enjoyment. Take Dark Souls, for example. I’ve never beaten it. Hell, I’ve barely made it past the starting area. Despite that, I still enjoy the game’s atmosphere, lore, and art. For me, it’s the perfect Let’s Play game. I’m not interested in putting in the effort of gaining the skill necessary to see more, and the pleasure I get from overcoming the challenges doesn’t outweigh the frustration I feel with myself when I continually fail. Since I enjoy the presentation of the game, though, and find its gameplay loop interesting (in theory), I also enjoy watching others play it and discuss it.

Every Game Has Its Place

The intangible elements that make a game fun are extremely hard to pin down. Plenty of awesome games are challenging, tons of amazing games are easy, and games exist on every point in the diamond-shaped spread between ease, difficulty, accessibility, and esotericism. There is a place for all games, whether they challenge you to be better or not. It’s very interesting to me how often I see difficulty conflated with challenge, however. I think the industry would do well to learn the difference and better identify where designers are substituting challenge for plain difficulty.

Over three years ago, I wrote an article about my suspicion that the World of Warcraft team was afraid of creating their own legacy servers. In it, I suggested that they were not only worried about the engineering effort and maintenance costs behind running two vastly different versions of the game, but also, on some level, fearful of just how positive a response those servers might receive.

Well, if my hypothesis was correct, Blizzard must be absolutely shitting themselves with terror right now. It turns out all they needed was a little push from the community, because in late 2017 they finally announced WoW Classic. Since that announcement, the hype around the release has only gotten stronger. Now that we’re mere days away from release, the original World of Warcraft—which Blizzard’s top brass seemed so confident we didn’t actually want—is experiencing the kind of resurgence other companies can’t even pay for.

Since the initial run of servers went live for character reservations on August 12th, Blizzard has added (or will add before launch) over a dozen additional servers. One can assume they were added out of necessity; it seems that even once they conceded to actually offering a Classic version of WoW, they still couldn’t believe anyone actually wanted to play it. Now, the numbers speak for themselves. The servers are filling up before the majority of players, who likely wouldn’t have bothered reserving their characters ahead of time, even log in for the first time. By all accounts (including their own), WoW Classic is more massive than Blizzard expected.

I won’t spend this article gloating about how right the community was about the demand for Classic. While I intend to play it for a good, long time, everyone will eventually reach a point with it where the nostalgia has worn off. Myself included. We’ll have seen the expansive world, relived the peaks and valleys of joy and pain, and remembered both how we loved and why we hated old-school MMO design. We’ll be ready to move on. I hope Blizzard learns a few things from this massive initial success, however, and eventually releases Burning Crusade and Wrath of the Lich King-era servers as well.

A Link to the Past

Instead, I want to congratulate Blizzard from an engineering perspective. They have managed to achieve something near-miraculous with Classic: they brought the future back to the past. For those unaware, Blizzard essentially had three options to bring a legacy version of WoW to market:

1. Stand up the old server software and release the 1.12 client from 2006 and let the players deal with the known bugs, exploits, security holes, and lack of modern integrations (e.g. with the Battle.net client).
2. Use the 2006 code, but fix all known exploits and security issues and add the necessary integrations.
3. Take the modern code and re-implement the 1.12 logic and systems.

It’s option #3 that I didn’t consider in my original article. Actually, that’s not entirely true—the idea passed my mind as I wrote it, but I discarded it. It was so absurd, so unrealistic, and so expensive that I assumed such a thing was fiscally irresponsible. That’s the option they ended up going with. I only have myself to blame for this lack of foresight; after all, I even said before that Blizzard has vast resources and talent at its disposal. Their engineers considered the available options and chose the one which made sense to them.

But why? Why risk the millions of possible regressions that come with trying to force a newer system to emulate such a complex old system, especially one where the nuances of the system are a critical part of the experience? There are a few talks from Blizzard engineers on this topic, but perhaps the most appropriate one is the “Restoring History: Creating WoW Classic” panel from Blizzcon 2018. In this presentation, the engineers don’t give a strong reasoning behind their choice of direction. They briefly gloss over some pros and cons, but I imagine most folks at that panel didn’t care too much about the engineering behind Classic. So, we’re left to pick from the crumbs and make assumptions.

Blizzard: A Gaming Enterprise

Blizzard Entertainment, the game studio underneath the parent company Activision-Blizzard, has over 5000 employees. They are a $700 million dollar business. Obviously, this is massive. Compared to their size at WoW’s launch in 2004—around 400 people—the scale of their operations has grown by an order of magnitude. They’re playing in the big leagues now, and they’re on the same turf as many major corporations. As a result, it only makes sense to think of them from a corporate perspective, and what’s the most important thing to corporate IT? Infrastructure.

Infrastructure maintenance, stability, and growth are among the foremost concerns of corporate engineering teams. The rise of platforms like Kubernetes, DevOps and SRE roles, and cloud computing has demonstrated how pivotal infrastructure is to the success and resiliency of a company. Blizzard is surely no different. While it’s impossible to know what their infrastructure looks like today, I guarantee it’s nothing at all like how it was 15 years ago.

Teams move away from old infrastructure because they outgrow it, sure, but they also move away because of the flaws. Lack of scalability, technical debt, security holes, dead technologies; any of these alone are perfectly valid reasons to update your infrastructure. I imagine Blizzard, a company with zero experience in MMO infrastructure in 2004, had all these and many more. To a team operating at this scale, returning back to the ancient “broken” infrastructure would be poisonous to the entire ecosystem. The entire platform is at risk if a single component is weak.

Infrastructure was almost certainly the reason Blizzard chose to use the modern WoW code as a starting point. The team simply could not take the risk of running ancient servers, designed for hardware and networks that are no longer available, on their systems. They couldn’t expose their customers to the Internet of 2019 with a client from 2004. The cost/benefit analysis was likely very conclusive: it’s cheaper and safer to just throw programmers at the problem.

Eventual Consistency

Throw programmers at the problem they did. A year passed between the initial announcement and the first playable demo at Blizzcon 2018. I presume they waited until they knew how to solve the problems before announcing the project, so it’s reasonable to say that by late 2017 they had chosen to re-implement Classic’s logic on the modern architecture and had learned how to import the old data structures. This means that the year between Blizzcon 2017 and 2018 was almost certainly spent entirely on game systems.

This alone was not enough. Famously, Classic had a lengthy closed beta period and several public stress tests where players were finding bugs left and right. Many of them were indeed regressions introduced by the modern engine. Especially interesting were the defects found that were also defects in the original game. The above-linked panel from Blizzcon 2018 demonstrates one of them: a missing texture on a lamp, defective for 15 years—long enough that, like most unfixed bugs, it became a feature. Of course, passing through the fog of time is hard for even the best of us, so many of these “bugs” were actually intended behavior.

Indeed, Blizzard could not have simply left the recreation of 15-year-old logic to fading memories and speculation, so they created an internal version of the game as it truly existed in 2006. At a small scale, without being publicly exposed, they were able to use the old 1.12 server as a rubric of sorts. It served as the authoritative guide for the nuances of the old systems.

In a very intelligent move, Blizzard used a combination of internal testing, player testing, and the original systems to check their re-implementation. This allowed them to use their modern infrastructure for the live game, while still eventually ending up at a ruleset so very close to 1.12, even down to reproducing bugs and long-surpassed architectural limitations. While I have no doubt that more bugs will be found when the game goes lives on August 26th, this “eventual consistency” approach is, in hindsight, certainly the correct approach for a company like Blizzard.

Grats!

So, congratulations are in order. Blizzard has managed to satisfy two camps of people notoriously difficult to satisfy: ops teams and players. While it remains to be seen how stable the launch is, the beta and stress test periods have already shown us just how good a job they’ve done with the authenticity of the systems. What seemed to me like an absurdity turned out to be the perfect solution. I think there’s a lesson to be learned in there somewhere.

Also, to whomever spoke up at Blizzard and pushed hard for the investment into Classic, I specifically offer you my thanks. Without you, the company may still be telling us just how much we think we do, but we don’t.

You: “Let’s consider using Docker for this service.”
Them: “No, we can’t do that.”
You: “Why not?”
Them: “Because, we’ve never done that before. Besides, Docker isn’t proven technology.”

It makes me want to pull my hair out when someone dismisses an idea out of hand like this. Solving problems in the software industry is all about choosing the right tool for the job. Innumerable factors go into that choice, but you must be willing to consider any solution, or you’re not doing your due diligence. To be clear, I’m not trying to dismiss the benefits of using familiar solutions, or rock-solid and time-tested tech stacks. It’s just… those are considerations that factor into the decision you make, not road blocks themselves.

Technology advances. New stacks have benefits that old ones lacked; after all, they were put together by someone to solve a problem. If it’s popular and well-supported, it’s solving that problem for a lot of people. True, you can solve pretty much any problem with any tech stack. There are shops out there supporting petabytes of data and thousands of users on top of ancient mainframes and COBOL. However, as a business grows, the problems grow and shift alongside it. Sometimes you have to give up the old comfortable tools and move on to something that is better suited to solving the problems you have today instead of the problems you had five years ago.

Let’s put aside some of the other reasons you should consider moving away from aging tech stacks, like the inability to hire anyone. I want to focus on this: if a company gets enough of those inertially-bound people in decision-making roles, it’s a deathblow for the business. The company’s problem-solvers are stuck in the past, which means the business can’t grow. Any attempts to grow are met with…

1. Resistance. “Our servers can’t handle that!”
2. Failure. “We wrote 20,000 lines of code over the weekend to reinvent the wheel, but there were some bugs, so it didn’t work at all and we were down for 4 hours.”
3. Sluggishness. “I estimate about 6.5 months to complete this project. What do you mean our competitors did it in two weeks?! There’s no way!”
4. High cost. “We’ll need to buy two new VM hosts so we can spin up the six new servers dedicated to this service. They’ll be idle 75% of the time, but we’ll really want all six servers at peak load, so we need six.”
5. Resignation, the worst one of all. “Sure, whatever, we’ll get it done. Just hack some shit together and ship it. It doesn’t matter, the architecture is fundamentally broken anyway.”

I wish I were making these up, but I’m drawing from (exaggerated) real-world experience here. At no point in these conversations did anyone else recommend making changes to the tech stack to strike a better balance between the available hardware and the current-day workload requirements. Any time I brought it up, it was shot down. Why? “We can’t do that. We’ve never done it before. It’s not proven technology.”

Innovation is the lifeblood of companies in competitive markets, and inertially-bound people are the enemy of innovation. Look, I get it. I really do. Change can’t happen overnight, and it’s often expensive in terms of manpower, capital expense, or both. But, if you don’t make room for it, you’re going to quickly end up as the last horseback cavalry unit in the era of unmanned drone strikes.

Anyway, enough ranting for now. Next time, I’m going to dive into a little more depth and talk about some of the causes of career inertia, how to avoid it yourself, and how to make those judgment calls on when to go with something new instead of leaning on an old stack. Spoiler alert: despite everything I just said, 90% of the time the correct answer actually is to build onto the old stack… sort of. You’ll see what I mean.

Let’s put his impressive title aside and focus instead on the comment. This man—let’s call him Bob—suggests that the amount of “time” you spend ‘at work’ doesn’t matter if your success is measured by outcomes. To translate back into English, he’s saying that you shouldn’t be worried about your hours, you should be worried about results. Hours aren’t a consideration when you’re focused on the “outcomes”—i.e. getting stuff done. Bob implies that so long as it’s understood you’ll be working a crap-load, then you’ve got no reason to get burnt out by long hours.

Now, I can sit here all day and break apart his argument, but I want to put emphasis on the idea that ol’ Bobby here expects you to not burn out. After all, your expectations were established along with your success metrics. You are focused on outcomes, right? In his model of the workplace, burnout is caused by coming up short in your “success measurements.” Clearly, given his wording and punctuation choices, he doesn’t put a lot of weight behind the “time” you spend ‘at work’.

The Problem with Results as the Only Metric

As a software engineer, I work in an industry notorious for long hours, no overtime pay, scope creep, and poor planning. Let me tell you, Bob: burnout happens whether your expectations were set properly or not. It occurs even if your success measurements are overflowing with outcomes—it’s not the same as being dissatisfied. You burn out because you’ve stressed yourself to the limit repeatedly. You burn out because you forget what your wife’s face looks like. You burn out because you catch yourself working out how to sleep and shower in the office to save time. To put it another way, you burn out because you consistently have too much work to do in too little time.

Especially in software, the 9-to-5 job died a quiet death a long time ago. There are too many eager kids willing to light the candle at both ends to prove themselves, because programming is their passion; too many old neckbeards living at work because they don’t have a life to go home to. These people set the expectation. Putting in extra time goes from being a thing you do when you’re dedicated, passionate, and invested in the project/product/business, to being the norm. It stops sounding like “that Nathan is a hell of a worker” and becomes “look at that guy going home at 5 while the rest of us are here until 7 or later every day.” Before you know it, not working 60 hour weeks is getting counted against you in your annual evaluations.

Combine an over-working culture with project mismanagement and you’ll have the murder weapon used to kill the 9-to-5 job. I’ll be talking at length in a later article about how mismanagement leads to burnout. However, it’s not hard to see why only working 8 hours a day isn’t sufficient anymore. We live in a culture where “you’re lucky to even have a job.” There are limited advancement opportunities and tons of competition for your position. Employers are keen to encourage this; after all, it keeps everyone on their toes.

Call me old-fashioned, but I believe that people are more productive and put out higher-quality work when you give them some time to have a life outside their job. Some people live to work, others work to live. However, like most things in life, the sweet spot is a balance somewhere between the two. You enjoy your job and are passionate about it, but you go home and mentally pack it away for the rest of the night so that you can be the master of your own destiny for a while. Maybe you’ll squander that time watching Netflix and eating popcorn or maybe you’ll invest it into new skills, hobbies, or your family. Either way, it’s time where your only obligations are to yourself and your loved ones. This time helps you decompress and analyze the problems you faced at work subconsciously. It leads to the fabled “ah-hah!” moments in the shower where your brain has finally put the pieces together for you. Without this time, you’re going to run out of gas eventually.

He’s Dead, Jim

So, Bob, you’re right. The 9-to-5 job has died, and we were all so focused on our outcomes that we didn’t notice or care. The worst part is, we’ve bred a culture where humble-bragging about how much you work is a show of dedication. If you truly enjoy working yourself down to the bone (either literally or proverbially), you’ve got my respect. However, for whatever reason—let’s avoid political, economical, or ideological arguments here—this has now become the standard. Anything less is insufficient. I can’t foresee it getting better any time soon, but the best way to improve the culture is to not participate in it. Don’t let your success measurements cloud your perception of what’s truly important to you. And most importantly, don’t let guys like Bob tell you otherwise.

On a whim after I wrote my Realforce RGB article, I decided to sell that keyboard and pick up a Realforce 87u 55g instead. I kept thinking that my experience with the Realforce RGB couldn’t be the norm for Topre keyboards. They’re so loved by many mechanical keyboard enthusiasts… surely they’re not all just misguided? After doing a bit of YouTube research into the sound profile of other Topre boards, I decided to give cup rubber another chance. I’m glad I did.

I don’t have time to write a full review of the Realforce 87u, so I’ll just give some quick impressions. Probably the best praise I can give the board is this: it feels exactly like I expected Topre to feel. It’s soft, tactile, and gives a solid “thock” on every depression while still remaining fairly quiet—overall it’s just a joy to type on.

I still have some minor concerns about the quality of the keyboard, given the price point. The case is still made of plastic, a top and bottom plastic shell that are clamped and screwed together. There is a seam between the two halves, much like the plastic case of the Unicomp Ultra Classic I reviewed a while ago, but it’s nowhere near as flimsy as that. The cable feels cheap and weak; it’s worse than on the Realforce RGB but at least the cable gutter works properly. Despite all of these shortcomings, the Realforce 87u still manages to feel much more like a premium keyboard than the Realforce RGB did. There’s no flex, no creak or squeak, and the switches are largely consistent. The upstroke noise that bothered me so much on the RGB is almost completely absent on the 87u. Overall I have a much more positive opinion of this board than the other.

Once again, however, the elephant in the room rears his ugly mug. Not only is the Realforce 87u expensive, it’s more expensive than the RGB despite the smaller form factor and complete lack of backlight. Topre is an amazing switch when well-executed, there’s no denying it. At $270+ it just can’t compete. The switches themselves are great, but these keyboards are built like $50 Microsoft rubber dome keyboards: very sturdy and reliable, but still plastic and with some annoyances one shouldn’t have to wrangle at over $200.

Ultimately, the decision of whether or not to buy Topre comes down to whether or not you can justify spending so much on what are, in my opinion, quickly diminishing returns. For $200 you can buy some of the highest quality keyboards ever manufactured, and at $300 you can get a custom-built mechanical keyboard made from carbon fiber plates and $1-per-unit Zealios switches. Topre promises an unparalleled tactile typing experience, but without the rest of the package to back it up, it’s hard to recommend such a barebones keyboard.