# How to solve a problem like a Software Developer

As a software developer, we have to learn how to solve a problems on a regular basis. But not only do we need to solve these problems, we also have to be able to present them properly. This presentation must be in a consumable format as well as in a language that can be understood by non-technical executives. The problems we solve have to be transformed and presented in a way that they make economical sense. Over the years and decades, many of us have developed frameworks and structures to help us create these presentations in a more streamlined, consumable way.

Solving a problem is not just about the solution; more importantly it is about the environment we face and the examples we present. When trying to solve a problem, we have to make sure that all of our thoughts are written down and comprehensible by third-parties that are not privy to the context. Here is how I approach and present problems:

## 1. Restate the problem

This is one of the most important steps. Restating the problems allows you to show YOUR understanding of the problem. As many great people have said:

It is not about what has been said, it is about what has been understood.

The moment someone speaks, we apply our own interpretation and understanding on the conversation. This has benefit; it speaks to our brains and allows us to process new and unfamiliar situations by matching them to our previous experiences. However, while beneficial, it is frequently the source of many misunderstandings. The purpose of restating the problem is to avoid the potential mistakes that may occur through our own assumptions.

## 2. Find your Audience, your stakeholders

Define the consumer of your solution. Think outside the box. Who will benefit from your solution? Who will have to maintain it? Who will be responsible? Who will be merely a spectator? Based on your audience, your approach for the presentation and the solution itself will be different. It is important to target your presentations to your specific customer.

## 3. List your Assumptions / Risks

After you have developed an understanding of the problem, you want to write down your risks and assumptions for the problem -- as well as the risks and assumptions for the possible solution. This is usually a document that will be frequently revisited as the solutions are being developed in order to make sure all assumptions and risks have been captured. Assumptions and Risks can be very detailed and should be customized to your audience. There may be assumptions that are important to the System Architect but less important to the Marketing Manager.

## 4. Define and Validate your Solution

This is an iterative process. You have your audience. You have your assumptions. Now you can begin working on an actual solution approach. You should validate your solution as often and as quickly as possible. Obtain validation by speaking to your direct stakeholders and getting feedback on the progress of your solution. Most of these concepts can be found in Scrum - How to do twice the work in half the time. The idea is that you want to get feedback from your users as soon as you have a presentable solution. Don't waste yours or the stakeholders' time.

## 5. Define your Presentation: How To Present your Solution

Now, this step seems counter intuitive in terms of the list, as we are discussing a presentation format in general. This step describes the format in which we choose to write down our solution: Is it a visio diagram? a Word Doc? a formula? or PowerPoint? Again, refer back to your audience and validate the pros and cons of each approach. Explain how your solution solves the problem and what it doesn't solve.

## 6. Present examples

Examples, examples, examples. You want to present real examples that showcase how your solution solves the problem. You should include examples from the full problem spectrum; are you catching all the edge cases and special cases? Show examples how these special cases will be handled or if there are problems with these. If you don't feel comfortable presenting special cases, you should work on your solution again, 'cause what you have ain't it.

How do you solve problems? Am I missing something? What do you do in your practice that is different from this?