Stop Beating Yourself Up and Embrace Failure
If you have been a software developer for some time, you probably have a folder or multiple folders full of unfinished ideas and projects. Or you could have many repositories where you had commits and branches, and suddenly that repository was forgotten. Or you have some cloud service that is shut down and you are having trouble remembering why it was there in the first place. And there could be any number of reasons why your work at the time never saw the true light of day.
I’m here to tell you that there is absolutely nothing wrong with that.
What is the Michelangelo Phenomenon?
Coming from psychology, Drigotas et al. (1999) states that the Michaelango Phenonmenon is when two partners influence and shape each other to their ideal selves. The ideal self can be described as the conception of ought self, or the ultimate version that an individual wants to be.
This phenomenon is named after the Italian Renaissance artist Michelangelo and his sculptures. It is said that the blocks of stone that Michelangelo chipped away reveal the stone’s “ideal form”. During the process of creating that sculpture, the artist is also, simultaneously, one step closer to their “ideal form”. In this context, the stone is creating the artist just as much as the artist creates their vision for the stone.
Bringing this back to software engineering, all of your unfinished or discarded work is part of the journey of creating who you are today. This can be anything from a software program that is riddled with bugs, a web application where the cascading style sheets are not lining up just right, or a service running on your local machine that is multiple months old (I am guilty of this). Every pet project you work on is another stepping stone in the direction of your next big win. This helps carve out that journey ahead when it does become time for you to tackle that giant project. You have already seen what systems need to be built, what tickets need to be put in, and what compromises need to be made to get the project across the finish line.
If you still have guilt over your cobbled mess of projects, that’s understandable. I have plenty of projects that I have worked on that were never truly finished. But I am confident in saying that there is some reason why you picked up something, put some work into it, and get left behind. It could just be because we have other priorities in our lives that we have to attend to. It could also be that you attempted something you weren’t quite ready for yet, and you need to go back to the fundamentals before you are truly ready to tackle it.
In contrast, it is easy to look at some of the greatest works of our most famous people and compare yourself to them:
- Michelangelo - Pietà, Statue of David
- Vincent van Gogh - Starry Night
- William Shakespeare - Hamlet, Romeo and Juliet, Macbeth, A Midsummer Night's Dream, etc
- Sir Issac Newton — Law of Universal Gravitation, and everything else
- Sigmund Freud - Id, Ego and Superego
- Antoni Gaudi - La Sagrada Familia
But the thing you do not see is all of their unfinished work. You never get to see the thousands of pages of failed equations Newton wrote. You never see all of the bad plays Shakespeare came up with. You never see all of experimental paintings Gogh went through. And you never see all of the unacceptable statistical results Freud had to contend with. This quotation comes to mind from Stephen McCranie, "The master has failed more times than the beginner has tried". And just to drive it home, this quotation comes from my former supervisor, "I've written more bad code than all of you have written good code".
When the time comes to approach that large slab of marble, all of your trials and tribulations will be worth it. And when that project is finished, that will become your Statue of David.
Building Myself
Taking a slight detour, one of the biggest sources of growth I had as a Software Engineer is utilizing Design Patterns and writing Unit Tests. At the time, I had bad habits I picked up when I was writing classes and methods out of Jupyter Notebook and trying to port them over to VS Code. What I noticed was that I had a cobbled-together mess of code that was not working well together. My code I had written was difficult to read. The classic problem of long-running if/else trees and nested conditional statements was starting to grow. It was like weeds were taking over a garden of vegetables. This is a bad sign.
This leads me to the topic of Software Design Patterns. Design Patterns are well-established solutions to commonly occurring problems in software. For the problem I was having, the specific pattern I needed to implement was the Template Pattern with Reflection. To apply the Template Pattern, I needed to deconstruct my entire project and build it back up from almost scratch. Embarrassingly, this process takes way longer than I thought it was going to take. And there were several times I wanted to throw away the idea if applying the Design Pattern and go back to my garbage code because I knew it worked. But I pushed through it and got it working again. This time, it was cleaner and easier to read. Refactoring that project taught me the value of not being afraid of starting over and building it back again.
In order to take that next step, my current coding style and philosophy, what little I had, needed to be burned away in order for something better to take it's place.
After that, writing Unit Tests is taking it to the next level. Now that I have established the idea of writing clean code, it is time to tackle writing robust code. This is when I stumbled upon one of the chief tenants of UNIX Philosophy, "Do one thing and do it well". This is when the habit of abstracting core components of my application into specific sets that are similarly started to come into play. I was naturally breaking methods down into a single piece or function. This made testing easy.
And best part about getting things down to their smallest component is that it forced me to be more deliberate in the software writing process. Each step that is written in a project has a methodical approach. The Unit Tests write themselves now. Classes and methods fit and work together better. Getting solid code coverage reports from the get-go was possible.
Embedded in that journey of learning Design Patterns and Unit Testing, was tons of reading and staring at errors. I know there were times when I burned hours trying to get a Unit Test to pass properly and nothing I was doing was quite working. But with enough time and perseverance, I was able to get things to work properly and move on to the next thing.
Looking Around You
Coming back to the main topic, to get to the next level, you have to open up that IDE and get hammering at things. All of the documentation, StackOverflow posts, and blog articles need to come together to produce the next big thing you're going to tackle. And you might have to go way outside your comfort zone to make that next step. The thing that matters is you pick a topic and you go all in.
Just to get the juices flowing, all of these make for great project ideas that you can deep dive into:
- You are a Front-End Developer looking to get a better understanding of SQL Databases:
- You want to learn about standing up applications and systems in the Cloud:
- You want to tackle the automation of Kubernetes and DevOps:
- You are just starting off and want to learn the ropes:
And there are many more topics and places you can look into to get that next spark. The tough part is knowing where to look and figuring out how to begin. The good part is taking the time to think through what is missing in your skill set or what part of you needs more refining. Once that's figured out, it is time to start installing and building.
Just to reiterate, getting this stuff on the first try is unlikely to happen. There will be hours of staring at errors, chasing down random posts, and searching on multiple search engines. Hours will be burned stuck on a single issue. And that is when the emotions will come into play. Anger, frustration, sadness, the whole nine yards. The worst thing that can happen is you get far enough into one of these projects that you hit a point where you cannot go any further, and you have to tear it all down.
That is equivalent to crumpling up a piece of paper and throwing it in the trashcan bin.
And then you start it up again. And again. And again. You will have to do this as many times as you need to until you finally get traction. You are achieving something worth feeling proud of. The growth can be felt after each big win.
Where does that leave us?
When you think of all of the surfaces that an individual can work on, all of them start as a blank object, and have some conclusion at the end of that journey. For painters, it is a board of white canvas. For home builders, it is piles of lumber. For thespians, it is an empty theatre. And for software engineers, it is a blank IDE and software solution. Even after years of experience, there's something magical about starting something completely fresh, dipping that paintbrush, and leaving brush strokes.
When you sit down and think about it, bringing new things into the world is an unusual experience. Not only are you forging something out of nothing, but that very thing is also constructing you at the same. You become defined by the thing you are creating. The style of your highlights. The depth of your shadows. The numerous layers of paint you apply as you blend everything. And once you take that final dip of paint into your water cup, and dry it off on the towel, you stand back and marvel at what you created. Art becomes the mirror image of yourself. You appreciate all of the fine details and mistakes along the way. You find areas you could improve on. Maybe you go back into the world to find more inspiration before you tackle your next project. And when you are ready, you prep everything and go back at it again.
Building software is the same way. There is never a point where a piece of software has achieved perfection. It is taking everything you've learned so far and applying it to a single solution, or a larger architecture full of systems that work off of each other. Time is a limited resource. It is impossible to get it all right on the first try. What is important is sanding down the rough edges as much as possible and learning from that experience.
References
Drigotas, S. M., Rusbult, C. E., Wieselquist, J., & Whitton, S. W. (1999). Close partner as sculptor of the ideal self: behavioral affirmation and the Michelangelo phenomenon. Journal of personality and social psychology, 77(2), 293–323. https://doi.org/10.1037//0022-3514.77.2.293