Remember when you started your job, how was it?

Let me guess: the sheer amount of new things to learn was overwhelming, you felt out of your depth, and your calendar was open and free after the first week of onboarding activities.

Best part of starting a new job my friend 👉 You get to work. It’s wonderful.

Imagine a typical workday for a new team member:

• 10:00am – standup
• 10:15am – work on tickets
• 11:00am – quick chat to ask a question
• 11:15am – work on tickets
• 12:00am – lunch
• 12:30am – work on tickets
• 15:00pm – review PRs
• 15:30pm – break
• 16:00pm – work on tickets
• 18:00pm – done for the day

8 hour block of time, 30 minutes of meetings, 30 minutes of PRs, a whole lotta coding. 😍

A good manager will put you on one long project. It’s the best way to learn.

Get a big project and do it. You’ll explore the system, figure out how pieces move together, and have a common thread to guide you.

New junior engineers get to work on parts of the same big project over weeks and months. New senior engineers do the whole thing.

Both are valid.

Now imagine what a typical day looks like for a seasoned engineer my friend.

• 10:00am – standup
• 10:15am – unblock Susan
• 10:30am – meet with product manager
• 11:00am – quick chat to answer Bob’s question
• 11:15am – answer PM’s followup question
• 11:30am – code reviews
• 12:00am – lunch
• 12:30am – 1-on-1 to welcome new team member to team
• 13:00pm – 5 slack threads of questions
• 13:30pm – production bug
• 13:45pm – unblock Joe
• 14:00pm – meet with head of engineering
• 14:30pm – write tech specs for next month’s project
• 15:00pm – quick chat with PM to clarify something
• 15:15pm – continue writing specs
• 15:45pm – unblock Alice
• 16:00pm – work on tickets
• 16:15pm – notification in #bugs channel
• 16:20pm – work on tickets
• 17:50pm – catch up on Slack threads
• 18:15pm – done for the day

8 hour block of time, 2h45min of meetings, 45min of writing tech specs, and an hour of coding. Never more than 30min of focus time. 😅

And that’s why senior engineers get nothing done. They’re too experienced and know too much.

You start with writing code and delivering fantastic results. You’re killing it and everybody loves you! Rock on.

Then your code hits production.

All code has bugs, yours too my friend, I promise.

As a professional software engineer, you maintain this code. You are the owner.

When a bug happens in production, you look into it. You figure out who best can solve it. Could be you, could be an upstream or downstream system. You ensure the bug gets fixed.

That means you are in charge of communicating with whomever stepped on the bug. Tell them you saw, loop them in when it’s fixed, offer a workaround for right now.

As your knowledge of the system grows, your job shifts from that of writing the code to that of force-multiplying others.

You can make others faster.

When Susan hits a problem, she can spend 3 hours Googling for a solution, or 5 minutes asking you. When Joe can’t understand a module, he can spend a day digging through the code, or 5 minutes asking you.

20 minutes of your time to save 7 hours for the team.

Your company will make that tradeoff every day. $40 of your expensive time for $420 of everybody else’s time? Yes please.

When you complain you can’t get anything done 👇

Make sure your boss understands and values your force multiplier work!

I’ve been in situations where all this was expected, but only writing code was valued. That sucked.

Do not become that ass who doesn’t answer questions or help their team!

You can use 2 broad strategies to protect your time:

1. Timeboxing
2. Optimization

Timeboxing is the strategy of blocking off your calendar for specific types of tasks.

For example I have a meeting with myself every afternoon. 3pm to 6pm is coding time. My calendar appears blocked off and no meetings get scheduled.

When you do have meetings, schedule them all in the same part of the day. Back to back.

Nothing worse than a 15min stretch of time between 2 meetings. Too long to waste, too short to do anything.

Same goes for Slack and email.

Have a time in the day where you go through all of slack. Ignore notifications and questions for an hour, then answer everything in 15min.

I find this hard to do but it’s good advice to give. 😇

Configure Slack so it never creates notifications and only dings when you are mentioned or DM’d. It’s how you stay sane. Remove all other notifications. Keep your computer in DoNotDisturb mode.

The fewer pings you get, the easier it is to ignore everything until your question-answering timebox.

Do not expect immediate replies, do not give immediate replies. Let questions accumulate

How can you answer more questions faster?

Documentation my friend.

Nobody reads documentation do they? Out of date, hard to find, impossible to understand without context. Easier to ask.

Here’s what you do:

1. Someone asks a question
2. Answer
3. Take 5min to write down your answer
4. Share publicly

Next time you get the same question, do this:

1. Find your answer
2. Spend 30sec validating it’s correct
3. Send link

With time folks learn to check documentation first. If they don’t, you’re saving time by sharing pre-packaged answers.

Saving answers to your questions helps you too. 6 months from now, you won’t remember why or how you did something. Look it up in your notes. Make the notes searchable and shareable.

Another optimization is asking good questions.

Problem with a library or framework? Google it.

Problem with our code? Ask.

Problem with how we’re holding a library or framework? Ask.

This is why you should avoid inventing everything from scratch and use public open source libraries. The more your team can learn from public resources, the less work for your seasoned engineers. 😉

After that heuristic comes this magic question format:

Can you help me with this problem? Who is the best person to ask? Here’s what happens and this is what I expected to happen. I have tried X, Y, and Z to resolve the issue. I will be blocked by this in N minutes.

Ask before you’re blocked, ask in public, present what you’ve tried, explain what happens and what you expected to happen.

Any tips I’ve missed? hit reply

Cheers,
~Swizec

PS: Once upon a time I wrote a book called Why Programmers Work at Night, which talks about how to be more productive as an engineer. You might enjoy it and I should re-read it too.

Have a burning question that you think I can answer? I don’t have all of the answers, but I have some! Hit me up on twitter or book a 30min ama for in-depth help.

Ready to Stop copy pasting D3 examples and create data visualizations of your own?
Learn how to build scalable dataviz components your whole team can understand
with React for Data Visualization

Curious about Serverless and the modern backend? Check out
Serverless Handbook, modern backend for the frontend engineer.

Ready to learn how it all fits together and build a modern webapp from scratch?
Learn how to launch a webapp and make your first 💰 on the side with ServerlessReact.Dev

Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️