DEV Community: Jesse van Herk

Becoming a Force Multiplier

Jesse van Herk — Tue, 23 Aug 2022 17:34:00 +0000

For a large part of your career as a developer, your main focus is on building up your own skills and contributions. But then a strange thing happens - as you keep progressing, you actually start writing less code, and spending a lot more of your time on other activities, like meetings, and helping the rest of your team. This is deeply uncomfortable for a lot of people, but it's actually a big step in your career!

Early Career

Let's look at the main progression for the first part of a programming career. You start out by learning to code, through a degree or a bootcamp or teaching yourself. At this point, you're going from knowing nothing about coding to knowing something about coding - this is an infinity percent improvement in your technical productivity! Suddenly you're making computers do your bidding, and it's amazing!

You keep digging, learning more languages, design patterns, frameworks -- and the net result is that things that used to take you days now only take you a fraction of the time! Your productivity isn't going up by an infinite amount, but it's still going up incredibly fast, and it still feels great. Occasionally there's things that stump you, and once in a while you might have to pull an all-nighter to get something done, but it just takes some extra effort and learning, and you can get there.

After a few years, you're working on a team, working on larger codebases. Your big focus is still on tackling bigger and better stories, taking the lead on more of them, dividing work between you and your teammates, and generally writing big chunks of code yourself. This is usually the point where your job title has the word "senior" in it. That's also the point where the strategy of learning more and coding more yourself starts to break down. You're already a great coder, so learning a new language or framework only gives an incremental gain. You've already optimized your workflow and learned all the git secrets (git pickaxe is my favourite!), so tweaking your config is also only an incremental gain.

So how do you keep getting more done, having a bigger impact, and delivering even bigger and better things?

Changing the Math

As a seasoned veteran with years of experience and a full toolbox, this is the point in your career where you start leaning on the rest of your team more, and a bigger and bigger amount of your time is spent helping them. You switch from adding productivity to yourself, over to multiplying the productivity of others.

I'm going to pretend there's such a thing as a 5x engineer, and that's you. Levelling yourself up further so you can do 1 extra story point is hard (you’ve hit diminishing returns), but you can have a bigger impact by taking 5 other 1x engineers and helping each of them to do an extra story point! It takes about the same amount of effort on your part, spent in different places.

This works because junior devs haven’t hitting that point of diminishing returns yet - you can help them get an “aha” moment, or point them at useful resources, or give targetted feedback, all through small interactions or group conversations.

There's also the obvious fact that you probably want to be able to take vacations, sick days, and go home at a reasonable hour. If you're the only one who knows how to do any of the work, you won't feel like you can ever leave. Your own heroic effort doesn't scale, but investing time in teaching and mentoring junior or intermediate devs does. Not only that, but a full team of developers can parallelize the work, getting multiple things done at once, where your own single-threaded brain has to tackle them in serial fashion.

Your time should be spent working with others to help them get more done, but that doesn’t mean you stop writing code entirely. You just need to focus your coding efforts on the highest-impact things!

Putting it into Practice

Okay, but what does that actually look like, and how can you apply your elite coding skills to the challenge? Unfortunately, levelling up others is one of those pesky soft skills that requires a completely different approach from technical problem-solving.

The first thing to do is to convince yourself that it's okay for a task to take longer. Yes, you could finish that story in 20 minutes. But you've got bigger fish to fry, like investigating weird race condition bugs in prod or selecting a new vendor, so it's okay if the intern spends a few hours flailing around with component interfaces. They'll get there in the end, and meanwhile, you've tackled a different high-priority thing in parallel. Again, repeat it until you believe it: it's okay if that task takes longer when someone else does it.

The second thing to convince yourself of is that if you had done that task yourself, you would be taking away a learning opportunity from someone else. Think back to your early career - you learned the most by getting out of your comfort zone, and I guarantee that there was a senior who was internally thinking that he could do that task faster. Delegate work to junior devs that will stretch them, and they will stretch and improve way faster than you expect! Get out of your own comfort zone by getting them out out their comfort zones.

As an aside, I've had teams that intentionally assigned tasks to the person who was least familiar with that code, in order to drive cross-training. The first couple of stories where they did that were slow, but the next ones were faster, and before very long we were in a situation where the whole team was moving faster because we didn't have to wait for the one expert to be free. It's an investment, and it works!

We're into mentoring territory here. A big part of being a good mentor is giving your mentee room to make mistakes, and find their own way. The other big part is accepting that they'll make mistakes - what you need to do is to keep an eye on things and make sure you're acting as a non-obvious safety net. Check in on how they're doing, take the time to do detailed code reviews, and when you find a mistake, work with them to fix it and learn from it. Teaching is just remembering that they're learning because they don't know it yet, and taking the time to share the cool things you know with them.

The Big Picture

As a high-level developer, you still spend chunks of your time coding on big, uncertain problems. But there's also the other activities at that level which often don’t necessarily feel valuable at first, but are critical to letting your team and the larger organization function. Examples include communicating about timelines, writing documentation, build-vs-buy discussions, planning a roadmap, etc. By doing those things, your team can get on with coding, without running into roadblocks. These activities tend to come along at the same point in your career as you're realizing you can't code everything yourself. Tackling them lets you unblock and level up multiple teams, so the whole org can move faster and get more done than a single team (or a collection of individuals!).

This is a magical change in your career - you still code but not as often, some tasks are taking longer to get done, and occasional mistakes are being made, but the team is getting more done. Between levelling up your team and tackling blockers, you’ve become a force-multiplier, putting your skills to good use to get a lot more done than you ever could alone!

So as a developer wondering where your career is going to take you, or someone who has noticed that you're not writing as much code anymore as you used to, remember that this is normal, expected, and above all, it’s a good thing. It's only uncomfortable while your primary metric is your own productivity - switch to thinking about your team’s productivity, and suddenly it clicks into place. It's a phase-change in your career, and it's incredibly rewarding to see your whole team levelling up and accomplishing big things thanks to your efforts!

About Jobber

Our awesome Jobber technology teams span across Payments, Infrastructure, AI/ML, Business Workflows & Communications. We work on cutting edge & modern tech stacks using React, React Native, Ruby on Rails, & GraphQL.

If you want to be a part of a collaborative work culture, help small home service businesses scale and create a positive impact on our communities, then visit our careers site to learn more!

Incident Post-Mortems at Jobber

Jesse van Herk — Fri, 26 Nov 2021 16:58:00 +0000

No matter how stable your software product is, occasionally things go wrong in production, and Jobber is committed to doing a post-mortem investigation to follow up and learn from each incident.

At a high-level, an incident post-mortem answers these questions:

What went wrong?
What did we do to fix it?
What will we do differently, so it doesn't happen again?
What went well during the incident, that we should keep doing?

As we’ve grown and moved to a remote working environment, we’ve changed our process to work better for remote teams and super busy schedules. This is a summary of what we’re doing to make sure that incidents remain rare and our customers can keep getting their work done!

Our process

Our process is broken down into 4 steps: Resolve the incident, investigate it, debrief about it, then share the results

Collect data during the incident. We collect as much data as we can in a slack channel dedicated to incidents, keeping it organized with threads. This includes server graphs, snippets from logs, and screenshots showing what was going on at each point in the incident. It doesn’t all end up being useful, but it’s nice to have everything collected when you start going through the investigation.

Start the investigation right away. We get one of the involved people to take on the role of lead investigator, which really means they’re in charge of making sure the investigation gets done, the post-mortem document gets filled in, and the debrief gets held. Starting it right away makes sure nothing gets lost.

Review the results within a week. While things are still fresh, hold a debrief to review the post-mortem document, discuss the action items, and make any edits needed. This is a 30-60min zoom session with the team involved in the incident as well as reps from other departments (mainly the customer support/escalation team).

Share the results as soon as the debrief is done, so everyone gets a chance to learn from it! We post it to a slack channel that the whole company has access to, for transparency.

New Challenges

With a larger company, people working in all sorts of time zones, and everyone being remote, scheduling and coordinating got a lot more complicated. The process is still mostly the same, but with some tweaks to keep it effective.

Shorter timelines

We’ve shortened the timeline expectations - getting the incident doc started faster and the debrief done sooner helps get all the data and lets everyone involved get back to their sprint work sooner.

Assume async

Scheduling the debrief sooner means that it’s harder to find a spot in everyone’s calendars. Rather than pushing the meeting further and further out, do more of the work asynchronously. Make sure the document can stand on its own, and use slack to ask people for their contributions.

We also record the debrief (easy with zoom) so that anyone who couldn’t attend is also able to watch it later, so nobody has to worry about missing out.

Simple incident doc template

We’re using a wiki template for consistency, and over time we’ve simplified down the template repeatedly so there’s less sections to worry about.

Setting it up with a button to auto-create the new page from the template works well.

The template has sections for:

Impact and Scope
Trigger (what started the incident)
Resolution (what ended up fixing it)
Timeline of events
Root Cause
What went well
What didn’t go well
Action items
Data & Analysis (all the charts!)

Asking for input from customer-facing teams right away

Our customer success team always has great input and is able to help fill in gaps in the timeline. We reach out to them early so there’s time for their input to be added into the post-mortem doc before the debrief. Waiting for the debrief is too late!

Tracking action items in Jira

Why track action item progress in an incident doc when we already have a standard tool for tracking work? As soon as we can, we get all action items from post-mortems in as Jira tickets so they can be assigned to backlogs and don’t get lost.

We also have some reports set up to view the list of outstanding post-mortem actions - driven by a post-mortem label on the items.

Have a section for “things we should do if we have time”

Realistically, not all action items are actually actionable - some are more aspirational or are something we just need everyone to keep in mind. In order to keep the Jira action items clearer, we’ve included this section as a spot to put the things we think are important but we couldn’t turn into assignable/trackable work.

Our approach is that it’s better to have a smaller set of action items that we actually do than a giant list of things we’d like to do given infinite time.

Keep it Blameless

This one isn’t actually new, but it’s well worth repeating! We’re interested in what happened and what we’re going to do to fix it going forward, not in pointing fingers.

"Removing blame from a postmortem gives people the confidence to escalate issues without fear."
– the SRE book

About Jobber

We're hiring for remote positions across Canada at all software engineering levels!

If you want to be a part of a collaborative work culture, help small home service businesses scale and create a positive impact on our communities, then visit our careers site to learn more!