In my previous post I outlined a broad model on the principles of successful individuals and teams. I’d like to dig into the “getting stuck in the weeds” part of that post.
The search for correctness
I was introduced to the Haskell programming language around 4 years ago by a colleague at work. I was immediately curious and that curiosity has never subsided. The idea that you could eliminate entire classes of software bugs by applying mathematical laws and proofs inherit in your program and have those things checked before that code ever made it into a production system was very appealing to me.
Up until that point, I had primarily worked with languages that were not capable of expressing these properties. So, you can imagine my surprise to learn that all of the time that I was spending dealing with bugs in production code could have been avoided by choosing a different approach to building software.
My goal was clear - to use this new way of thinking about software into my daily work and have it impact in a positive way - economically, socially, personally.
How much do I need to know?
This idea of “a better way to build software” consumed my thoughts for the better part of 2018.
As I kept digging and learning more about the language, my feelings started to change. I started thinking that:
- I was stupid because I didn’t know these things before.
- I wasn’t smart enough now, because I couldn’t grasp new concepts.
- I would never be able to get to a point where I would be allowed to use this language and have my work be considered to be of a high standard.
There’s more to this list but these were my primary thoughts at the time. Whilst these existed in my mind, I was unable to stop myself from continuing on the journey for correctness.
This led to:
- putting an unreasonable amount of pressure on myself to know everything.
- burnout - where I wasn’t motivated to do any programming for some time.
- working late most evenings and losing balance on other priorities that were (and still are) important to me.
I felt like that I wasn’t going to be able to do anything useful using Haskell unless I fully understood All the Things ™
Understanding the landscape
At some point I had lost perspective. My original goal of wanting to eliminate bugs from my production code had disappeared as I became interested in ideas, that led to other new and interesting ideas.
I was introduced to the world of type safety and the level of safety that you could achieve in writing your libraries and applications.
How far down the rabbit hole would you like to go?
Image credit: Blog post on Finite State Machines by Oskar Wickstrom
Don’t get me wrong, this is a valuable exercise - especially if your goal is to solve problems at their core. In that case, staying with the problem longer will allow you to dig into it deeply and find real truth.
However, I was essentially engaged in the biggest yak shave of my professional career and in that context I needed to revisit my intentions and goals. I had two distinct thoughts after taking a step back from it all.
- That what I had already learned in the space, if applied, would actually result in a vast improvement in the values and objectives that I was reaching for.
- That the additional in-depth knowledge that I had been gaining, although useful, didn’t have a practical implementation yet, and would only push the improvements slightly further than the initial boost.
Lessons learned about learning
I was sitting somewhere in the “Valley of Despair”, where I had climbed the initial learning curve, and had a very sharp fall into the valley once I could see how many unknown-unknowns had been brought to my attention.
What I didn’t realise is that the knowledge that I had accumulated was already enough to make a start on realising my goals.
I had sunk a lot of time and energy into pursuing a vague idea I had of “the perfect way” to solve fundamental issues in software. I also coupled this to a dangerous idea.
If I can’t do this right, then there’s no point in doing it at all.
This created a stressful learning environment for myself which turned out to be rather toxic.
This caused me to realise that something strange was happening, and pause for a moment to consider the following:
- How did this happen?
- Why did I lose sight of my goal?
- Could have I prevented it?
- How could I stop this from happening again in future?
Think Big, Start Small
You want to become a concert pianist - do you sit in a room and practice all day? Maybe. But that is only one part of the puzzle, and will only get you so far. You need to perform. You need to put those things that you’ve learned out into the world to see how it behaves when it interacts with other things, ideas, people.
The mistake I made, was thinking that I shouldn’t be writing code, when I knew that there were more concepts available that were “better” than what my current skill level would allow.
What is really interesting about this - I knew this already from my music career. You get a piece of music, you learn it, you practice it, then you perform it. It’s the same process whether you are a beginner or a seasoned professional.
By remembering this - I can be kinder to myself and develop an understanding that it’s OK to perform, regardless of your skill level.
The trick is to be honest and humble with your performance. Be open to continued learning at all levels instead of attempting to learn everything at once, and subsequently never putting your learnings into performance.
“Perfection” isn’t something that you achieve immediately, rather, you can get closer to it by taking small steps, consistently, one at a time.
Thanks for reading!
Final note: I have to express my gratitude and say thank you to those who spend their precious time really understanding ideas and concepts at their core in order to create tools that are freely available for others to use to create positive and meaningful impact in the world.