From time to time I volunteer or get volunteered for a seemingly impossible challenge. A typical conversation goes thus: “Hey, we need to integrate the XYZ module into the DEF system and ensure performance lies within ABC limits. Also, can it ship next month?
Software engineers love TLAs (three-letter acronyms)
In the past, I would fret over XYZ, DEF and ABC and worry that I would fail (impostor syndrome eh). How was I expected to make any progress when I didn’t even know left from right in ABC-land?! However, over the years, I have learnt techniques to boost my chances of success at such tasks.
Here is my approach for tackling such challenges
Spend a lot of time learning
Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
The statement above is an apocryphal quote attributed to Abraham Lincoln but the lesson is clear. Most of my struggles occur when I do not have a full understanding of the problem space. This makes it difficult to build mental models, which in turn makes it difficult to debug problems or theorize possible solutions.
TIP: If it is difficult to clearly define a problem, then you probably do not understand the problem domain.
I now try to learn as much as possible about a problem space before trying to pitch solutions. I try to gobble up everything I can find about the ecosystem, tools and practices so I can make informed decisions.
I once studied for about ten hours to deepen my understanding of message-broker architectures. Armed with this knowledge, I redesigned my initial architecture to support new scenarios. The expertise also came in very handy when the inevitable bugs finally emerged. I bet some of the edge cases would have befuddled me otherwise.
TIP: The bugs averted, debugging time saved and experience gained have paid off the initial 10-hour investment in several manifolds.
You can seek out experts to clarify unknowns and cement understanding. Or you could look for people with domain expertise or those who’ve solved the problem (or similar problems) to learn from their experience. If everyone is groping in the dark, then this opens up a vista for collaboration and mutual support. There is no point in making mistakes that others have already made! Rather make new mistakes so you learn something new!!
Make it work first
As a junior engineer, I spent an inordinate amount of time trying to deliver perfect software in an unfamiliar space. My exploratory spikes were quite helpful as I finally acquired a solid understanding of the system architecture and data flow.
After that, I faltered and could have done with some mentoring. One big mistake was trying to get 100% test coverage for features that were still in flux. I lost time fixing tests when the prototypes changed: the tests caught nothing! Tests are essential but testing dead code is not productive.
Nowadays, I rarely write tests if I am running experiments or writing throw-away code. I know that the only purpose of such code is to quickly validate assumptions. Once exploration is complete and I have a better picture of the space, I can focus on a solid implementation with test cases.
Polish until it shines
At this stage, you should already have a solid understanding of the problem space and how to solve it. Ideally, the task feels familiar now and craftsman expectations come into play: you start thinking of testing edge cases, informing stakeholders and leverage footholds.
This stage should be relatively drama-free and involve execution of a solid plan with a few unknown unknowns. You should also take a step back and look at the problem from a distance to find spots to smoothen.
Amplify Project Impact
Congrats! You’ve elegantly resolved a tricky problem!! Pat yourself on the back and do an introspection of the entire process. Are there ways to leverage your solution for even bigger impact?
For example, the research phase usually reveals teams who have the same challenge. These are potential customers who can reuse your solution! Proactively reach out to them and see if they can leverage your implementation or even learn from your experience. This is a very easy way to amplify success at little or no cost.
If there are no immediate customers, consider writing a blog post, publishing a white paper or open sourcing solutions. You never know who would eventually benefit from such; writing is a great way to reflect deeply about your growth.
I believe there are many ways to magnify impact: we only need to make this a habit after completing projects. Think again, how can others benefit from all your hard work at little cost to yourself?
And that’s about it. I’ll love to hear about your techniques! Do share in the comments.