Blind Confidence
As developers, we often get put in difficult situations. Whether its finding solutions to distinct and interesting problems, designing complex architecture and code, or pushing back on extra features - the list is endless. However, these questions do have answers and are approachable. We can ask other team members or push back with the help of managers and scrum masters. But what about difficult situations where we don't even know the problem?
Most importantly, how can we cope when faced with them?
Blind Confidence
Disclaimer time. As developers, I believe we have a duty to ourselves to push ourselves and learn new technologies and standards. However, this should always come with a good support network, and at a frequency that fits the individual. Always put more focus on mental health over productivity and delivering work.
Story Time
There I was, a fresh, wide-eyed and eager graduate full of enthusiasm and energy. Well, at least the graduate part is true. I had joined a new company as a developer and was getting settled in learning the basics of developing on their internal systems. This was a nice easy entry into the company, and I was enjoying it just fine.
One day, I get pulled in to a meeting discussing a new FinTech startup client that I could potentially be working on. Amazing! I was one of the first few to be put on a client in the office, and the project was 100% greenfield - we had complete control over everything from the tech stack choices, architecture and the infrastructure (Not that I understood much of that either way).
Fast forward a few hours and my mindset had changed a little:
Along with 2 other developers, we tasked with building and deploying 4 different containerised NodeJS WebApps to AWS, using container orchestration, best security practices and multiple different testing environments with a fully automated pipeline to Production. All behind a VPN.
From scratch.
In 4 weeks.
I was responsible for designing and deploying all our pipelines and infrastructure.
(Imagine a '2 people step back, leaving one in front' sort of situation)
So what happened?
Needless to say, this wasn't something I expected within the first few weeks of employment. I had barely come across the terms 'pipelines', 'Infrastructure' and 'DevOps', yet I had somehow become the leader within the team for these fairly crucial parts of the delivery of this project. Whilst I had an okay support network around me - mostly technical, going into the project I was naturally terrified from Day 1.
After an incredibly intense 4 weeks of:
- Teaching myself AWS, CircleCI, and Docker
- Creating templates upon templates of CloudFormation
- (Rigorously) Managing stakeholders
- Daily sprints
We were finally done.
Through blood, sweat, and tears we somehow managed to deliver the project. Fully automated pipelines pushing 4 different docker containers through 3 environments with automated testing gates at each level - straight to production. The dream.
But it wasn't all plain sailing. Needless to say, I spent most of my time stressing, worrying and generally being anxious over almost everything I had to do. I made a lot of mistakes, broke a lot of things (production), and made a bunch of long-lasting friends.
But what did I actually learn?
1) You will never know everything
Simple and obvious, yet incredibly important.
As developers, especially ones new to software delivery, it can be incredibly daunting to see new technologies rise up into the forefront of a developer's core skills only to fade away within a few months/years. Especially with experts appearing out of nowhere suddenly knowing 'best practice' before you even have a chance to understand what that technology even does.
It's easy to constantly feel behind the curve with libraries and frameworks (Hello Javascript?).
Even worse is to then to relate this understanding into a lack of skill.
This will never change. You will never understand everything.
Harsh words. Unfortunately, chasing the dream that you will eventually 'complete your learning' leads to feeling inadequate, incompetent, and can allow the general feeling of technical inability to leak into the rest of your work and personal life too.
What can change is the context in which you view your own understanding.
The lenses through which you view your own and others' work will change throughout your career.
As you learn technologies, you will start to understand the core underlying principles that tie different technologies together; be it languages, libraries or software architecture. You will start to see patterns emerging and understand shared concepts between libraries, and understand that the 'magic' you once saw was nothing more than levels of abstractions and software design patterns. You will work on both easy, and difficult projects - terms that soon become incredibly relative to your own skill.
As you work in a team, you will start to learn the communication, teamwork and empathic skills that are essential in creating a fantastic work environment. You will start to understand the impact of your work, and how skills not conventionally valued from a developer go a long way in a team setting. Not only this, but you will learn that skills outside of development vastly impact development skills.
As you pair program, you will understand the value of timely and constructive feedback - invaluable knowledge that you could not have gained without working with different and diverse groups of people with contrasting minds to your own. You'll gain insights and viewpoints that you would not otherwise acquire without deep interaction and co-working.
Of course, there are infinitely more areas to improve upon, but the message stays the same - all these skills reside on a scale of knowledge. Everyone starts near the bottom of the scale and works their way up - with other skills contributing and making it easier along the way.
As developers, we should aim to understand as much as possible, whilst also being content with the knowledge that we will never be able to know everything.
2) Accept and embrace ambiguity
New challenges often represent much more than just the nervousness they impart.
By far the biggest issue I found throughout the project was not my technical understanding of tooling, or architecture, or even the behemoth that is AWS.
I wasn't able to understand what direction the project would take.
Especially as a developer new to almost everything, I was unable to predict what the project would look like in a few days, let alone what the product would look like in a few weeks.
Whilst the work I did every day seemed uncharted and foreign; the end goal seemed extraterrestrial. It was not just another obscure task I didn't really understand, it was an end product in which the path was blurred out and the signposts turned the wrong way.
So to deliver I had to embrace that ambiguity. I had to accept that along with all the mental challenges and difficulties ambiguity brings, there are also many benefits. I was able to experiment and learn new technologies and concepts I otherwise would not have had the opportunity to learn.
Most importantly, I was able to then pass on this newly found knowledge to others in my team and office, and grow alongside all of my friends and colleagues.
An incredibly important aspect of this is support. Without a strong support network and foundation, it can be very difficult to keep motivation and confidence when constantly battling with ambiguous and challenging work. Ideally, someone who is more experienced or with a different mindset will be available for help and discussions - especially when you think there are too many unknowns.
Ambiguity forces us to either find solutions or get answers to difficult questions. We may not always be able to work through these on our own, but we should be confident approaching vague and uncertain problems and working towards a solution.
3) Comfort Zones exist, and they need to be challenged
"Work somewhere between swimming happily in the ocean and being chased by Sharks" - Jo Crossick
This is based around The Learning Zone Model.
In my eyes, this can be quite a dangerous topic to discuss - especially when describing how hard to push yourself and others. This is by no means a qualified opinion, it's simply what worked for me. As an action from this, I urge you to think about where you are currently sitting in the Learning Zone, and where you believe you should be.
Whatever work you do, it's necessary to have a baseline - some level at which you are comfortable and content with the work you are doing.
This baseline is incredibly important, and should always be in the back of your mind whenever taking on new challenges and workloads - it's your baseline for a reason. Perhaps you feel most at ease when doing repetitive tasks, or perhaps you perform and work best when you are being pressured under intense deadlines. However, if you stay at your baseline, you will stagnate.
If you are constantly doing tasks you understand or tasks you feel comfortable doing, on the surface you will feel content. You will never be growing nor learning as an individual if you do the tasks you already are able to do.
It will be difficult, you'll face challenges you won't immediately understand or be able to solve, but those are the periods in which you will grow the most as a developer and as a problem solver.
You cannot begin to learn new technologies without starting from effectively nothing. This is what the term Blind Confidence represents:
Understanding that it is perfectly okay to go into problems with absolutely no idea of how to solve them, but you should go in with confidence in your own ability to solve them.
Blind Confidence is my way of dealing with pressures and difficulties that I cannot understand before actually doing the task itself.
I urge you all to consider where you are right now, where you want to be, and what unknown challenges you will try to face to get you there.
Fast forward a year and a half, and I am now a DevOps lead within my office - providing guidance and support on Pipelines, Testing and Infrastructure. Without being put into those difficult situations, I would not even close to where I am today.
- Olly