Embrace a creative practice by doing low-stakes, reflective personal projects. Create and allow your creations to be imperfect sketches. Take advantage of the freedom from pressure and give yourself space to rest, reflect, and learn. Mastery requires it.
Keeping a software sketchbook ¶
A few weeks ago–with some free time during the Thanksgiving holiday–I sat down to write a static site generator.
The world didn’t need another one.
Especially the bare-bones and completely undistinguished one that I ended up writing.
The project doesn’t really contribute anything new to the world; in fact, there’s not much that is novel in most of my hobby projects. And that’s on purpose.
They are sketches. I’m not particularly proud of or attached to them, and rarely do I do any hobby work that has any complexity or is algorithmically interesting.
So, why?
There’s a bunch of typical reasons that are given for this sort of hobby work: maintaining a growth mindset, staying malleable in tools and technologies, “staying up-to-date,” etc.
But the way that I think of my hobby work is that it is my creative practice. It is a way for me to rest in my art as an element of a path to mastery.
One could argue that my time would be better spent contributing to open source projects. Things that I use, or things that others may find useful1.
However, I think there’s a lot of value in these types of small and unpolished toy projects, and that their value is derived precisely from the fact that they are small and there is no expectation that they are polished, or even meaningful.
As professional software engineers, one of the things that we must recognize is that our brand of engineering differs from other disciplines. Though we share a disciplined and scientific approach to developing technological solutions, software engineering has a high degree of creativity, and the lack of physical constraints leads to a malleability and practically-infinite solution space.
Our best-practices and principles are abstract—DRY, Law of Demeter, SOLID, design patterns, etc.—or loose suggestions. Software engineering is a discipline of trade-offs, and our touchstone texts on software design provide situational advice, at best.
In other words: we don’t have handbooks; we have style guides and requirements.
So, as a professional in a creative discipline, I think having a creative practice is an important part of my growth. Just as artists have sketchbooks, so do I—my hobby projects.
Resting in our art ¶
These software engineering sketchbooks are more than rote practice of technique. By creating them, we create spaces for reflective practice.
Solving new—and even toy—problems forces us to practice our creativity, adaptive thinking, and problem solving. And avoid stagnating. We talk all the time about the importance of and the why for having a “growth mindset.” Exploring new spaces through low-or-no-stakes projects is a perfect example of how.
But these sketchbooks are also our personal galleries. Places to spend time idling and processing—resting. When we leaf through our projects, or sit deep within one, we give ourselves time and space to reflect on our work.
This sort of pressure, judgement, and risk-free reflection and consideration is often not possible in our professional work, where, at the end of the day, we must deliver some product to stakeholders. In our personal work, there is no stakeholder, no urgency, and no risk.
We can ask ourselves what worked, or what didn’t. We can start a project anew with a different approach, informed by our reflection. This allows us explore, discover, and evaluate trade-offs in algorithms or design—real confidence for how we might improve our work.
When we experiment with new patterns, play with new tools, or work in areas of the stack that we don’t typically work in, we develop theory. Traversing and building abstractions allows us to generate, discover, and evaluate theories about principles and ergonomics.
What made this code easier to write? To understand? More performant? With looser synchrony? And how may those ideas be translated to new domains or problems?
This sort of theory crafting and application is not often possible or emerges more slowly when our tasks are scoped to a particular product or feature.
Supported by educational psychology ¶
Constructing, applying, and evaluating theory is required for mastery because it is how we learn and generate knowledge.
It is probably an uncontroversial statement to say that we learn by doing. But what does this mean?
Kolb’s learning cycle ¶
The idea of learning cycles in educational psychology has existed for almost a century and many different cyclical models for learning have been proposed. The one that I—and I presume many educators (or former educators 😅)—are familiar with is one due to Kolb.
In Kolb’s model for experiential learning, knowledge is derived from reflection about experiences; the learning cycle describes how. It is comprised of four macro phases:
- Concrete experience: Something happens. We encounter something new, make an observation about the world, gather data from experimentation, etc.
- Reflective observation: We reflect upon this experience. We consider whether the experience was something we expected or not. We think about how it aligns with what we already know about the world. What knowledge do we have that support the experience? Or is it contrary to what we know?
- Abstract conceptualization: We try to incorporate this experience into our existing knowledge. We develop or augment theories and processes. We create new hypotheses and beliefs about the world.
- Active experimentation: We test our hypotheses. How can we confirm or refine our new understanding of the world? Can we add justification to our beliefs? What new experiences might help us understand more?
The model is cyclical in nature: as we encounter more experiences in the world, we iterate. The importance of the cyclical nature is not just its repetition, though, it is the relationship and dependency between each of these activities.
Just “doing” isn’t enough ¶
What the cycle means to us is that knowledge is derived from traversing the entire cycle, not just elements in isolation.
Doing, alone, doesn’t generate knowledge, it is the reflection and subsequent rethinking of what we might do—and then testing this—that does.
So, is a toy project like a static site generator really meaningful to my growth as an engineer?
I have certainly worked on infinitely more complex problems than this and written infinitely better code to solve them.
However, doing this one-off project and allowing myself the space to write code without any sort of expectations has permitted me the time and space to reflect on the process. And to think about what I would do differently next time.
And by keeping a sketchbook and continuing to do these sorts of toy projects, I ensure that there always is a next time and that it is a next time free from expectations. A next time that will also allow me to rest and reflect on my (shitty 😉) work.
-
Or that maybe I should be doing more complex projects, or ones with more interesting algorithms, things that might build a more interesting portfolio than a skate dryer. That’s orthogonal to this post. 😅 ↩︎