How a “Kids Game” Changed How I Approach Software Development I remember when Minecraft launched in 2009. I had just graduated with a shiny New Media degree, chasing game dev dreams. My whole life was ahead of me, and it was incredibly exciting. With this new degree in hand, I had jetted off to Seattle, found a decent job, and was enjoying a newfound freedom without the pressures of homework on the nights and weekends. I tinkered with Steam’s Source engine and read every article I could find about tools and frameworks like Endorphin and Euphoria, and subscribed to every major gaming newsletter available. I took one look at Minecraft when it launched and thought, “Who would want to play virtual Legos when you have all of these tools to build a real world?!” and completely dismissed it. virtual Legos Cut to 16 years later: several job changes, cross-country moves, homes bought and sold, a beautiful wife, and two amazing kids; life was chaotic, but it was good. Then, one day, my son came home from school talking about…you guessed it. Minecraft. I always make an effort to show an interest in the hobbies my kids fall into. Kids change interests faster than the weather changes, but when they get excited and start talking about their new hobby, I want them to see that I have an interest in it too. So, after weeks of hearing about Minecraft and recovering from my shock that this was still a “thing,” I decided to give it a try. I tried the game for free with the few weeks I had left on Xbox Game Pass, then ended up purchasing it so we could keep playing. I downloaded the Bedrock server hosting files from their website and set up our server to play together on. And together, we eked out a pretty impressive survival in this harsh world. One night, I headed up to my office to play after everyone had gone to bed and started making a list of the various things I wanted to improve about our base (I like to do most of the building at night so that when the kids log on, we can adventure together). My gaming PC is in my office, where I work remotely, so as I was moving my work keyboard and trackpad out of the way, my computer popped on, used my watch to unlock, and took over the monitor. Briefly, the project I was actively working on flashed onto my screen, and I was momentarily distracted from my desire to game as the problem ahead of me stirred in my memory from earlier that day. Like most engineers, I struggle to leave unfinished work at the end of the day. But as I looked at the code and my list of tasks I had set out for myself for the next morning (a habit I’ve developed over the years to help me let go at the end of the day), I realized something. Glancing at a similar list I had just typed on my phone for my night’s Minecraft build needs, I saw that familiar pattern. Minecraft is just engineering neatly packaged into a whimsical, blocky paradise. Minecraft is just engineering neatly packaged into a whimsical, blocky paradise. First Impressions Can Lie First Impressions Can Lie We’ve all heard the adage “you only get one first impression,” and I’ve often found flaws with that. I know the saying is true enough for the simple reason that the first impression can only happen once. The premise, however, that we can never correct damage done by a bad first impression, is where I find the flaw in this thinking. While it may be true in many scenarios, I would argue that a person who is so stubborn as to never allow for a second impression to help clarify and color their opinion on someone is a person you don’t want to have in your life. First impressions matter, but they should just be a fleeting thought in the large scheme of things. Early in my career, I was handed a project that, at first glance, looked overwhelming. The task involved processing financial data across multiple currencies, with layers of calculations that felt daunting and overly complex. I remember staring at the requirements and thinking there was no way this could be straightforward. But once I dug in, I discovered that most of the heavy lifting happened at the data ingestion stage. The math itself turned out to be simple once the right systems were in place. By building tools to retrieve and organize the variable data, the final solution was little more than a clean calculator that tied everything together. What looked impossible at first ended up being one of the simplest, most elegant engineering solutions I had worked on. It reminds me, now, of all those years ago when I dismissed this game as child’s play, only to find years later that it’s a fantastic piece of art and a whole lot of great fun. I’ve spent hundreds of hours building out a world, now, and it’s a great reminder: you can’t always trust your first impression. When a project seems too daunting or far-fetched, take some time to flesh out the details, and you’ll likely find that it’s not as impossible as it seemed. Projects at work often start this way: overwhelming, noisy, uncertain. But once you set the foundations, just like laying down torchlight and supplies in a dirt shelter, the impossible simplifies into something manageable, even secure. What starts as survival becomes structure. Building Incrementally Building Incrementally Any of you who have played Minecraft know that the first few moments in the game are the same for all of us. You have to punch a tree. You have to punch a tree. I know it sounds ridiculous, which is why I intentionally put that line alone. It needs to stand out. Let’s say it again. You have to punch a tree. You have to punch a tree. You have to punch a tree. In Minecraft, the reasoning is that when you first start the game, there are very limited resources that you can collect with your bare hands: sand, dirt, and wood are some of the obvious examples, and wood is vital for so many things. You don’t start the game with an axe or any tools, so how do you collect wood? You have to punch a tree. You have to punch a tree. You have to punch a tree. You punch that tree for as long as you can until it drops a few pieces of wood. Then a few more. Then a few more! Then you head over to the crafting section with this wood and you make planks. Then you take those planks and you make a crafting table. You continue this loop with more complexity until you’ve beaten the Ender Dragon, collected your Elytra, and completed the game (at least the story). Similarly, building a shelter from the nightly horde of zombies, skeletons, spiders, and witches requires you to place one block at a time. Of course, some mods have sprung up over the past (almost) two decades, but in vanilla, it’s one block at a time. Layer after layer, you build up and around until you’ve secured yourself a safe place to sleep. Interestingly enough, this same process is often the very best way to build software. On another project, I was handed a deadline that was flat-out impossible. When I scoped it, the work would realistically take two months, but the team needed something working in just two weeks. Rather than burning myself out chasing an unrealistic timeline, I reframed the challenge. I broke the project into smaller, independent “chunks” of functionality that could each be delivered in a day or two. I then let the team choose which features they wanted first, clearly noting dependencies and tradeoffs. This gave them working software in their hands right away, and a transparent roadmap for the rest. By shifting from “all-or-nothing” delivery to incremental progress, I turned an impossible deadline into a series of achievable wins. In Minecraft, no one starts with diamond armor, enchanted tools, or a sprawling castle. You start by punching a tree. Then you craft planks. Then sticks. Then the tools. Block by block, you build your shelter, your base, your world. Software is no different. You don’t get to ship the perfect, polished product on day one. But if you’re disciplined about breaking things down: one feature, one function, one “block” at a time. You can survive the monsters, deliver something real, and eventually build something remarkable. You just have to punch that first tree. You just have to punch that first tree. You just have to punch that first tree. Collaboration Without Demolition Collaboration Without Demolition As I mentioned above, I love to build at night when everyone’s sleeping. The kids love to log in on the weekends and see what I built the night before, and then complete their additions to the world. My younger kiddo planted a dense, gnarly, haunted forest on the outskirts of our town. My older kid created a harbor with a rushing river into the ocean for our boats. I, of course, had plans for these areas, so I have to adjust. I can’t log in at night and destroy what they built; that would be monstrous, so I have to find ways to work with them. I might thin out the forest slightly, then add some signs and lights to keep the worst monsters away. I’ll add docks and a redstone drawbridge around the harbor so that it looks ready for more than just our little dingies. But I leave their ideas intact so they know they’ve had a lasting impression on the world just as much as I have. monstrous This same premise is followed every day by us engineers. Most of us are working together on a single product, which means we’re constantly interacting with each other’s code. It’s on us to treat our teammates’ work with respect so everyone feels included, can leave their special mark, and grow together. I once worked in an environment where each developer supported a different business unit. We often solved similar problems, but instead of copy-pasting code between projects, which led to messy edits and fragile solutions, we adopted a better approach. Whenever someone built something useful, we turned it into a small service that others could integrate. If one developer had a feature I needed, I wouldn’t copy it; I’d build a service around it that worked for both of us. That way, we each had a clean, maintainable solution without stepping on each other’s code. Over time, this mindset built a culture of collaboration without demolition: sharing solutions without breaking what was already working. In Minecraft, I could bulldoze my kids’ builds and force my “master plan” onto the world, but it wouldn’t be much fun for them, and it wouldn’t be our world anymore. Instead, I find ways to shape, protect, and extend what they’ve made so we can keep building together. Software works the same way. You can rip apart what others have written, or you can work with it, improve it, and fold it into something stronger. That’s how teams grow, codebases stay healthy, and everyone’s contribution leaves a mark. At the end of the day, whether it’s a harbor, a haunted forest, or a shared codebase, the goal isn’t to build my world; it’s to build our world. my our Keep Building Keep Building Calling a video game a guide for engineering might sound like a stretch. But it isn’t. In both Minecraft and engineering, we move forward the same way: by taking one step at a time and shaping chaos into something meaningful. That rhythm doesn’t just apply to code or blocks; it’s how we build anything worth keeping together. Chaos is presented to us on a silver Jira platter, and we’re asked to organize it into something that can change the world, at least for some users. Chaos is presented to us on a silver Jira platter, and we’re asked to organize it into something that can change the world, at least for some users. That’s the real craft: turning mess into meaning. It may seem daunting, but you already do this every day in your life and hobbies; you just need to bring the same mindset to software development. Even AI works this way. My experiments with AI have felt a lot like starting out in Minecraft. Next time, I’ll share what it’s like to punch trees in the world of AI. (Originally posted on Substack: https://halexmorph.substack.com/p/the-incremental-mindset) https://halexmorph.substack.com/p/the-incremental-mindset

How to Build Energy Into Your Developer Workflow

Learn something new with me!

Nominated for Super Career Strategist of 2022

Too Long; Didn't Read

Make resilience your competitive advantage

Minecraft, Engineering, and The Incremental Mindset

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

4 Tips That Will Help You Become More Organized as a Developer

How Frequently Do IP Addresses Change and Why It Matters for Accurate Data

RNN-Aided Dead-Reckoning: IMU-Only Navigation for Cost-Efficient AUV Fleets

What No One Told Me About Being a Product Manager at an Early Stage Startup

10x10: Ten Life Lessons from a Developer After Ten Years in the Industry

4 Tips That Will Help You Become More Organized as a Developer

How Frequently Do IP Addresses Change and Why It Matters for Accurate Data

RNN-Aided Dead-Reckoning: IMU-Only Navigation for Cost-Efficient AUV Fleets

What No One Told Me About Being a Product Manager at an Early Stage Startup

10x10: Ten Life Lessons from a Developer After Ten Years in the Industry

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps