Being Vulnerable

I’ve made tons of mistakes over the years.  We normally call them bugs, but since around half had to do with code and half with human beings, we’ll label them as mistakes. It’s funny, I never remember bugs I’ve created and fixed in code (unless production went down) but I always remember social faux pas or missteps I’ve made. Maybe that’s because I can’t fix them after they’ve happened.  There’s no source control, no continuous delivery system, nothing to repair the damage except, “I’m sorry. I won’t do that again.”  The damage is still there, the bug isn’t fixed, there’s just another guard clause added to hopefully not trip it again.

I don’t say this to minimize the value of an apology.  If anything, it makes me want to learn how to apologize better, since I know it’s going to happen at some point, no matter how hard I try.

I wasn’t there five years ago.  Five years ago I was sure of myself, my ability as a programmer, and most definitely the best estimator I’d ever encountered.  I was that good. So good in fact that I kept the Army-induced confidence in all of my conversations, even when there were internal doubts.  I will say this for the Army, they know how to make you feel confident about your abilities.  It’s easy to dismiss most business ‘crunch time’ as it doesn’t really come close to what I went through in the military.  That disparity made me confident, and that confidence made me arrogant about my abilities.

And then that arrogance came crashing down all around me.

The project itself was a new piece of software for the company I worked for, on a project where I was the sole day-to-day back-end developer in a new language and new framework, and I had no idea what I was doing, but I was too arrogant and too scared to tell anyone else.  Today, that amount of code I wrote would have taken a quarter of the time, but then, not knowing anything and not even knowing the right words to search for, and being too scared of showing my vulnerability to ask others, I just plowed right through it. I didn’t ask for help, didn’t say to anyone that I was ‘in over my head’, and I didn’t show that vulnerability to anyone.

It’s no surprise then that everyone started to notice that the project wasn’t finished yet; that we were behind, and that I wasn’t as good of a programmer as I had led others to believe (arrogance masked as confidence has serious side effects).  At that point, the damage was done.

Trust is the glue that holds software teams together.  My teammates had to trust that I’d tell them when I needed help, or when  I was in over my head, or when I’d over-promised. That trust was broken because I was scared of being vulnerable.  Ultimately, It took a lot of time to repair that trust; but even with all that effort; there would always be that mistake.  Unlike a bug in my code, I couldn’t just fix it, check it in, and never have to think about it again.

I thought vulnerability was a weakness.  It wasn’t. It was the key to trust. It was the key to feeling like I was part of the team. It was key to delivering the product on time.

Ever since that incident, I’ve taken great care to be more open and vulnerable to my teammates, even going so far as to saying very clearly in interviews and team meetings what I’m good at and what I have no experience doing.   To break down the fourth wall for a moment, this is the point where I should talk about the list of things I’ve done; or how you can be a better software developer, or person, or whatever.

But I don’t have a checklist. I don’t have bullet points. I don’t have any insights, except to say that I’ve fully embraced being vulnerable. I never used to be OK with talking about my weaknesses, and now I wonder if I talk about them too much.  It hasn’t negatively affected me yet, but that fear is always there that it will.

Vulnerability means constantly reassessing my abilities; and focusing on my weaknesses.  It means sharing that with my teammates.  While there’s always a fear of rejection when I do that, it’s far better than the alternative.

Leave a Reply