A few years ago, I decided to do something completely unnecessary and travel to Chicago for a series of guitar workshops. It was 7 days of just hanging out with other guitarists jamming and learning from other very talented musicians. Probably not the most amazing use of my savings, but I enjoyed myself nonetheless and learned a lot about writing music and playing with other people.
Of the things I learned in that week, the most useful has been something the instructor called the “Four Personalities”, a way of breaking down the creative process and trying to get through blocks in your songwriting. I’ve found that it matches some of the things we do in software engineering, and have since adapted the way I work to somewhat mirror this process.
The Personalities
The four personalities are the madman, the architect, the carpenter and the judge. All have their place, and should be kept in their box until it’s time to bring them out to do their job.
The Madman
I remember one of my first tutorials in my discovering engineering course in first year of uni, they said “sit down and start yelling ideas at each other”, I feel like the madman is a codification of that exercise.
The madman is the dreamer. There is no rhyme or reason for his ideas, but with the rate that they come forth from him, you’ll strike gold at some point. Commit every thought you have about the problem to paper, no matter how stupid, you can pick the best ones later.
In music, this would be all the riffs, melodies, solos, chord progressions, etc that you might figure out while just messing around with your instrument. Maybe a little 3 or 4 note lick, some weird chord you really like, or a solo idea.
In software engineering, this might be sitting down to talk about a new service or feature, or a spike to produce a proof of concept or prototype. This is all spitballing, no idea is too stupid for the madman because he wants it all.
The important thing to note here is that the madman should not be trusted to produce something that works correctly, and will require input from the other personalities to ensure the best result.
At the end of this process, you’ll have a mess of disparate ideas that the next personality can start to sift through and shape.
The Architect
The architect looks at the madman’s work and starts picking out the useful ideas and putting them into a blueprint. They may sift out the illegible scratchings, decide what will and won’t work and generally just bring coherency to the ideas.
It’s common (at least in my personal experience) that the madman comes back to play at this point. As the ideas start to take a better form, you will notice different patterns and ideas come along. My general strategy is to note these new ideas down then and there to appease that part of my brain, and let the architect bring them back up at the appropriate time.
As a developer, I tend to view this as something similar to prioritising your work board and doing estimations. This forces you to pare back your ideas and decide what’s important and what’s not, as well as how the whole thing fits together. As for the music side, this would be grabbing those scratchings you’ve made and putting them together into a coherent order that flows nicely, as well as building the basic accompaniment by the other instruments.
The next step is to take this template, and put it all together.
The Carpenter
The carpenter looks at the blueprint from the architect and gets to work. It’s just their job to do what they’re told, they don’t take any liberties with the broader plan, but will add their craftsmanship where appropriate. Things like small embellishments and runs to make individual parts fit together a bit better are within the realm of the carpenter, and in fact a core part of their job.
Every programmer is familiar with this part, and it’s just as natural for you to spot issues in code as it is to find something just impossible when you go to record your music. Don’t be afraid to kick it back to the architect to rethink it a little if the carpenter is having issues making plans a reality.
Finally, the hardest part is upon us
The Judge
The judge is here to provide constructive criticism, and should definitely not be let out of their box until there is actually something complete for them to judge.
For an engineer, this will be when you test your code and submit it for review. When writing a song, it’ll be when you’re listening back to your own music and trying to pick anything that sounds off or needs improvement.
It’s incredibly important that you keep your criticism constructive, the judge isn’t here to tear anyone down, they’re here to ensure you only release the highest quality product.
Should there be issues, you will need to kick the work back to either the architect or the carpenter. It may be there’s just not enough oomph in a drum fill that the carpenter will need to fix, or maybe you discover that an existing client service expects a certain API interface which will need to be analysed by the architect.
How This has Impacted my Creative Process
After learning this method of writing and realising it could just as easily apply to my professional life, I set about seeing how I could make it work for me.
I’ve found that by making sure I keep notes on my ideas, things don’t get lost and it’s easier to see what’s actually important. I’ve also come to really appreciate the art of giving useful advice and criticism to people, and I feel like that’s made me a much better team member.
Distilling my notes before actually implementing anything is a bit of a time sink, but I believe it’s also helped me identify more issues before going to code it and hitting a blocker that just can’t be solved.
I think it’s important to understand how you work, and this is a system that’s certainly helped me in the last 5 or 6 years since I learned it. I’m also better able to make sure that I go into a task with a clear attack plan.
Limitations
Sometimes I’ve found that this process can be a bit too burdensome for small tasks. For example, small bugs or loading a CSV into a database table that don’t require much thought.
I’ve also found it can be difficult to keep the madman and judge in their boxes until they’re called for, often criticising my code before it even does anything or trying to stay on task building when I have a few new ideas.