Back3 Attributes of Good Embedded Software Consultants
Team augmentation (aka, “software engineer rental”) is something a lot of software consultancies do as a service; if you’ve got good engineers, it’s valuable to let other companies borrow them for a fee. Sometimes those other companies have their own tech teams and don’t need to hire a whole team to get the job done — they might need one or two with specialized expertise as extra sets of hands to get a project over the finish line.
When working in new environments, our engineers need to be particularly strong in certain qualities in order to be the most effective as a part of our client’s team. Here are three of them that stand out.
Asking Lots of Questions
If a new engineer to any project just listens and nods her head a lot, it could be a good thing — they could be absorbing everything perfectly, then once they hit the GO button on her keyboard they’re going to crush some code exactly how you need it. More often that’s not the case, and if someone isn’t asking the right questions, they’re missing something. They might be too eager to code something without knowing that the approach they’re taking is the right one.
Asking questions — a fair amount of detailed ones — is valuable since it shows the engineer wants to consider all angles before diving in. She doesn’t want to just start writing code, she wants to think of the challenges ahead of her holistically so that she’s going to execute efficiently.
Looking at the Whole Stack
Things in software development aren’t always what they seem. This is especially true when diagnosing things like performance issues, for example, where a slowly-responding button could be the result of a front-end bottleneck, a back-end bottleneck, a third-party API call, or an engrained architectural decision.
Good software consulting — like good software engineering in general — is facilitated by assuming any problem you encounter might be the tip of the iceberg, with more parts of the problem hidden beneath the surface. Practices like the Five Whys and root-cause analysis come in incredibly handy, even on a small scale.
Pragmatism Over Perfectionism
Every software engineer wants to write good code, and do things “the right way.” But trying to focus on perfection at the expense of time, budget, practicality, and so on can lead us down costly rabbit holes or create unnecessary complexity that can turn into technical debt.
When working off of someone else’s dime, it’s particularly important to keep these things in mind. Being too perfectionistic with the solutions we build means missing deadlines, launching too slowly, and sometimes over-engineering solutions that might change before they’re worthwhile. So it’s important to have a razor-sharp focus on the immediate goals while keeping the long-term goals in mind, and building the happy medium solution that will best cover both bases without taking too much time to see the light of day.
