One of the most common mistakes I see software engineers make when they start in a role is not reaching out to a teammate sooner: for help, or to throw an idea around.

Here’s some reasons why, especially in a new role, you should ask for help if you get stuck.

The Pros #

Get ramped up quicker #

If you’re working in a new tech stack, or on a new team, there’s always going to be some tribal knowledge: information that isn’t stored in any easily searchable system of record, but is readily available in memory from a colleague.

Every team has that extremely esoteric issue that has yet to be documented yet, and it can cause someone new to spin their wheels for days: things like:

  • A known bug in a dependency that has yet to be fixed.
  • A particular error that is caused by a misconfiguration in setup of a local environment.

Reaching out as you encounter issues to verify if this is something others have seen can avoid days of time.

You learn about tools and techniques #

Someone who’s been on the team for a long time will generally have a large collection of command-line tools, browser extensions, and shell scripts to assist with common issues. As someone new to the team, you don’t have that yet, and building those from scratch all by yourself will take time.

Reaching out and seeing how a teammate investigates or fixes an issue can teach you about valuable tools that you may have not been aware of.

Learn about prior art #

One of the most valuable pieces of knowledge your team has is experience from previous attempts to solve a problem. It’s best to run your ideas to improve the codebase (improved linters, or perhaps a refactor of a particularly hairy piece of code) by someone on the team to see if it hasn’t already been tried.

The cons #

Losing out on learnings from struggling #

Sometimes, struggling through an issue is good:

  • You learn techniques that you wouldn’t have otherwise.
  • You’ll need read through and understand a technology deeply to diagnose.
  • You’ll improve your search-foo and debugging skillset.

And reaching out too quickly can rob you of that opportunity.

Randomizing colleagues #

Asking your team does come with a cost: it can randomize your teammates from their work.

But consider the cost benefit: ultimately, it benefits the team to have a productive member of the team more than a few one-time randomization costs. The contribution you make as you add new features, fix bugs, and contribute new ideas will easily pay off the hours it takes the other engineers to answer your question.

If you’re really worried about randomizing the team, consider asking questions at dedicated times or around regular events that are already randomizing like standups or sprint planning.

The compromise: timebox then ask #

To try to strike the balance of reaching out and solving problems yourself, try timeboxing your investigations: give yourself a set time to investigate and unblock yourself, and ask if you’re still stuck when time is up.

Setting an upper limit on an investigation helps you stay productive while not bugging your colleages too much. Without a timebox, you can get lost in investigation indefinitely: who hasn’t had a bug that they fixed and felt great about, but felt like they took a bit too long?

Summary: asking for help is a good thing #

  • Timebox your investigations: once you hit your limit on investigation, ask for help.
  • Reaching out can help you ramp up quicker.
    • Ramping up quicker is better for your team.
  • Reaching out helps you learn tools and techniques you may not learn otherwise.
  • Reaching out can save you days to re-learn knowledge or learnings your team may already have.