CodeX
Published in

CodeX

Don’t skip planning when learning to program

Man planning on a glass board

Photo by Diggity Marketing on Unsplash

The computer is not a machine like in a factory where productivity is dependant on you pressing the buttons frequently. The computer is much more efficient if you relax, take your thinking time and plan.

Having taught Mathmatics and Computing for a number of years, I gave this piece of advice in a previous blog. In reflection a lot of learn to program courses still seem to neglect the planning process. Planning is an essential skill to learn on the path to learning to program. However; like showing ones working in an algebra problem, it’s somehow still “uncool”, and we are still reluctant to do what seems like “useless work”.

Part of the problem when beginning programming is that starting a problem is often quite daunting. Knowing how to plan is a key part of tackling a problem.

So in making the effort to plan — the next question is how?

Analysis

All projects are different, but they all start with breaking down the problem.
Things to note, and ask about:

Who is paying for the project. What is the problem they are trying to solve? Theanswer to this for many of your first projects may be yourself, and the problem might be wanting to know how to program. Thats fine, but sometimes having a context to work towards makes things easier. I often use my CV as a starting point. It’s rarely for recruiter consumption, but it helps to have something to work towards.

Who will be using the project? Is the user the same person thats paying for the project? Is there more than one user? Most non-trivial problems may have more than one user. Think about a simple shop app, there may be different screens for the customer looking at a product, the customer making a purchase, the warehouse operators picking and packing the product, the retailer analysing the shoppers habits. What information does each user want from the system?

What information does the project need to handle. In this case it is often prudent to start from the outputs and work back to the inputs. For example the warehouse picker needs to know which product to pick, and where its located. Tracing these two pieces of data back — where does the system get the info? In schools we often start talking about variables here. This is too early, just identify the big picture.

The warehouse picker wants to know the product to pack, the customer will need to input a product when entering their purchase.

Design the Interface

This is the time to start mapping out how the conversation goes. depending on the nature of the interface design the conversation. Whetehr you are using a web page, console app, or background worker, there is still a conversation happening. If your fingers are itching to fondle the keyboard at this moment you could use mermaid to assemble a good set of diagrams.

After the conversation, its time to do one of two things. Either design the data, or design what the user sees. I’d always suggest designing the interface first. Start with paper, before heading to one of the many tools you can use to polish things up with. The advantage with paper is its tactility. sketch the broad picture first then fill in the details. Switch to digital once you have a nice first draft.

Designing the data, OK back to mermaid here. Keyboards are nice to touch. start with the broad strokes of an ER diagram, before filling in the details with a class diagram.

If you’re a student then the next step is pretty much just to show you’re thinking. For some reason software planning has students here going into doing pseudocode. This is the planning step that gets planning its bad name. Commercially the previous steps are done for a developer by a team of BAs product managers, and the such. Pseudo-code is nice to demonstrate that you know what you’re thinking. But once your familiar enough with any language, its an unneeded barrier.

I’d suggest a better planning step here is to enter into the test driven development (TDD) cycle. Start somewhere in your class diagram. Make a failing test for part of it. Create just enough code to make all the written tests pass. Tidy up the code, without breaking it, and repeat. When learning code wasting time off the computer doing pseudo code is frustrating, and false. Maybe replace the pseudo code with documenting the code?

--

--

--

Everything connected with Tech & Code. Follow to join our 900K+ monthly readers

Recommended from Medium

All You need to know about Cloud Computing

How to run OpenCV on STM32 MCU

Powerful Regular Expression

The Lockdown Coder: Getting to Grips with Flutter

How to Build a Bayesian Calculator in Python

Reasons why developers make apps for Android rather than iOS

My personal journey into the Cloud!

Could Your Child’s Best Friend Be A Robot?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Brian Jones

Brian Jones

Coder, Dad,

More from Medium

How To Become a Better Developer

6 Youtube Channels To Follow If You’re Just Learning To Code In 2022

2 things I wish I knew before I started to code.

Learn All About Coding: Top Coding Books For Kids

Learn All About Coding: Top Coding Books For Kids — Verzeo