How to Approach Solving a Difficult or Vague Programming Problem
Here's a few things I keep in mind when trying to solve problems that require a decent amount of thinking or I don't know where to start.
Quick Jump: Experiment | Short Feedback Loops | Visualize | Wishful Thinking | Video Walkthrough
Prefer video? There’s a video version of this post on YouTube with a tiny bit more color and flavor.
A while back I saw a post on HackerNews which asked:
How do you battle against (self-inflicted) anxiety/paralysis when you are attempting to tackle a problem you are not sure has a solution? I have a very open mind to solving problems but it can make it difficult to come to conclusions. Anyone know what I’m talking about here? Have any advice?
I thought that was an interesting topic and as someone who has had similar thoughts in the past it made me think about what I do nowadays to help overcome these thoughts.
In the past I’ve written about breaking down problems and went over why it’s a really important skill to hone. I still very much stand by that today.
In this post I’d like to identify 4 tactical actions you can take to help go from “I’m internally paralyzed by choice or unknowns” to “I know what I need to do to move forward”.
Experiment
One of my favorite things to do is tinker and experiment. I’m an exploratory developer.
For example if I want to use tool A, B or C and I’m not sure which one is best but I do think all 3 have potential and it’s really close then I’ll make a proof of concept with all 3.
This avoids getting stuck in theory craft mode for an extended period of time and it also prevents your future self from always wondering “what if” if you pick one without trying the others. That uncertainty of you wondering if the grass is greener on the other side can drain all motivation.
Now you might be thinking, “I don’t have enough time to do that!”. Look at it this way. If you spend a huge amount of time in research mode such as reading blog posts, watching videos and reading docs then you’re investing a lot of time already.
Don’t get me wrong, I do think initially reading and doing research for all of your choices is a good idea. It’s what helps you move the needle forward on coming up with your choices to begin with. I’ve written about how to research anything too btw.
Also, if you’re building something that you plan to maintain for years then spending an extra few hours or a day up front to try a few things out is time well spent. It’s not always extra too. Sometimes experimenting can be faster than reading.
You’re going to learn a lot from implementing the tools, frameworks or whatever you’re trying to choose between. I don’t know about you but sometimes I can just “feel” if a tool is going to work or not after playing with it for a bit. You can’t always get that from reading because sometimes this only comes up when you’re in the thick of it for your specific problem.
Short Feedback Loops
I love seeing the output of what I’m doing.
There’s a lot of ways to describe what a challenging problem is but one of them might be there’s a lot of combinations of state and logic, such as your program can output many different things based on many different conditions.
Oftentimes littering a bunch of print statements around can help a lot because as soon as you can see what everything is set to, you can start to make sense of it all.
On a related note, having a short feedback loop helps you make incremental progress. I’ve written about question driven development and I think it’s a nice way to always move forward while seeing the results of what you’re doing quickly.
For example, ideally you want to ask lots of bite size tactical questions like “how do I add a database model with SQLAlchemy” or “how do I add a model with Rails” that you can quickly research and try out. It helps you stay focused without becoming overwhelmed.
The goal is to go from reading -> doing and repeating this loop.
Visualize
This is pretty related to the above where we covered printing outputs or debug logs, visually seeing that helps a lot. You can take this 1 step further and visualize what you’re trying to build with diagrams and charts.
When figuring things out initially I’m not a fan of “process”, so I tend not to use fancy diagram tools because for me personally they tend to get in my way and can pull me out of the zone.
I really just want to get something out on paper, so I’ll either use a pen and paper or a whiteboard. I’m not looking for perfection here, it’s usually just a bunch of lines connected to shapes with short text labels. There’s no secret formula or rules.
I treat these drawings as a means to an end, in other words I usually throw them away when I get what I want out of them. Depending on what I’m doing, sometimes I’ll convert them into a proper looking diagram if it happens to be a deliverable for a client’s project but that’s much further down the line.
Wishful Thinking
This is the idea of using your tool, library or whatever you’re building before you build it.
A great use case is a command line tool. Before you even open up your code editor, try coming up with ways you wish you could use this tool if it existed. You can write these commands out in a document, as if you were calling it on the command line.
This really helps you discover a good API for your tool. I do this all the time and it applies back to developing web apps too. For example, in your controller you can call out to a model or domain driven design (DDD) interface that doesn’t exist yet just to figure out how to name something nicely or what the level of abstraction should be.
For me, I get a dopamine hit from this too. Even if it doesn’t work yet, I can see progress and it motivates me to move forward because then I start to think how nice life will be if I can do the thing I’m wishing I could do.
The fun part is turning that into a reality and now you have your end goal in mind so it’s less vague. You now also have the option of working backwards from your goal, or forwards toward your goal. All of this happens in minutes and it’s malleable, AKA you can change your mind very quickly. The easiest code to change is the code you haven’t written yet.
So that’s about it. Hopefully this helps you move forward on your specific problems. If you want to see follow up posts where I use these actions to solve real world problems let me know in the comments below.
Video Walkthrough
Timestamps
- 0:19 – Replying to a question
- 1:13 – Breaking down problems
- 1:45 – Experiment
- 5:29 – Short feedback loops
- 7:06 – Visualize
- 9:22 – Wishful thinking
- 12:38 – Do you want to see practical examples of this?
What’s your favorite tips for approaching problems? Let me know below.