Breaking Down Problems Into Ever Smaller Parts, Smaller and Smaller

Breaking Down Problems Into Ever Smaller Parts, Smaller and Smaller

So this is not your usual Software Engineer Princess blog post but we have to try something new sometimes and we have to change our minds.

My mentor has sent me some amazing notes on how to break down problems.

So I wanted to go over the quotes that he sent me, and analyse them bit by bit. I hope he doesn't mind. I hope that that is alright. Thanks. 

CodeWars

I like CodeWars, and I like solving CodeWars problems, so my mentor has tried to phrase software engineering problems to me like that:

When approaching a new task: "start by writing the "codewars problem" that you are trying to solve.

So what the requirements are; and then, think about the inputs, and the outputs.

So every time I am breaking down a feature problem I want to think: what is the codewars problem here? And if that is too big I want to think, what are the aspects of this feature? What are the components? And then once I have the feature broken down into small components, I can start to think about: what are the codewars problems too? What are the inputs and the outputs?

"Remember that comments can represent toasters with inputs and outputs"

This is a comment from my mentor that confused me a little.

How could a comment represent a toaster with an input and an output? But I guess the key thing to keep in mind all the time throughout writing the function and while writing it: okay what do we do here? At this point we take in a list - okay so now I know that we take in a list - well what do we do? I know that we loop through it, right? Okay we send an email - it's not what we RETURN from this function but it is an OUTPUT here - okay so what do we do here - I know that we RETURN something please from a function - great.

"Knowing the types of the inputs and outputs really helps."

Pink puzzle pieces and bright blue html tags. Text reads breaking code down into smaller and ever smaller parts. How any feature can become a codewars problem. Even the most complicated one.

I sought further feedback and guidance about this

I asked "why is a comment like a toaster?" (Why is a raven like a writing desk?).
And we established that every comment was a thought. And then, well, what kind of thought is a comment? And the answer is that a comment is a step - right? A step of what we are working towards in the process.

And a comment can also include something like a requirement.

Adding Comments

Even if we want to break down the steps, it might be helpful to add some extra comments, or even more, then, about how each step is implemented and what we think that we might be able to do/want to do/should do.

"Comments describe overall parts of the algorithm and each part can be thought of as a toaster with inputs and outputs. The types of inputs and outputs are very useful for understanding how to implement a toaster. Knowing that the input type is X, and the output type is Y, helps to remove any ambiguity."

One thing that you can do is that you can add in the requirements into the comments

So if you are commenting that you should send an email, you can add in two of the things that the emails actually have to do.

So for example (like) check that we have the right email addresses, or rather, as my mentor has put it better, if we want to send an email to a user telling them what their favourite colour is, 

def send_favorite_color_email_to_users() -> None:
    # get users from the database
    for user in users:
        # send email
        # - email must be sent to the user's email address
        # - email must contain the user's favorite color

Can you see the two requirements that we have listed there? The email must be sent to the user's email address; and the email must contain the first one.

  • Things that sound obvious are not so obvious in software
  • Yes of course the email has to be sent to the users email address - but what if you were the one who is literally building the software that sends the email? Well that is us! Not so simple anymore...
AND THEN WE CAN LOOK IN THE CODEBASE - AND TRY AND FIND AND TO SEE IF THERE ARE ANY PRE-EXISTING FUNCTIONS THAT DO ANY OF THE STEPS FOR US.

AND THAT DO ANY OF THE CODE FOR US.

"Codewars problems range in complexity. A 6 kyu codewars problem may contain multiple Level 7 and 8 kyu codewars problems to solve."

"These are toasters of varying levels of complexity."

"The way you are approaching 7 kyu problems by writing the algorithm in comments and gradually turning them into pseudo-code and real Python applies to every complexity of problem."

You can take it right down to a level 1 kyu problem and realise there are smaller problems contained within it, simpler and of lesser complexity.

A big problem will contain any number of smaller problems. If a problem is very complex, drawing a diagram of the high-level and smaller problems is a good starting point. "Keep breaking it down" until they are much smaller problems.

"Then each one can be solved with the comments -> pseudo-code-> Python code approach."

This is the important part

The approach should be more or less like:

  • Write comments
  • Write pseudo-code
  • Write Python code
I got a bit confused about the first two but I clarified it with my mentor. They are not necessarily independent steps - for example in the past I have interspersed my comments with my pseudocode naturally.
  • pseudocode can also start to add things like:
    • defining variable names
    • adding control structures
      • like if statements
      • or for loops
  • which is not quite valid Python yet
  • but this is before thinking about whether or not the code is valid Python

"The comments are a translation of how you solve the problem mentally - they're your mental algorithm that you come up with for solving the problem."

"Then the comments get translate into the end result which is a working implementation."

What about drawing diagrams, how about those, should I be drawing them?

"Drawing diagrams is a great idea and I'd start with a diagram if the problem is too big."

"Then you can take parts of the diagram which are small enough to start writing comments for, and then turn that into code."

"Breaking it down in that way results in solving complex problems in small steps."

A big problem will contain any number of smaller problems. If a problem is very complex, drawing a diagram of the high-level and smaller problems is a good starting point. "Keep breaking it down" until they are much smaller problems.

"Then each one can be solved with the comments -> pseudo-code-> Python code approach."

I love the wind farms and I love the pylons

I love the wind farms and I love the pylons

Everything I do I do it for the pylons

Everything I do I do it for the deep deep love of the forest.

I find love in the forest

If I want to find love I do not have to look much further than the forest. There's nothing I love more than the trees.

If I want to find love - and this is the love which we all already all are - then I don't have to look any further than the forest. I never have to look any further than the forest. But what is the forest? Is the forest one last tiny leave? Is the forest one last grain of soil? Is the forest one of my favourite trees, one of my favourite clifftop sets of trees? Is the forest the way I feel when I am walking inside of it? Is the forest the deer I once saw that bounded vertically up the cliffs, cutting across my path, and showing off to me her beauty and power and prowess and grace as she flew horizontally? Is the forest the secret lake in the middle of the trees? Is the forest the narrow path that I once terrifiedly walked across as I tried to navigate it post injury?

Or is the forest the magical internet tower that I see from all parts of the forest?

A few bangin' quotes for you today:

  • "When everything that can be let go of is let go of, what remains is what we desire above all else."
  • "In ignorance, I am something; in understanding, I am nothing; in love, I am everything."
  • Both are from The Ashes of Love, by Rupert Spira 

Codecademy is my happy place

I love doing courses. I love the UI. I can't wait to do some more courses today.

But just please remember that I am slowly moving away from being a courses engineer and moving more and more towards being an I BUILD AND DELIVER FEATURES engineer. But still some more courses to do
  • Intermediate Python
  • Django
  • Advanced Python

    Comments