DEV Community

loading...
Cover image for How to Solve Any Algorithm

How to Solve Any Algorithm

nielsenjared profile image Jared Nielsen Originally published at jarednielsen.com Updated on ・5 min read

This article originally published at jarednielsen.com

In 1992, Mary Oliver published Poem 133: The Summer Day, which ends with a question for the reader:

Tell me, what is it you plan to do with your one wild and precious life?

What do you plan to do? Are you going to spend your one wild and precious life solving the same problem over and over? Or, worse yet, working on the wrong problem?

We want to work smarter, not harder.

How do we do that?

Lucky for us, there's an old school approach to problem solving that is still relevant today. It's called, you'll never guess...

How To Solve It

In How to Solve It, George Polya outlines four steps of problem solving:

  1. Understand the problem.

  2. Make a plan.

  3. Execute the plan.

  4. Evaluate the result.

Understand the Problem

If you're a good developer, you'll realize that the best solutions emerge from listening to your customer tell their story. Many alogirthms are disguised as story problems, such as the farmer who needs to get duck, corn, and fox across the river. But! He can only carry one of these at a time. If left alone, the duck will eat the corn and the fox will eat the duck. How does he get everything across?

Story time.

User story time, that is.

Yeah, I know.

They're awkward.

They feel like work, don't they?

But the thing is, they work!

The format for a user story is:

AS A < USER OF SOME SORT >
I WANT < TO DO THIS >
SO THAT < MY EXISTENCE IS VALIDATED >
Enter fullscreen mode Exit fullscreen mode

In our farmer example above:

AS A farmer
I WANT to ferry my duck, fox, and corn across the river
SO THAT we all live happily ever after
Enter fullscreen mode Exit fullscreen mode

Reframing a problem as a user story then makes it very easy to write acceptance criteria.

The format for acceptance criteria is:

GIVEN < APPLICATION >
WHEN < I DO THIS >
THEN < I EXPECT THE APP TO DO THAT >
Enter fullscreen mode Exit fullscreen mode

In our farmer example above:

GIVE three items that will eat each other
WHEN I ferry one item across the river
THEN the other two are safe
Enter fullscreen mode Exit fullscreen mode

Make a Plan

The next step in Polya's heuristic is to make a plan.

AKA pseudocode.

You write pseudocode, don't you?

Writing pseudocode is like making a sketch for a design.

It's your back-of-the-envelope proof-of-concept.

It's your discovery phase, your user research, your market validation.

It's your roadmap.

It's also the comments for your function. Just // each line and there you go.

Execute the Plan

It's show time!

After all this problem understanding and plan making, it's time to crack your fingers, dust off the keyboard, and write some code! This part will be easy because why? Because you wrote pseudocode! All you need to do now is translate that plain language into JavaScript, Python, or (shudder) Java. Then hit Enter...

Evaluate the Plan

Did your plan work?

If no, back to step 1.

If yes, can you do better?

How to Solve It with Computational Thinking

The steps above are table stakes for problem solving and can be applied to any domain. If you want to turn pro, you need to assimilate with the Borg and learn how to think like a computer. There are four primary stages of computational thinking:

  • Decomposition

  • Generalisation

  • Abstraction

  • Algorithms

Decomposition

If composing a function is the process of assembling the various components, such as variable, control flow, and conditions, then decomposition is the opposite: it's breaking a problem down into smaller parts. This is both the easiest and the hardest step in the process because sometimes the component parts of a problem are obvious, but other times the component parts are emergent, or intertwined, and it's difficult to cleanly separate them.

How does our farmer decompose?

Well, yes, he makes compost.

He also thinks through the problem.

If there was only one item, he would simply need to carry it across the river.

If there were two items, he would need to carry one across the river, then return for the second item and carry it across the river.

If there are three? He would still need to carry one across the river, but he would need to ensure that the two left behind did not destroy, or should we say, decompose, one another. In thinking through his items he sees that there is only one combination that can be safely left alone: the fox 🦊 and the corn 🌽. The duck is the crux of the problem! 🦆 He sees that he must carry it across first.

What does he choose when he returns for the second item? It doesn't matter. Either can be left alone and neither can be left with the duck.

Do you see a pattern?

Generalisation

In decomposing the farmer's problem, we revealed a handful of crucial components to a solution:

  • conditional statements

  • repetition

  • logic

Another way of saying this is that we recognized patterns.

A useful question to be in the habit of asking yourself is: where have I seen this or something like it before?

Abstraction

Once we recognize patterns, we can remove the details, or form abstractions.

What if it wasn't a farmer? What if it was a lawyer? With three clients who would eat each other and they needed to get across town to the courthouse.

Or what if it was a space shuttle transporting lifeforms to another planet and we needed to find the right combination of carbon and oxygen producers?

It no longer matter who or what it is. What matters is that we can remove the details in order to form a conceptual model and focus on the relationships between concepts.

Algorithm

Now we simply need to write a series of repeatable steps to solve our problem, and, like above, evaluate its success.

Where have we seen this or something like it before?

🤔

How to Solve Any Algorithm

You can solve any algorithm using Polya's heuristic and computational thinking. Like your health or your retirement, there's no shortcut to learning how to solve algorithms. Do the work. Practice makes practice.

Give yourself an A. Grab your copy of A is for Algorithms

If you want to stay in the loop, sign up for my newsletter, The Solution.

Discussion (24)

Collapse
sharpninja profile image
The Sharp Ninja

With the duck on the far side, neither remaining item can be brought over without failing the outcome as the fox will eat the duck when returning for the corn or the duck will eat the corn when returning for the fox. The algorith is missing a cage for the duck to always protect it from the fox and the corn frim the duck. Sometimes critical analysis shows where a flaw in the system can only be fixed by adding complexity.

Collapse
sbleks profile image
Bleks
  1. Farmer brings duck to side b
  2. Farmer goes back to side a
  3. Farmer brings fox over to side b
  4. Farmer brings duck back to side a
  5. Farmer brings corn to side b
  6. Farmer goes back to side a
  7. Farmer brings duck to side b

This way the Fox is never left alone with the duck and the duck is never left alone with the corn while getting all three to side b. No need for a cage!

Collapse
sharpninja profile image
The Sharp Ninja

Cool! But the cage is more efficient. ;)

Thread Thread
pengriffey profile image
pengriffey

The cage is less efficient

Thread Thread
sharpninja profile image
The Sharp Ninja

The cage requires less trips, plus you can stack stuff on it. Put the fox in another cage and lash them together for more efficiency.

Collapse
naveennamani profile image
naveennamani

Simple solutions do exist when you "think outside the box".

Collapse
keskyle17 profile image
Chris Briggs

Interest article. The value of understanding how to construct truth tables to resolve problems during the decomposition stage is invaluable to programmers. Some investment in logic and discrete mathematics is worth its weight. I recommend Discrete Mathematics and it’s Applications.

Collapse
nielsenjared profile image
Jared Nielsen Author

Of course! Or should I say, O(f) course? I'll put this in the backlog. It would make a great future article. Thanks for the book rec. I'll check it out.

Collapse
lluismf profile image
Lluís Josep Martínez

All you need to do now is translate that plain language into JavaScript (shudder) , Python, or Java

Collapse
anagheshmuruli profile image
Collapse
bam92 profile image
Abel Lifaefi Mbula

Thanks for this interresting post. I've written a post on how to write a pseudocode here.

Collapse
nielsenjared profile image
Jared Nielsen Author

Nice work on the pseudocode post. I found the verbs particularly useful. If anything, I would recommend/request examples of their use. Cheers!

Collapse
jp7webdesign profile image
João Paulo

Great article. Congratulations.

Collapse
rohithv07 profile image
Rohith V

Great article with a nice example

Collapse
jighdan profile image
Reinny Almonte

Great Article!

Collapse
lluismf profile image
Lluís Josep Martínez

The first algorithm I was taught in a programming class was how to make a french omelette.

Collapse
nielsenjared profile image
Jared Nielsen Author

You know what they say, "If you want to make an omelette, you gotta break statement..."

When I was teaching, I used how to make peanut butter & jelly sandwiches as the first algorithm.

Collapse
cebuka profile image
cEbuka

Insightful article

Collapse
hseritt profile image
Harlin Seritt

We all do this to solve any problem, we just don't know it to where we can articulate it well. If you constantly freak out over solving problems (esp. in the technology sector), bookmark this article.

Collapse
lainz profile image
Collapse
manolopez profile image
manolopez

something interesting and disturbing indeed.

Collapse
mmanflori profile image
flutterCode

Great article. thx

Collapse
souvik88 profile image
Souvik Kundu

Great article. Thank you.

Forem Open with the Forem app