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.
CodeKraft 
This is very insightful, thanks for sharing.
My first task when I started my graduate studies was to work with a PhD student in my lab on his thesis. I was saddled with the responsibility of developing the mobile application that would be deployed to users and get some data for his analysis. I have never done any mobile dev before. I used the first few weeks to learn about mobile architecture, watching tutorials and took online courses about about mobile development, I also did some small projects along the line. Even with all that, I still didn’t have confidence in myself, the imposter syndrome in me almost won. After several tutorial and learning, I summoned the courage to start the project, also largely because time was running out and I was tired of giving excuses.
Building the app one component at a time, it was a success and I’m largely proud of myself. To cap it all, last week, I received a mail that the application won the best student design competition at an HCI conference. Now I feel more comfortable taking up tasks that I think are beyond my level of expertise and understanding, especially in software industry, all that matters at the end of the day is the amount of work you are willing to put in.
PS: The imposter syndrome still sets in sometimes.
LikeLike
Explaining your system to someone else is a great way to find out just how well you actually understand it yourself. If you can’t explain it simply and clearly, there may be issues to resolve.
LikeLike