You Don’t Have to Know Everything

I have a lot to learn.

This is one of the thoughts that is in the forefront of my mind more often than I’d like to admit! I’m still a relatively young developer, particularly for someone in a position of technical leadership, and (in recent weeks especially) I often suffer from the worry that I should know more. I feel like I’m not developing fast enough, or able to contribute to every discussion with the perfect clarity befitting of a technical lead.

This is a ridiculous notion of course. No one knows everything all the time. Everyone is learning and while you can be honest with yourself about the fact that you do want to improve, you have to allow yourself to not feel like you have to have all the answers. Because there will always be a more talented developer than you, and a lot of times you might have them on your team!

A while ago I watched a talk by Clare Sudbery, where she discussed how she dealt with being in a position where she didn’t always have all the answers for her senior technical staff. The talk is linked below.

I really enjoyed this talk and it resonated with me a lot. I’m fortunate to work with some very knowledeable people and there are often times where I just don’t have the understanding I’d need to advise or make suggestions based off my technical expertise. As a Technical Lead, it’s easy to feel like you should have all those answers. And that can be pretty daunting. Especially when you think about just how much there is to know. The thing that Clare points out is that that’s okay!

It is not your job to know all the answers to every question that could come up. Your job as a technical lead is to bring together a group of people with varying technical ability and try to funnel that into a constructive form. You want to hire talented people who have technical knowledge! That’s a benefit to your team. And then you want to work to empower that team, with knowledge and strategies that help the team share in the expertise they have. Clare goes into various strategies for teaching and building the skills of these developers. But, sometimes, you’re going to be the one who is going to be confused, and it is important that you are open about that confusion. Because it gives other people in your team tacit permission to open up when they’re confused, which creates opportunities for your team to grow.

So what do you do when you’re faced with a situation where senior technical staff are presenting problems and solutions that you don’t feel confident evaluating?

Ask the people involved to slow down and take the time to break it into pieces. My favourite phrase for doing this is something like “Walk me through that” or “Bring me with you“. I often find myself saying these phrases in meetings, while pair programming, or just in catch ups with my team. I really like these expressions (or any similar sentiment) because they’re a way to ask your co-workers to take a step back and realize that there may need to be a deeper explanation given. It doesn’t put any blame on anyone, for not explaining things well enough, or for not making sense or anything like that. It’s just an honest admission that, for whatever reason, I’m not on the same page as someone else.

It’s a well known concept that, as you become more experienced with any skill, you internalize the basics and those actions that used to take deliberate practice and effort, just become a feeling which you act on. This is what allows athletes to make split second decisions between a huge number of techniques, and also allows creative experts to make up entirely new things on the spot that seem to fit the moment perfectly. But because of this, you often find that experienced practicitioners of a skill find it very hard to break down, in the moment, why they chose to do the thing they did. They just do it. I’ve found the same thing with talented developers I’ve worked with. They’ll often answer a question by tackling the bit that they’re wrestling with, without really considering that other people haven’t gotten to that point yet. A lot of the time, this isn’t done with any malice, or even an understanding that it’s happened. It’s just that the answer was clear to them so they skipped the step. It’s important to be mindful that this could be what’s going on, and to not get frustrated with people.

It’s usually a blessing in disguise! As soon as you recognize that, that means there’s an answer to a question in the room and you can help everyone around you get to it. Even if you, as the technical lead, understand the same thing as your experienced developer, this is a great opportunity to say something like “Walk me through that”. In my experience, even if you are on the same page (and I’m often not!), there will be at least one or two people who would appreciate being brought up to speed but feel like they’d just be getting in the way of they said anything. Getting those knowledgable people to take a step back and bring people along can be a great way to help the team move forward together. It can also be a great way to challenge people, without creating a hostile environment. Earnestly asking someone to bring you to where their head is at, even when there’s frustration in the room, can be a fantastic way to convey that you’re honestly trying to work towards a consensus, and push things forward in the best way possible.

So the next time you find yourself in a situation, for whatever reason, where you are missing something, maybe give “walk me through that” a try.

I’d love to hear thoughts, phrases, and techniques on dealing with the moments where you don’t feel like the expert. How do you feel when it happens to you? Feel free to drop me a comment or message me, I’d love to hear from you!

Becoming a Technical Leader

In the middle of 2019, there was an opening at my job for a Development Manager position. Rather than take the role as described, I made a request to change my role to Technical Lead instead. I explained what I felt that meant (as my company had never had someone with that title before) and discussed it with our CTO. I felt that our organisation needed someone who had a responsibility to building a strong technical team, and to ensure that our day to day practice was as good as it could be. And I wanted to take more responsibility for that kind of thing. I felt that the Development Manager position was also important; someone responsible for the department and how it interacts with the rest of the company at a high level. I just didn’t want that to be my job!

Very luckily for me, there was someone else in the company who felt the same way but approached it from the departmental side. In the end, the role was split in two and I entered my current role as R&D Technical Lead. This was great! I had been allowed to take a position which let me make the changes I felt were important for the Development team. The company felt it was valuable and let me try.

There were two problems though. First of all, I was stuck on a big project which needed to be finished, but that was a legacy code nightmare. It took up almost my entire year to get through it, leaving very little time to think about other things. And secondly, I had no idea what I was doing. I’ve not been a Tech Lead before, and as a Developer, I’m still on the younger side. My experience is in developing for and maintaining a large legacy codebase in C++, and leading projects within that framework. This was a whole new ball game. I had a lot to learn.

Drawing of me with my back to the viewer looking up at two looming towers with the AWS logo on them
I drew this in 2018 when I was feeling out of my depth at a conference. I still feel out of my depth pretty often!

Fast forward to now, January 2020.

I have a lot to learn.

As I mentioned, that big project took up most of my year. No time to work on this role directly. But! That project has ended and I’m now in a position to think about what being a Tech Lead means to me and start my journey to be as good at it as I can be. So I thought I’d try to share as much of that as I can with you all, because learning together will be more fun than sprinting into the darkness alone!

What is a Tech Lead (to me)?

Early last year, I made the decision that I wanted to try to be considered a Technical Lead by the end of 2024. As part of that, I had to put a lot of thought and research into what people consider this role to be. There’s a lot of scope to move around in the Software Development industry and the structure and criteria of a job role are entirely defined within the context of the organisation that it’s a part of. This leads to an interesting issue where lots of positions with equivalent responsibilities have different names. This can make it tough to figure out what it is you’re trying to achieve, and also makes the conclusion you come to somewhat of a personal opinion.

For me, I think a Technical Lead can be described as the following:

“A Tech Lead is a Software Developer who is responsible for ensuring the quality of the technical output of their team is as high as it can be.”

There are a lot of things hidden inside that definition for me, and it’s still evolving as I learn more. So let’s break down that sentence.

“A Tech Lead is a Software Developer…”

This is very important to me! A Technical Lead to me is someone who is actively involved in developing solutions. Writing code and designing software. This is the day to day work of the team. If you aren’t aware of what that’s like, then you can’t be sure that it’s being done in a way that can create the best experience and best output, because you won’t know what the practicalities of creating that output are.

One of the reasons this role appeals to me over Development Management, or even CTO type roles currently, is that it stays close to what I enjoy; writing code. I don’t have to make excuses to justify that work. It’s core a part of the role.

“…responsible for ensuring the quality of the technical output…”

To me, this is where all the ambiguity lies. But it’s also where all the hidden gems are!

Ensuring the quality of technical output means so much to me. If you’re experiencing the development process on a day to day basis (as I believe you should be as a tech lead) then you’ll be able to experience things that slow you and the rest of the team down. Technical things in your solution is the most obvious thing to a developer. Framework improvements, refactoring, or architectural clarification. These are great and useful things to do that improve the technical output of the team by making the code that you should be writing clearer. And as a senior technical staff member, I’d be lying if I said the coolest bit wasn’t being a part of designing and implementing the code that the organisation needs. But these may not always be your pain points! This is about the quality of the team’s output, and the team doesn’t just throw out code into a void. It works as part of a larger organisation, or at least as part of a larger purpose, which means interacting with other functions to deliver what they need. You can write a bunch of fancy code, but if it doesn’t do what your stakeholders need because there was a breakdown in communication then it’s not very useful!

So to ensure the quality of the output of the team, you may need to look at your processes and find what’s slowing you down. Does it take too long to log and work on issues? That’s going to lead to less detailed issue reporting, which leads to more opportunities to get the work wrong. But as a Tech Lead you have the opportunity to deal with this.

Yet another way to ensure quality is about the people in the team. The best work comes from people who are comfortable and content. Not every member has to be a super passionate, high performing power house. That’s not realistic (and often not a healthy dynamic!). But to ensure the quality of your team’s output, you need to be ensuring that they’re growing, and in a position where they aren’t worrying about job security, or being made to feel unsupported or unwelcome. These things also come in the realm of your care as a Tech Lead, because they’re things that can drop the quality of your team’s output. Which is great! Because you should care about that kind of thing at every level, but as a Tech Lead you have the ability to try to do something about it.

Finally, a Tech Lead is responsible for all of that. If you’ve truly been given a responsibility, then that means you should also have the tools to be able to fulfil that responsibility. That’s great! It means that, hopefully, your organisation has given you permission (within reason!) to be able to make changes for the better. To spend your time on things that you believe will generally lead to a better working environment. That’s pretty cool!

“…of their team…”

This is the final part of that definition that I’d like to mention in more detail. A Tech Lead is the leader of a team. This means doing your best to exhibit leadership skills. Setting boundaries (to allow others to do the same), leading by example, and often times it can mean managing people. This is often the part that fills people who come from a purely technical background with the most trepidation. People are complicated. They’re unique, and messy, and interesting. And depending on what other roles exist in an organisation, it may be up to a Tech Lead to be responsible for creating an environment where those people can be their best selves. Even if there’s a dedicated manager or Team Lead to go alongside the Technical Lead role, there will always be a component of leading the individuals and building a team that’s conducive to the work you need to do. And in my opinion they should be one of the major considerations in driving your decisions.

Simple pencil sketch of a group of people high fiving

As you can see, a Tech Lead can be responsible for a lot of things. Which means learning a lot of skills in order to be able to do it well. I had intended to add the skills that I think I’d like to prioritise in my journey to be a strong technical leader, but I think this blog post is already a bit long! So I’ll leave that for another time. I’m sure you can see how amorphous it is as well. It depends on the needs of the organisation, your personal aspirations and temperament and the skills of your team. But it’s a great opportunity to build things that are interesting and a joy to work in; software and teams!

What resources have I started using?

As part of this journey, I started doing research on what people consider the role to be. Some of the following have been useful to me. Hopefully they’ll be useful to you too.

Pat Kua’s BlogDefinition of a Tech Lead – In the first developer conference I went to I saw a talk by Pat Kua which lead me onto his blog. He’s made it a focal point of his career to describe and empower the Tech Lead role. I highly recommend his blog and talks if it’s something you’re interested in!

The Lead Developer Conference – The Lead Developer Youtube – One of the conferences that I’d love to attend is The Lead Developer in London. This conference is specifically aimed at technical leaders, new, old, and aspiring to help them build high functional and content teams. All their talks are provided free on their youtube and I can recommend them!

Where do I go from here?

Finally, I thought I’d go through what my first steps on this journey are going to be. Personally, I’ve found an affinity for leading teams. It’s something I’ve had a lot of practice in, and building teams is something I enjoy doing. But as I said, a Technical Lead is a Software Developer first. And with only 6 years of professional experience, the technical aspects of the role or something I personally feel I want to be more confident in.

I have been developing in a C++ application for most of that career, but more recently I’m designing a system that will mostly be written in C#. As such, I’d like to really get C# knowledge under my belt.

C# Certification – MCSD 70-483 Exam – I’ll be starting the year by getting the Microsoft C# Certification as a way to guide my learning, and as something that I can use to prove that skill exists.

Attend conferences – I have been lucky enough to go to a few conferences during my career and each one was a pretty amazing experience. I was too nervous to talk to anyone else, but I feel like they’re a huge opportunity to learn, and inspire learning. So I’d like to attend at least one more conference this year.

Write Blog Posts – There is so much to know in tech (and in the world at large) and I’m always terrified my sieve like brain is going to forget all those amazing pieces of information that the studying, reading, practice, and discussing can give you. So to do something about that, I want to try to do more technical writing and personal ruminating.

So that’s where I’m starting. And that’s what I’m shooting for. I hope you’ve enjoyed joining me as I gather my thoughts on this. I’d love to hear your thoughts, experiences, and aspirations!

Comment below, feel free to share the article, or get in contact with me.

Photo of me in my study

Looking into Vim

Vim

Vim vs Emacs is one of the big fights in the Software Development vanguard. At least, apparently it is? I had only recently heard about Vim and Emacs tangentially from podcasts that discuss more of the recent news in the software world. I ignored it for a little bit, assuming that if I needed to know the knlowledge would find me in due course. But when it had turned up in most of my listening collection, I decided to find out what in the heck these things are and why everyone seemed to be fighting between them.

So What are Vim and Emacs?

Vim and Emacs, it turns out, are programs which allow you to navigate and edit text documents. At least, they are until you become fluent. In their post, Why I Use Vim, Pascal Precht describes the learning curve more like scaling a mountain and sliding down the other side. And from what little I’ve tried, the description seems pretty accurate. They’re powerful text-based editors which allow you to interact with the file system and traverse, search, and edit documents all without leaving the program or even having to touch the mouse. They can serve as an alternative to a visual IDE in the software development world. The intention is that, without the need for the more graphical elements of modern IDEs, the terminal style editor can be faster and the editing of code can be more efficient due to being able to freely switch between contexts of use with just the soft slap of a single key.

I had done a little bit of research but, to be honest, I still wasn’t getting it. So I thought I’d just give it a try.

Trying it out

Downloading Vim is pretty quick and the install process is simple. I work on Windows for the moment, so that’s what I installed (and also let’s you in a bit on the super graphical world I’m coming from). Opening up the application presents you with a black, terminal-esque window with a bunch of blue tildes. The classic blinking cursor sitting idly, awaiting the divine keystrokes of a User; with a capital U. A short message lets you know that typing :help will bestow upon you the knowledge of the ancients, the commands by which you can control this arcane console. Like an explorer in the midst of a magi-technological discovery, you imagine the Rosetta stone that this must be; the secret to untapped power and your key to understanding. What appears is a wall of text referencing other documents which, if I had read in full would probably have told me everything I needed to know. Except that I had no idea how to navigate it. The help file is extensive and a little daunting. Honestly, I actually set Vim down for a bit at that point. The problem was that I just had no idea how to get started and, since I wasn’t really sure what it did, I didn’t know what problems to apply it to.

A week or so later, my curiosity had not abated. I was sure that if I dug a little further the reason that everyone cared about these, seemingly unwieldy, text editors would become clear to me. So I did what any knowing professional would in my shoes. I googled it. I discovered OpenVim.

VirtualVim

Using a virtual vim terminal, the site walks you through your first few commands of Vim. It is by no means exhaustive. It’s a short and simple tutorial of basic editing and navigation. But that’s enough. With that short sample I became an apprentice sorcerer. The runes had begun to make sense and I could feel that there was something a little more powerful at the end of this journey. I was excited to explore more; to gain more knowledge. So I used it for a real life problem. I was not fast. I was not a super human hacker now. But there was something intuitive about the mode switching and navigation without having to leave the keyboard. It took me a while to realize that that was what I liked about it. What I still like about it. Using Vim made me realize quite how much you could do without having to touch the mouse at all, outside of Vim as well. A lot of the programs proponents say, and I haven’t been able to tell how serious they are about this, “why would you ever want to leave Vim?” But as a mere apprentice sorcerer, there’s plenty of tasks I still need to do away from that editor. And using the mouse felt natural. But there’s something really fun about being able to traverse you’re whole machine without lifting your hands more than an inch from the keyboard. I don’t actually think it made me faster or better. But using Vim forced me to think about what keyboard shortcuts my programs and desktop offers. And I found that I was really enjoying it. It felt much closer to putting what I wanted to do into action without any barriers. I’m not saying everyone is gonna have this experience. The mouse hand is a useful tool and it can help you to think. But I can see why people use Vim. With the right start and if you can keep the commands in your head for long enough, then it can become a really easy way to traverse text documents. Does it replace an IDE? I’m not sure yet. There’s a lot you need to do in order to be able to set it up with any of the features that modern IDEs have out of the box.

There is a best of both worlds solution. It’s possible to install Vim plugins to some modern environments such as Visual Studio and CLion which place the navigation and input aspects of Vim ontop of the functionality provided by more modern development tools. This seems like a pretty promising step to me in terms of development speed. So I might give that a try at some point.

If you’re interested, here’s where to get Vim and some good resources on the commands available for getting started.

Vim Website – The website for downloading Vim

Vim Adventures – A little adventure game based around Vim commands. A fun way to get used to the basics.

Vim Cheat Sheet – Pretty dry but really useful during learning. Just the basic commands one after the other.