!Plan to Fail

An educator’s approach to coding

I’m a former educator transitioning to a career in code.

After only a few short weeks into my coding bootcamp, I can already draw so many comparisons between teaching and coding. For starters, both fields will immediately break you and humble you to the very core of your soul. Aside from that tasty nugget, both are unexpectedly much more dependent on good planning skills over good technical skills. That seems weird. Let me explain…

When I first made the decision to take the leap, I started out, as many people often do, learning to code via online tutorials. These were all pretty straightforward, filled with mini-lessons and mini-challenges as you progress through modules. I would be taught how to do a certain kind of method, then immediately practice it in a very sheltered and safe environment. Things came pretty quickly. I was GETTING it! I pictured myself as one of those cool hackers in all the movies (could I actually be that cool??) I even had moments when I boldly dared to think to myself, “…maybe coding wasn’t all that hard.”

That’s cute.

I quickly realized the error of my ways as I completed the last few labs of my Flatiron School pre-work and started my Software Engineering Immersive program a couple of weeks ago.

Things got much more difficult reeeeaalllll quick.

It was not until after my first week of classes that I finally had a light-bulb moment.

I was still approaching the work the way that I was during those online tutorials. (And my first year of teaching.) I was immediately trying to jump right in and start writing methods, make classes, or create relationships between Ruby objects in code as soon as I finished — or, well, let’s be honest — barely skimmed the README for a lab. Did I so naively assume that beautiful, clean, and perfect code would just flow from my fingertips?? Oh my…

Well, I can tell you, it most certainly did not.

As I sat and struggled …and struggled …and struggled…I found myself slipping back into my “teacher mode”. I started to approach code in a different way:

Rather than rushing in to start writing lines of Ruby immediately, I stopped, slowed down, and I broke it into chunks and took time to think through the logic needed to solve the problem and plan my steps — just like I did when I planned for lessons as a teacher. Here’s the basic idea:

Backwards planning approach

How can this approach be applied to code?

1. What do I need to end up with?

Start by thinking of what value you need returned from the method. (Beginning with the end in mind.)

2. What do I currently have?

How can I reference or work with this information?

3. What steps do I need to take to get me from POINT A → POINT B?

Take the overall problem and brake it down into detailed instructions that the computer can carry out. HINT: Pseudocode is a huge help here!

4. Write some code. (test, edit…rinse, repeat)

Learn how to test your code! Do not code blindly! You aren’t that good. :-)

The big takeaway here: Don’t think about programming as writing lines of code. Programming is a logic-based problem solving activity that eventually results in some code.

Let’s look at an example:

I have two arrays and I’ve decided that I want to put them together to make a full sentence declaring my undying love for PB&J’s.

Follow the steps

1. What do I need to end up with? — I’ll need a longer string made up of the shorter strings in both arrays.
2. What do I currently have? — I have two different arrays, one assigned to the variable “a” and one assigned to the variable “b”. I notice that the strings seem to already be in some logical order — assuming I’ll be reading my PB&J sentence like I would read a book. Cool.
3. What steps do I need to take to get from POINT A → POINT B? — Well, I need to know what methods I can call on arrays. So I’ll Google that. I found that the .join method might be useful here — .join returns a string created by converting each element of the array to a string, separated by the given separator. Seems like we’ve got a good start here so pseudocode that out: array a + array b.join(with separator).
4. Write some code.

To make it more readable I also added a new line at the end and printed what the method returns in the terminal so we can see it. Voila! CODE! — and most importantly — WORKING CODE!

Another example:

Let’s say you have a program relating artists, paintings, the art gallery, and the price of the paintings. We want to find the price of all the paintings.

1. I know I need to return a value at the end of my method.
2. I have values currently. (In the instance variable that we set ‘@price = price’.)
3. So how can I break this down to get my desired result?

• *Insert Google search here* and I find that the .reduce method can be used to take an array and reduce it to a single value. Perfect! (a.k.a. .inject method)

The ‘0’ in the reduce argument sets the initial value. Cool, so I should be able to add the price of each painting to get a final total. Essentially…

start with sum = 0 then iterate through the array of Paintings do |something| and add the price of each painting.

4. Let’s write some code.

The .reduce method uses two parameters in the method |sum, painting|. The first parameter, ‘sum’, is the total that will eventually be returned from our method. The second parameter, ‘painting’, is the variable we iterate through from the array. So, with ‘sum + painting.price’ we are telling the method that we we want to add the price of each painting to the sum each time we iterate through the array.

Would I have come up with this off the top of my head? hahahahaha. no.

It took some planning and logic.