In this episode, we are going to be chatting about a useful pattern for problem solving. I have used this for all types of things and thought it would be worth sharing.

Before we dive in though, I should add some context here. Back in episode #51 we chatted about building a carpooling application, and at the end of the episode, we walked through problem solving. This episode is basically just a copy and paste of that chat, but since this is such a useful technique, I thought it worthwhile to create a dedicated episode on it.

Let me set the stage before we jump it. We were chatting about, going from a rough idea, to a finished minimal viable product, and how that can be hard. The reason it is hard, is there is all the problems or things we will need to learn. Sure, it helps if you have a mentor that can walk you through it. But we can brute force this too, and it goes like this.

When I am trying to solve a problem, I think about what the finished product will look like, then try and reverse engineer that idea down into chucks of functionality, or technical hurdles that need to be overcome. Finally, focus on solving each of those technical hurdles, to get a workable solution, then chain all those solutions together, until we have a completed product.

Often times, I have no idea how to do something. But, I have had some success following this thought process. Sure, it is more of a brute force way of thinking, but you will get a deep understanding of the problem space.

I guess the root of what I am trying to say is that the technical unknowns should not intimidate you. A critical component of tech success is having a high capacity for problem solving, learning new skills, and basically grinding things out. This way of thinking, is not particularly hard, it is just time consuming. So, with this in mind, lets look at how we can break a larger problem of building this carpooling service into smaller chunks.

Working the Problem

Now that you know the idea we are going to develop, and the broad set of skills we are going to touch on, lets briefly chat about how this episode series broken up. Probably the best way to do that is through the use of a few diagrams.

It can often be hard to create something from scratch, in that you need somewhere to start, and it is not always obvious because you are starting from a blank slate. I have found that it helps to envision what the end product will look, illustrated by the minimum viable product on the right here, and then sort of reverse engineer it in our mind and on paper, back to the far left over here where we are sketching things down. So, lets briefly work though this and see what we get, as that will likely tell us how to logically group these episodes.

So, what do you think the major pieces, milestone, or problems will be? Well, we are going to need our carpool-matching algorithm for sure, so lets put that down. Then, what about solving the problem of turning a physical address into positional data we can put on a map, so we need to figure out the geo-location problem. Then, what about the route between our user’s house and the office, we need a way to put that on the map too.

We might have a second sketching step here, once we know more about our prototype and how things are going to fit together, so that we can use this as a feedback loop when building things for production. Then, we can use that sketching step to help plan the database design, programming the frontend, and also the backend.

We are also going to need to figure out how users are actually going to use the system. So, we will need to do some workflow brainstorming about having a signup page, where people can create group, how do they join group, what does that matching display page look like, etc. We can call this a type of interface design. Oh yeah, lets not forget actually building out the map and maybe a very simple prototype at the beginning.

So, hopefully you can see that we can kind of mentally reverse engineer steps to building what a product might look like without actually doing anything. Then we can use this as a map of the problems we are going to need to solve. These are kind of steps along to way to making our webapp.

You can also logically split the problems we need to solve into two phases. One might be a prototype phase, where we roughly prove the idea, and then feed in a bunch of example data to prove the idea actually makes sense.

The second phase, will be where we build something that is a much more polished product, and has things like user signup, group creation, group join, user login, password reset, email notification, etc. You know, all the streamlined user functionality that makes up a nice application. Basically, moving the idea from prototype to something people can actually use.

We never really chatted about how you solve these problems if you do not have the skill set needed. Worse yet, you might not even know all the steps, because you do not have enough technical experience to reverse engineer this fully. The unknown unknowns. So, here is the system I typically use to solve these problem steps, it is kind of a cycle I continually go through.

Most of the time, things start with a simple question, like, “how do I turn an address into position data that I can put on a map”? Well, I always keep a notepad of graph paper on my desk and continually jot down notes or sketch down ideas when working through a problem. I find that it help to write things down, drawing diagrams, and sort of put a face to the problem. Next, I suspect we all use Google to answer questions pretty much non-stop while working through problems. Personally, I find Stack Overflow, technical blogs, and Github search invaluable here. Then, I usually code and continually test my solution until I have solved each problem. It is just a matter of cycling through all these problems and chaining the solutions together into something that actually works.

It probably goes without saying, but we are going to run into many unanticipated problems not talked about here while actually building things out, it is just the name of the game when building anything for the first time. My suggestion, would be to keep it high level and not spend a crazy amount of time upfront planning, as things will change really quickly as you learn more about the problem. So, lets say on the far left here, that sketching down some rough ideas is problem number 1.

We might have gone through this problem cycle 15 times before getting to where we actually have a working map, then a bunch more before we figure out how to turn an address into position data we can place on that map. You kind of get this idea. I guess my point of all this, is that even if you do not know how to do these things, just by asking questions and working through the problems, you can typically get to where you want to go. We might have solved a few hundred problems, gone down some dead ends, but by the end of this, we should have a bunch of solutions we can chain together. There is no need to be intimidated of the unknown here, it just takes lots of time, and you can basically grind it out.

One kind of interesting thing to note is that you will typically have many of these little prototype side projects as you advance in your career. Most will rarely advance into the product phase as it just takes so much time and effort to create something that is polished. Most things that turn into products need to be maintained too, so there is an ongoing price to pay, that is why I mostly stick to the prototype area. There just is not enough mental bandwidth, to dedicate your time to too many of these product type ideas, so choose wisely.

Conclusion

It is time to end this episode. But, hopefully by now you understand the core idea, and how we are going to go about identifying and solving problems as we go.

I wanted to create this series, because I thought it might be cool to see the end-to-end lifecycle of how something actually gets built. Hopefully you will be exposed to something you have never seen before. I know, that as I work through these types of things, it is an opportunity for me to learn tons too. It is kind of a win-win, in that even if this product totally sucks, I am still producing something, which is hopefully useful, and learning lots in the process. So, you cannot really go too wrong. Last, but not least, I find that when you work on side projects, you can quickly amass experience and skills, along with your own repository of code. You can then fall back on these skills and code repositories throughout your career.

Alright, that’s it for this episode. Hopefully you found it useful. Bye.