Confessions of a Lead Engineer
Confession #1 — When you talk about Agile, I don't know what you mean
Don't get me wrong, I know you're not talking about whether I can touch my toes or do a backflip.
I'm passionate about finding processes and practices which help teams deliver solutions for customers quickly, safely while solving the correct problem. However, if you were to ask me the differences between Agile and Scrum or extreme programming I'd probably just look at you blankly.
Do you mean that you do a standup every morning, or do you meant that you iterate your product based on releasing little and often? Do you follow test driven development or maybe do some code reviews?
Do you know what you mean by Agile?
Each of the Agile frameworks have good practices, and probably some that aren't going to gel for your team. Every team is different and every project has different requirements, so why would one process work for everything?
My advice is the opposite to Master Yoda: “Try, don't just do”. What I have found most important when working on agile projects is an attitude of experimentation.
The most important question to reflect on is:
“Do you have a regular retro, and does it change how the team works?”
If you have this in place and a willingness to experiment for the sake of progress, then all the rest will fit into place. Find practices which work for you and your team, but have them be the solutions to problems, not a prescribed set of meetings or activities that you do to satisfy a buzzword.
If you never have any ideas at retro, maybe it's because nothing changes. Unfortunately it's a vicious circle — if no one sees a change, they're less likely to think about what could change. Take some advice from MJ and start with the (hu)man in the mirror. If you start driving change and get excited about it, others will follow.
Confession #2 — I don't actually know that much
I'm passionate about mentoring people. I love to see them grow and improve, and more often than not, I'll also improve through the act of mentoring someone. Recently I've been mentoring a lot of people who are relatively new to software, and a few who aren't. One thing that you might find surprising is that I often have to say “I don't know”.
I'll normally follow it up with “but let's find out together”. That qualifier is probably why I still have a job. The important part of my job is not retaining information, but knowing where to find it and knowing what good looks like. Seeing you use these skills to find an answer to a problem is far more valuable for your mentee than just being told.
(If you want to read more about my thoughts on mentoring, please have a read of my article how a toddler and two babies made me a better mentor.)
Meetings are another great opportunity to prove how little you know. Whether it's an overuse of acronyms, or you've missed the context, or the subject is just not being explained well, it's likely that you've been confused in a meeting before. Whatever it is, just speak up and ask for some clarity. I can almost guarantee that there'll be someone else relieved that you asked the question they were thinking.
There's a popular quote that the hardest three words to say are “I love you”, but for most of us it's “I don't know” (arguably four words, but go easy on me!). It's hard to admit that you don't know when you're in a senior position, and people have expectations of you. The temptation is to try to blag your way through it. I've done this before, and I've seen other people do it too. It's not worth it. You'll embarrass yourself more if you're caught pretending to know. Better to set the example that it's ok to not know by saying:
“I don't know, but let's find out together”
Other stories about Working Practices:
Take your stand-up to the next level
Make your daily stand-up quicker and more efficient with this simple method
7 reasons why video calls are so tiring and what to do about it.
Everyone feels it — be the one to do something about it.
Has COVID killed the daily stand-up?
The meeting that was “for the developers, by the developers” has turned into another status update meeting for middle managers.
Six things that will make you a better developer
Whether you're new to software engineering, or you've been doing it for years, these six things will make you better
How to get stuff done when your brain says no
Some tricks to focus when your brain decides you have a million things you must do right now.
Richard Bell
Self taught software developer with 12 years experience excelling at JavaScript/Typescript, React, Node and AWS.
I love learning and teaching and have mentored several junior developers over my career. I find teaching is one of the best ways to solidify your own learning, so in the past few years I've been maintaining a technical blog where I write about some things that I've been learning.
I'm passionate about building a teams culture and processes to make it efficient and satisfying to work in. In many roles I have improved the quality and reliability of the code base by introducing or improving the continuous integration pipeline to include quality gates.