Skip to content
Swizec Teller - a geek with a

Why senior engineers get nothing done

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.

When you're new life is great

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.

When you're seasoned though

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.

How this happens to you

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.

Grumpy cat with bugs
Grumpy cat with bugs

Ownership takes time

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.

Force multiplying takes time

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.

What you can do to protect your coding time

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.

Ask good questions and help others ask good questions

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


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.

Did you enjoy this article?

Published on September 11th, 2020 in Opinions, Learning, Mindset

Learned something new?
Want to become a high value JavaScript expert?

Here's how it works ๐Ÿ‘‡

Leave your email and I'll send you an Interactive Modern JavaScript Cheatsheet ๐Ÿ“–right away. After that you'll get thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over my 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

Start with an interactive cheatsheet ๐Ÿ“–

Then get thoughtful letters ๐Ÿ’Œ on mindsets, tactics, and technical skills for your career.

"Man, love your simple writing! Yours is the only email I open from marketers and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. ๐Ÿ‘Œ"

~ Ashish Kumar

Join over 10,000 engineers just like you already improving their JS careers with my letters, workshops, courses, and talks. โœŒ๏ธ

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:

By the way, just in case no one has told you it yet today: I love and appreciate you for who you areย โค๏ธ

Created bySwizecwith โค๏ธ