In our work as software engineers, we are primarily responsible for translating abstract problem statements into computer-readable code. Hence, I believe the largest issue is figuring out what to do with an abstract problem statement with complex objects, various stakeholders, and complicated logic must be converted into machine-readable low-level code.
Lets have a look.
Break it down — but how?
Breaking down a problem into smaller pieces is a typical piece of advice when it comes to problem-solving.
However, how? From where do you begin?
I believe that writing down a problem is the greatest method to simplify it.
Write the situation down in your own words. It make things easier to remember, especially when they are written down. Instead of memorizing things, our brains have been specifically engineered to make connections. So, for an abstract problem statement, consider writing down these things :
- Why is it vital to find a solution to this issue?
- What is the outcome?
- From the solution to this problem, who stands to gain the most?
- Is there an optimal output or state?
- How is the data inputted into the system?
- What data sources are you using?
- Has any processing been performed on this raw data?
- What format will the output be in?
- How long will it take for you to store it?
- Are there any events that can be pushed to the fore Or do you want to display them?
- What if there’s nothing to show for it if you are designing something?
- In what sections of the codebase will your solution have an impact?
- Are there any areas that need to be changed?
- Are there any teams that should be aware of this?
- Are there any groups or individuals who can assist you?
With these answers in hand, you’ll have a better notion of how to approach this challenge. You can gain a deeper knowledge of the problem and uncover some hidden insights by talking to the people who will be affected by the solution.
So far the abstract problem statement has been reduced to a more concrete form, which resembles an engineering problem with inputs and output formats.
Solving the problem
After that, you’ll need to figure out what actions that must be followed in order for the input data into its final output form: things that must be built; functions that must be written; objects that must be built; services that must be run. It’s possible that you’re designing/architecting something; in that situation, there’s no apparent outcome – your plan is the result.
Try to stay away from writing paragraphs that describe engineering issues or solutions. Everything should be written in bullet points – this immediately gives structure and splits it down into smaller, more manageable sections.
Doing some research
Before moving ahead, you should do some research like:
- Do you have access to any tools that can help you partially or completely address your issue?
- In order to handle this problem, what tools are you going to use?
- Do you have any suggestions for alternatives that would be better suited to your use case?
Collect as much information as you can on the tools you may employ in the future. Choosing a tool solely based on its perceived superiority is not a good idea. Give yourself a compelling reason to choose it. Have reasons for not selecting the other tools you rejected.
Nearly everything you try to do has been done previously, either in full or in part. As an alternative to using the same thing to address your problem, you can still use these solutions as a guideline. Using it as a starting point, you can find inspiration, patterns, things to do and not to do, etc.
When you’re done with the above steps, you’ll have a clear idea of what you’ll need to do in order to reach your goal.
Your final plan
Knowing your inputs and the processing that will be done on them, as well as your toolkit and final output format, is a huge step forward. Make a bulleted list of your final plan.
You should write down all the options you explored, including the reasoning for your selections, other techniques you could think of, and links to everything you referred to that could be helpful.
Using an example
If you’re describing something complex, always provide an example. Test your strategy using example input and check whether you obtain the intended outcome.
If you’re designing services, APIs, or data structures, this is extremely useful. Work it out based on an example instead of relying on the specifications.
Last but not least, ask for a second view before you implement or provide it to anyone else. There are always things that a fresh pair of eyes can see that you missed or neglected.
Final Note..!!
What I consider to be real talent is the ability to break down complex challenges into small parts that can be implemented and explained with relative ease and simplicity.
As long as you are given clear instructions on how and where you should perform certain tasks, what tools to use, and how and where you should create certain functions, then anyone can solve the problem.
Many people can write code in multiple languages without errors, but only a few individuals have the ability to simplify abstract problems and know precisely what to write or build.
Engineers, I believe, are distinguished from programmers and coders by their ability to simplify and break down problems.