Stop me if you heard this one before, you are working on a code project, and you really want to make this one perfect. You spend a ton of time brainstorming ideas to make this code “future proof”, this code is going to be elegant and perfect, and the code that will last forever.
Or here’s another one, you open up a project you worked on a long time ago, and when you look at the code it is just awful. I once saw a quote in a software comment that says, “When I wrote this, only God and I knew how it worked, now only God knows.”
Now both of these statements are extremely common among a lot of engineers I know and have worked with, and I’ve fallen into these traps myself (a lot), way more than I care to admit.
But over the past year, I’ve come to the conclusion, that these types of behaviors are fool’s errands.
I can’t tell you the number of times that I’ve seen this confirmed for, and that these type scenarios never lead to a positive outcome. And if we’re being honest, the past decade with the adoption of agile processes, in many ways addressed these same problems. Waterfall as a development methodology is built on this falsehood, so why do we continue to chase this “Holy Grail” that always turns out so poorly.
Realistically, I have found that these situations lead to either:
- Setting unrealistic expectations and forcing additional stress on yourself to deliver.
- Making it really easy to fall into imposter syndrome.
Now I’m not writing this and claiming to be some kind of psychology expert, all I wanted to do here is share my own thoughts and feelings on this, and honestly your mileage may vary, but this is based on my experience.
The simple fact I’ve come to realize is that Software Development is a temporal activity, like any act of creation. At the end of the day, all you are capable of doing is creating the best code that you can at the present moment. Period.
Any act of creation, whether it’s writing, art, architecture, etc, all have one thing in common, once you go through the process, they are frozen in time. Let’s face it, the Mona Lisa isn’t going to change, and any work being done on it is strictly to maintain it.
When you boil it down, at the project level, Agile focuses on this through the concept of “Definition of Done”, or a “just ship it” mentality.
But I would argue that this mindset needs to extend much further to help prevent ourselves from inflicting burnout upon ourselves. Carol Dweck talks about this in her growth mindset to a certain extent, specifically questioning the idea that talent is fixed, and pointing out that we as humans have the ability to grow in our ability to do the things we care about.
Let me give you an example, there are whole college courses that talk about the differences between Van Gough’s work over the course of his career. The simple fact is that every day we get better at our craft. So ultimately, it’s important to embrace that coding is no different.
My point in this post is this…it’s not worth putting the stress on yourself to build something that’s going to “stand the test of time.” Remember that at the end of the day, the best you can do is the intersection of these constraints:
- Resources – The tools you have at your disposal.
- Skill – Your ability to do the thing you are trying to do.
- Knowledge – Your knowledge of the problem being addressed, or the environment your work will live in.
- Time – How much time you have to create the thing.
- Focus – The number of distractions getting in your way.
- Desire – How much your heart is in the work.
These 6 pillars are ultimately the governing constraints that will determine the level of work your going to do.
I have been writing and re-writing this post for a while, but as we approach the end of 2021, I’m feeling reflective. My point is this, when you do your work, or build your solution you need to embrace the idea that you are not going to build the digital equivalent of the Great Wall of China, and your work is not going to stand the test of time. There will be new technologies, techniques, and even learnings you will be bringing back. So don’t put yourself through that pain, rather do the best job you can, within those 6 pillars, and move onto the next thing.
When you start to consider this, if you’re like me, you will realize that you are free to do the best you can, and not put that additional pressure on yourself.
The joke I tell people is this:
- Past Kevin is an idiot who writes terrible code and makes bad choices. And he likes to procrastinate.
- Future Kevin is a genius who can solve any problem in an elegant and amazing manner.
- Present Kevin is stuck in the middle, doing the best he can, and trying to figure out how to get it done.
I wish you all the best in the coming year, and hope you have a great holidays.
Top comments (0)