Don’t skip planning when learning to program

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?