You have 1 article left to read this month before you need to register a free LeadDev.com account.
As an engineer, it can be tempting to always try and figure something out on your own. Here are 3 common scenarios where you should turn to your colleagues for help instead.
One of the great gifts of modern software development is the wealth of information available to you at the drop of a hat. No more large reference books to look through when you’re trying to solve a problem – the internet is filled with all the answers. This is both a blessing and a curse.
If every question can be answered by a little, or a lot, of Googling or ChatGPT prompts, it becomes very hard to determine when to turn to our peers to ask for help. Learning where that inflection point lies between solving a problem yourself and asking others for help comes with experience. You develop a spidey-sense for when something is going to balloon into a bigger problem, and it is in the best interest of yourself and your team to bring others into the problem space.
You can hone this skill by taking lessons from the following common situations or problem scenarios you may run into as an engineer.
1. Trying to figure out the tech on your own
At some point in your career, likely in your first few years, you will work with a piece of technology that won’t cooperate. No matter how much time you put in or how often you review the docs, you’re constantly fighting to get the thing to work the way it’s meant to. If this is the first time this has happened to you, you may default to assuming that you’re the problem and your inexperience is making this relatively simple thing look way more complicated than it is.
The reality is, it’s not you. Working with a technology that is a bad fit for the problem at hand is an experience to learn from. At first, it may seem like a typical learning curve you must tackle on your own, but in this scenario, it makes sense to ask for help. Even the most seasoned engineers will bring in someone else when they hit an immovable tech object. It’s an opportunity to get fresh eyes on the problem, think through the essential elements of the solution, and determine the best path forward.
More like this
2. Rules are made from exceptions
On your way to developing your coding spidey-senses, you will learn to rely on a number of rules. This can be anything from don’t repeat yourself (DRY), to clean code principles, to upper bounds on lines in a file. These are good boundaries to start with, but rules are made from exceptions. Early in your career, the challenge comes from not knowing when to apply these exceptions.
As a result, you’ll end up in a situation where your “rules” are causing more problems than they’re solving, leading to an over-abstracted mess of spaghetti code on your way to building a feature. You don’t yet have the experience to recognize that your rules are a bad fit in this situation.
The next time you encounter a feature that requires you to exercise exceptions instead of rules, ask for help. Even the most experienced engineers follow this approach when they realize they’re deviating from an accepted best practice. They think through the pros and cons of doing so and often float their conclusion to a teammate to ensure the logic is sound.
3. Clarify project scope using the expertise of others
Writing code is fun; it’s why we do this job. Solving problems with code is why we get paid to do this job.
When you’re working with customers, you build what they ask for. But goalposts can move, and before long, you’re building and rebuilding to the tune of a customer who just can’t bring themselves to be content with a product. There’s always a tiny problem that’s been bugging them or a small fix to be handled.
When you’re just starting out, you won’t recognize the goalposts have moved so far because you were focused on the code. But when it happens the second time, you’ll recognize it. And you’ll also see it as an opportunity to ask for help.
Make sure the scope and boundaries of what you’re working on are clear so that they can be completed. Senior engineers ensure this through working with product managers, technical program managers, designers, and engineering managers. Their voices help to clarify scope.
Asking for help benefits everyone
Early career engineers are less likely to ask for help than they should be. They often view asking for help as a weakness, but it couldn’t be less true. Every experienced engineer you work with leans on others. It isn’t proof that you don’t know what you’re doing, it’s proof that you know what’s best for the team and most efficient for meeting your deadlines.
Sometimes engineers don’t want to ask for help because they feel like they’re a time suck and their seniors have better things to do. Your seniors are there to be multipliers. You deserve to take up space and time to learn. It’s in the best interest of everyone that you do.
Whatever reason you have, asking for help is a viable and reasonable way forward. Just follow the rule my very first senior developer gave me: “I’ll answer any question you like, just so long as you don’t ask me the same question twice.”
