While talking to some friends the other day about the nature of coding software into existence, we drew the distinction between two forms of creating software: one where you plug into the existing pattern you see and trial-and-error your way to a solution and the other where you dive into each piece that’s already there and understand it for its underlying form, a term from Art of Zen and Motorocycle Maintenance which means the function it has rather than just the appearance. Beyond software, I think this mental model applies to all work that involves creating, bringing something to life that wasn’t there before.
I’ve started to think about these two modes of creation as triaging tasks vs. realizing an idea.
The former entails the kind of work that you typically imagine for a standard project—picking tasks off of a Trello board or JIRA epic or other endless backlog of issues in YATMA, and finding the right code pointer to see the shape of what you’re working with. Typically, there are already examples of the kind of thing that you need to do, and it’s a matter of copying + pasting an existing example and tweaking the levers, and adjusting the details until it fits what you need for it to do. There’s a lot of benefits to this approach, namely that it’s extremely efficient. There’s a low upper limit on how much context you need to gather before getting to a solution that works for you. It’s why Ruby on Rails was one of the most popular web development languages for so long with their principle of “Convention over Configuration,” which pares down the number of decisions developers have to make by hiding “the cruft” for you. Because of this, it’s very easy to get started for simple tasks in a Rails codebase since there’s a lot of preformed templates and oiled processes for you to follow. Outside of software, it’s why the clickbait article format is so easy for people to get started with creating content with. There’s an understandable shape that is easy to plug and play. When things go wrong, it favors a shotgun debugging approach, a trial-and-error method of figuring out what’s wrong, because it’s a quick way to approximate where to look (also a symptom of our current debugging tools, where available, being heavy friction for users which makes us feel that they are beyond understanding). The benefit is that you only need to take as much context as needed for the task at hand to maximize the time efficiency to completion. This explains why it’s so natural for an organization to slowly completely move to this mode of operation as it grows because it’s the most efficient for operating in the context of a large system, specialists over generalists. However, the downside is that this mode of operation makes it very difficult for you to do anything outside of the cordoned-off area of expertise that you’ve developed. When things don’t fit the pattern at all, it becomes a problem because your typical thought branches start from the wrong basis.
On the other hand, realizing an idea is approaching the problem at hand holistically, seeing the end idea that needs to be achieved, and working from every foundational piece to bring that vision to life. This mode of creating involves understanding the components of a system at a level of depth significantly beyond the surface and using that understanding to decide when to break the “rules” of traditional operation. In software, this means going beyond copying the existing patterns in place by digging deeper into how and why those patterns were formed, following the rabbit hole to a point where the purpose of the pattern is clear. In writing, it means taking pieces of genres that you like, removing the parts that aren’t, and playing with seemingly ridiculous mashups of ideas to craft a compelling world and story. The essence of this mindset is divining the purpose of different components of a creation because the purpose determines what the component does well and poorly. With this understanding, you’re able to mix and match to find a custom solution that fits the core problem of the idea you want to realize. This kind of thinking is essential to true innovation and creativity in terms of introducing entirely new paradigms into the world. Cryptocurrency is an example of digging deep into the foundational aspects of a modern-day economy, taking the pieces of computer science like cryptography to form unbreakable contracts and taking the pieces of economics to create a scarce resource.
It’s easy for us to fall into the triaging tasks mode by default, especially given our societal focus around the prestige of achieving quantifiable goal posts and the obsession around productivity porn. And while it is great for moving quickly and executing on items within a certain pattern and scope, you end up having to pay the cost long-term when things don’t fit the pattern that’s been engrained into your mind. The realizing an idea mode of creation is essential to bringing entirely new creations and ways of thinking into the world. Training to default to this mindset, especially when diving into a new space or system where there are a lot of moving parts that don’t require understanding, is key to setting up the proper foundation to build on. It requires a departure from the norm of getting things done fast and having reaching the milestone be the end-all-be-all of your work, but it’s worth the early investment. When you’re starting out and the stakes are low is the perfect time to invest in picking away at that dense fog of unknown surrounding these components, and if you keep at it, one day you might be surprised at how solid your understanding of the entire flow has become.
As I’m coming to a completion, perhaps this is just a more anchored reframing of the modes of thinking I explored in my last piece as it parallels a lot of the same contrasts I made there, so if you haven’t read that, it might be worth a skim.
This is the 11th installment in my experiment of publishing raw, lightly edited mini-essays every day towards achieving 100 public pieces. Check out the rationale and the full list here.
I think this idea of triaging tasks vs. realizing an idea has a lot of similarities with growth as a software engineer. Entry-level engineers are normally tasked with the more straightforward tasks that have established patterns, but as you grow and become more familiar with the codebase, you start getting assigned projects that are larger and more ambiguous, which requires understanding existing systems and knowing which components to change in order to implement the new project.