How To Solve It

When I was a beginning coder, I gathered from watching more experienced people that one of the most vital skills a developer can have is the ability to solve problems quickly. But when I would ask them how they were able to solve such-and-such a problem, they’d usually let out a long sigh, then tell me: “It just comes from experience…”

I’m now at a point where I’m mentoring beginning developers. They ask me this same question, and, ironically, I’ve been catching myself giving this same response.

Now that I have more experience, I’m much more understanding of the value of it. But I still believe we can give beginners better methods for solving problems than this unhelpful, one-line answer.

In 1945, Hungarian mathematician George Polya attempted to provide such a method through a book called, How To Solve It. Originally written for college-level math students, his method can be applied to nearly any problem, especially coding ones. The four main principles of his method are:

1. Understand the problem
2. Make a plan
3. Execute the plan
4. Reflect on the plan’s success/failure, and what you could have done better

A lot easier said than done! Below is a list of my own strategies (many inspired from this book), that I recently shared with an apprentice here at 20spokes.

On Debugging

When stuck on a nasty bug, ask yourself (before Googling the issue)…

1. Have I truly identified the problem? Could I clearly state this problem to a coworker?
2. Have I broken the problem down into its smallest parts? Can I solve any of these parts individually?
3. Have I listed out all the possibilities of what the underlying issue could be? Try isolating these possibilities. If necessary, create some throwaway code to isolate a scenario.
4. Are there any unknowns needed in order to solve this problem? Eliminate as many unknowns as possible.
5. Have I verified my input? What is my expected output?
6. Have I verified my flow through the application? Am I hitting all the functions/points of the app I’m expecting to hit? Use tools like Pry for Ruby or Debugger for Javascript, or just good old-fashioned console.log.
7. Have I looked in the right places for potential clues, like the browser console, server logs, or network logs?

When debugging, the key is to set up a working situation where you’re able to receive rapid, isolated, and meaningful feedback. The time it takes to set up a scenario in order to get this feedback, either within your app or as external throwaway code, is totally worth it.

On Overall Strategy

When building solutions, developers are constantly faced with scenarios that have no one right answer. These questions can be as small as “what should I name this function?” or as large as “How should I model this database?”

In these cases, it’s a matter of weighing our options. This can be a frightening prospect for beginners, and a common first impulse is to ask a more experienced developer what they would do.

While asking people for their opinion is generally a good thing, you’ll gain respect a lot more quickly as a developer if you’ve already thought through potential solutions before you ask someone else. Your conversations will be less one-sided, and the other person won’t feel like they’re being used to decide for you. Here are my general guidelines for determining whether a choice is the “right” one:

1. How may this solution change over time?
2. Is this solution DRY (Don’t Repeat Yourself)? Will I be placing similar functionality in multiple places? I want to avoid doing that as much as possible.
3. Does this solution have a single source of truth? For instance, will I be looking in different places for the same data?
4. Is this solution maintainable by other developers? How would a developer new to this project interpret this code? Would they understand the name of this function?
5. Have I researched the issue online to see how other people approach similar issues? (Of course, you don’t want to take any old answer you see online. Apply the same method to these found solutions.)
6. Have I checked documentation(s) to verify that certain solutions are possible/not possible? (Have I “checked the docs”?)

Experience enables a developer to more quickly envision possible options, to see what will be difficult or easy to accomplish. Experienced developers have “learned the hard way.” But it’s truly rare to find an experienced developer who doesn’t adhere to some kind of method for solving problems or architecting solutions. It’s simply become more intuitive for them, and thus harder to put into words.

My big piece of advice to beginners is to trust in the methods, and to trust that by following these methods, the experience part will come in time.