One of the most fundamental problem solving challenges that developers face is the question of, "How do I even start tackling this problem?" This question is posed to developers at nearly every stage of development, though it takes different forms depending on the scope of the problem. This repetition of the question, "How do I start?" led me to start considering it not merely as a procedural question to be answered on a case-by-case basis, but more generally as a question of problem solving philosophy:

"Given a new problem, how do you begin solving it?"

It's a tough question to answer! With problems we're familiar with, the answer is typically obvious: we solve them with similar methods to how we solved them the last time! But with new questions, we enter into the realm of having to suss out the boundaries between the familiar and the unfamiliar - and it's undoubtedly the unfamiliar parts that give us pause. So how do we keep the unfamiliar from tripping us up? I think that one potential answer can be found in art: gesture drawings.

Capturing Form

The central theme of gesture drawings is to quickly capture the form of a subject. Rather than trying to perfectly depict the subject, the artists are practicing the skills of conveying more abstract qualities about the subject - often with a focus on stepping away from conscious thought, and instead favoring a fluid approach to capturing the "feel" of the subject. As developers we can embrace a similar technique to start tackling problems faster, and with less time lost to considering things like "where" or "how" to begin, and instead thinking about how to capture the "Form" of the problem.

Form: Scope, Action, and Pose

Making a gesture drawing as a developer is a little different than what artists do - we'll be sketching out the "form" of a problem! What does the "Form" of a problem look like? How do we enter that mindless state of observing a problem and capturing its Form? Let's start by breaking it down!

Scope

The "scope" of a problem is going to determine just how big it is. Are you writing a new operating system? Or are you writing a function that mutates strings? The Scope of the problem is an abstract quality that describes not just the perceived scale of a problem, but can also reflect the complexity of the problem or number of technologies needed to solve it successfully. When you're capturing the Form of your problem, Scope is one of those qualities that should absolutely influence how you view the problem, and subsequently how you will begin to solve it.

Action

"What is this problem trying to accomplish?" It seems like an obvious question to ask, but giving the question proper attention can greatly facilitate capturing the true Form of your problem. Action is a quality that exists outside of Scope, even though the two can easily influence one another. Understanding the specifics of a task is essential to capturing its Form properly. If you're trying to visualize the Form of your problem and you don't know these things:

• what kind of inputs are we being provided?
• what kind of outputs do we want to give back?

then you do not yet understand the "Action" of your problem and should observe the problem further. Understanding Action clearly helps us head-off losing time to functionality that isn't relevant to our specific problem at hand.

Pose

To explain Pose, let's take a Form that we're all somewhat familiar with: the Human Form (legs, arms, eyes - you've seen a human or two, you get it). With our knowledge of the Human Form, let's now imagine that Form performing an Action - let's say trying to lift a heavy rock off the ground. Without knowing the specifics of the Human or the rock, we could envision the various systems at place during this Action. We could see that Human perhaps crouched down, we can intuitively know that this Human will be engaging their muscles to perform this Action; we can intuitively know that this Human's muscles will be using the skeleton to provide support.

"Pose" as an element of Form is having a general feeling for the layout of your solution. What are the systems at play? What are they connected to? How are they laid out? What is the flow from one component to the next? Knowing that your Human is crouching and trying to lift this heavy rock, Pose is more than knowing that you have a Human Form and want to Action the rock - it's recognizing the interplay of the systems that must be utilized to accomplish the Action, and putting them in the right places (at the right times!) to make that Action possible.

Now stop thinking, start gesturing

It's often the process of thinking about the problem that is the sticking point - the desire to solve the problem fully before starting to put down text in your IDE is a common hang-up. We like to imagine that we're going to put down the perfect solution, and that there won't be any problems along the way - and that desire to render a perfect solution can seriously delay the most important step of solving the problem: starting. Consciously suspending the active-problem solving part of your brain seems counter-intuitive, but taking five minutes to figuratively pickup a piece of charcoal and create a "gesture drawing" of your problem will give you an excellent place to jump off and start actually laying down code. Sometimes this means sketching out component hierarchies, sometimes it means sketching out a "no-code" or "faux-code" representation of your problem. These "faux code" representations could be as vague and "gesture-y" as an outright description of what you want to accomplish ("I need a helper method to index into a nested data structure,"), to being a little more granular with specific dummy methods or variables that sketch out the Pose of your Form. Now solving your problem isn't a matter of "where to begin", so much as iteratively adding detail to your Form until the parts that are gestures become working solutions!