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.