The team lead path

Being a team lead at Automattic is not a promotion, but it is very challenging and after doing it for the last year, I understand why.

During 2020, just before an intense hiring spree, I got the opportunity to lead a small team of 3 software engineers. Our primary responsibility was WooCommerce Payments (alongside 3 other teams). With payments being a business focus, we needed more engineers. And in what felt like no time, a 6 month onboarding rollercoaster season led to the team growing to 8 people!

My vague team management ideas did not serve me well. I hoped to figure things out as I went along and expected work to remain as is, with a few leadership tasks added. No big changes. I was very wrong. Two major areas changed: my schedule and work type.

As an individual contributor I had two standard meetings per week. One with the team and one with my manager. As a manager, I now have eight check-in’s (1on1 with each member of the team), the team meeting and the meeting with my director. Along with these there are also other meetings that I have to fit in the gaps.

The type of work also changed. I was no longer writing code, but rather, spending a lot of time in google docs, messaging and P2 (our replacement for email). I could still help out with code reviews and do minor code changes, but I really struggled to find uninterrupted time to think deeply about the technical problems. Along with this I had to get used to the constant context switching.

Automattic truly supports team leads. We all get access to one on one coaching with a professional external coach. The company runs remote training cohorts specifically for team leads and on top of this you have access to any learning resource that could help you become a better leader and manager.

Besides work there were also so many changes in my life. The Covid-19 pandemic, loss of loved ones and 2 new arrivals in our family, Ariah and Avah. On top of it all I also undertook completing my academic qualification. I’m not complaining here, but just wanted to highlight how there really wasn’t any time for extra hours of reading and learning about the new path.

While figuring everything ways to handle the new path, I began to discover how valuable an impactful team lead can be. I began to see small things that came about as a result of my championing. I realised how my impact on other team leads can move the organisation forward.

As a new team lead you try and throw things together, a mix of what you’ve seen others do and you try to avoid the bad things that you’ve experienced. This mix doesn’t really help as you constantly doubt yourself. I think this past year helped me to discover the type of lead I’d like to be and what I can work towards.

My grandfather used to say: “Time changes many things”. I feel like this new path challenges me to change into a better version of myself. The great thing about the team lead path at Automattic is that because it’s not a promotion, you can always switch back. Maybe the pendulum will swing back and I will become a better individual contributor or perhaps I’ll stick it out and be the best manager I can be.

Imposters handbook: a quick review

A year ago I read the imposters handbook. It seemed like this book was specifically for people like me. The found himself in the same position I was in: Feeling like an imposter.

I read this book a year ago, but it took me this long to write something about it as I was lacking the daily discipline of working on my blog probably related to the same imposter feeling.

Continue reading “Imposters handbook: a quick review”

When are you proficient in a programming language?

Learning a programming language gives you the opportunity to explore other problem domains alongside new approaches to addressing familiar problems.

I write this as I was looking for the answer to exactly this question. There were many opinions that had me confused, some from ancient rockstar ninjas who command CPUS at will and others from earnest people who are also seeking.

Why would one ask such a question in the first place? It seems like the actual issue is 2 fold. For me it is firstly; when can this go on my resume. Secondly and probably more specific to me: when to move on to the next language or skill. When can I check off my to-do list and say that I know a programming language?

After looking at many other ideas, In my opinion: You are proficient in a language when you are able to read, understand and debug code along with deploying to production.

If you can read, write and execute you are well on your way and I would consider this profecient. Beyond this, optionally, persue mastery. Though in order to keep a language on your resume, make sure to continually read, understand and debug.

Link to other opinions: https://softwareengineering.stackexchange.com/questions/154862/at-what-point-can-i-say-ive-learned-a-language

Why I’m learning a new Programming Language called Go

For the past few years, I got stuck in a rut, a good one. My sole focus was not the technology I used. but rather the thought processes behind why and how I write code. I write in PHP and I mainly focus on the WordPress CMS. This pays the bills and helps me take care of my family but, while focusing on thought processes, I didn’t realise that learning a new language can have the same effect, helping me think differently about similar problems.

So why Go (#golang)? This one I stumbled upon by accident. A colleague of mine, Akeda, automated one of our workflows. Before this, we had a weird process involving multiple tools and steps. His script made life just a little easier. I thought one could improve it just a little bit more, but in oreder to do this I had to go digging into Go source code.

After hacking on this project and getting it “mostly working” I decided to dig a bit deeper into Go. I found out immediately that it was created by a few very smart people at Google. It is open source and has a very strong community. More specifically, Docker, the tool I use all the time, was written in Go(mind blown gif goes here).

With Go you to create systems software. I know my way around PHP and this is great, but there are a few things an interpreted language simply can’t do. This presented me with another opportunity to learn.

Go is written in Go! Yep, that means you can eventually read and contribute to any bugs in the language itself, if that’s something you’re interested in. I think it’s great that one only needs to learn on language to get involved with an entire commuinity.

Learning GO is free, no need to buy expensive books. Do the tour, then work through How to write go code and then read Effective Go. After this, you can start using the language. If you are new to programming you may need more help.

With Go, most of the tooling forms part of the language. The following things are already included: code documentation generation, testing, dependencies etc. In most languages I know these are third party tools. They may not work exactly how you want them to, but they work and they remove the burden of having to choose between third-party options. Though third-party options are available, the idea is that everything you need to be productive should be part of the language.

New languages force us to think differently about the same problems, as per this stack overflow answer:

It’s not about the next “new thing”. It’s about thinking in different ways outside of your normal thought patterns

I hope this inspires you to pick up a new language. There are so many to choose from.

Featured image is a gophers, the Go mascot. It was created with https://gopherize.me/. Creating a unique gopher.

Golang Channels: explained simply

I see go channels as a pipe connecting two air tight vacuum cleaners. One vacuum cleaner can not push anything into the pipe, if the other vacuum is not pulling from the pipe. Both need to do the opposite action. If one sends the “package” will be stuck until the other turns on it’s receiving action.

Channels can contain multiple slots for “holding” the “packages”.

Pushing more into the pipe than wha the pipe can handle results in a broken pipe.

I also think of it as a queue, first in, first out ( last in last out ). The only difference is this one is ultra sensitive and very particular.