Intro

When doing the dishes after dinner, you can get the job done, or you can go a little further. It’s the difference between wiping the counters, cleaning the gunk out of the sink and taking the garbage out if it's full. Do you take out the trash when you’re done writing your pull request?

When receiving help

We've all been there - staring at a bug for hours, feeling like we've tried everything and have no clue how to proceed. It can feel really draining and demoralising. So finally, you reach out for help from a more experienced member of your team and jump on a call. You share your screen, they poke around your pull request, asking questions and adding log statements. After a few suggestions, they finally solve your problem! The errors disappear, your tests pass and relief washes over you.

On the surface, this seems like a perfectly reasonable stopping point. They've solved your problem, and maybe they even explained a little bit about what fixed the problem. The issue is - you haven't really learned anything here. It's kind of your peer to jump on and help you debug, but the expectation is that you start collecting tools in your arsenal to solve your own problems.

So how do we go a little bit further here? We can pivot from specific questions to bigger picture questions. Here are a few examples:

• How did you know to look here?

• Can you share any relevant documentation that would help me understand this mechanism?

• What's the underlying principle that describes this behaviour?

• Can we take any steps so that folks don't encounter this in the future?

These kinds of questions not only solve the immediate problem but build your problem-solving toolkit. After a while, you’ll spend less time feeling stuck and more time making valuable contributions independently.

When reading docs

Oftentimes, when working on a part of a codebase for the first time, we try to mirror some other function that is nearby. That way, we can try to stick to the conventions, and when questioned, can point to the neighbouring function and proclaim "I'm with stupid!" This approach is limited however - the nearby code might not be similar enough to what you need. In that case, we may be able to go look up the docs for the library that we need to use. Lucky us! We found the function, can take a quick look at the required arguments, and we've gotten it to work for our use case! Job done? It could be, but we could also go a little further.

See, maybe the nearby code we were looking at is some legacy stuff - years old and janky even when it was written. Why should we even take inspiration from there? So instead of reading the docs for just the one function that we needed, let's take 20 minutes and read through the write up for the whole module. Now, we have a better understanding of what we're working with, instead of aimlessly trying to fit pieces together.

Okay, so what? Now we've sunk half an hour into getting better at some library, who cares? Well, now as we're finishing up our pull request, we realised (based on our readings) that there is a much simpler way to approach this. Maybe we cut down on lines of code, we decrease our surface area for bugs, and here's a real kicker - maybe we can get rid of this dependency entirely!

There's another benefit here beyond the immediate chunk of code. As you deepen your understanding of the libraries, you can now contribute to discussions more effectively.

This extra effort with documentation gives you a leg up in your own work and sets you up as a resource for your team. You’ll be better equipped to contribute new perspectives, help refine best practices, and provide valuable feedback in code reviews.

When writing technically

For early engineers, one of the most dreaded and annoying requests is "can you write this down?" You might think - what a waste of time! Let's just jump on a call and hash it out. And as far as documentation goes, who reads that stuff anyway?

Counterintuitively, I think this is one of the most important aspects of growth in early career. There's a notion of explaining a complex topic to someone "like they're five", which demonstrates one's mastery of a topic. So next time you want to reach out to someone to get unblocked, inclined to get on a video chat, consider first writing out your problem in detail:

• What problem are you trying to solve?

• What do you think it might be related to? Aka - what research have you done so far?

• What are a few things that you've tried so far, and what were the results of those attempts?

• What is the clear ask for the person you're getting help from.

Now this is a great start. The action of writing this out will help you think things through, and be systematic in your approach. But as is the theme of this article, can we go a little further?

My answer to that is in adding context. When you are asking for help, you shouldn't assume that they know anything about the problem you are working on. If it's someone on your team who is senior enough to help you, there's a good chance they have a lot of different problems in their mind. Help them out by providing the details they need to get oriented in the world of your task. As you develop better tools to debug your problems, when you do face an issue, it's likely you'll reach out to someone outside of your team or even on the internet. These people truly don't have any of the project context in mind. Think about the time you asked your first question on stack overflow, and got chewed out for being way too specific and not providing enough details for them to work with. Trust me, we've all done this.

I think that adding context goes far beyond this format of writing. It's crucial for leading projects, when engaging cross-functional stakeholders. This ensures that everybody is on the same page. When capturing a particular decision, adding good context in a quick write up lets future you answer the question "why did we take this approach" when you've long since forgotten.

Conclusion

Going a little further means investing in your growth, whether that’s by learning from teammates, exploring documentation more deeply, or communicating clearly in your writing. This extra effort not only solves the immediate issue but builds skills that will serve you over the long run. Every time you go beyond the basics, you’re setting yourself up to make stronger, more valuable contributions to your team - and ultimately, to yourself.