How often has it happened that you start on a simple ticket to add a field to the database, populate that field and display the data in the app and yet 6pm approaches and your brain is about to explode, your thoughts are gridlocked and your simple feature still isn’t working?
That feeling of your brain about to explode is the cognitive load you’ve lumped on yourself by trying to digest the complexity of that task all in one go.
Programming is hard. It’s too easy to forget this as you progress and begin to master new skills. Even as you get better, you are still asking a huge amount of your brain when engineering software and there is a limit to how much complexity it can handle at one time.
This doesn’t mean there is a limit on the speed at which you can develop though. What it means is that you have to control how much complexity you are dealing with at any one time to make sure that your thoughts don’t reach gridlock.
As your confidence as an engineer grows it can be tempting to jump straight in and start building something. But would a civil engineer’s first step on a new site be to unleash the bulldozers? Or would a mechanical engineer fire up their welder and blowtorch immediately? The free cost of writing software shouldn’t mean that planning is neglected, it’s hugely valuable and will help your brain keep working at full capacity, keep you moving forward and stop you stalling.
Planning out a software task allows you to break down a complex task (which is any programming task) into smaller, less complex, tasks that you can then complete in order, tick off and put aside.
The power of approaching your work like this is that everytime you complete a small sub task, confirm that it works and put it aside you can unload that complexity from your brain so that you have the same capacity to work on the next task as you did on the previous.
Practical advice
For this to be most effective you have to plan out your work like a one-way street, you only want to be working forward and never going back. The secret to making sure you never go back is thoroughly testing each step and confirming 100% that it works as you want it to.
Exactly how you go about planning work like this is up to you but I will give an example below on how to breakdown the development of a feature that requires creating a new schema in the database, a new endpoint to retrieve that new data and a new view to display that data in the app.
A useful way of mapping out what steps are required is to think of the flow of data like the one-way street mentioned above. Where does the data start? Where is it finally being displayed? What is the path it follow between those two points?
The Second Nature tech stack for a feature like this can be broken down into:
- Database schema
models/*.js
- Express endpoints
controllers/*.js
- Test with Postman
- Calling the endpoints in app
api.js
- Use the VSCode debugger to check what you’re fetching
- Storing the data in redux
reducers/*.js
- Use the VSCode debugger to check what you’re storing
- Displaying the data in app
components/*.js
Finish each stage completely before moving on to the next one. That is how you will reduce the cognitive load you’re undertaking and it’s the number one way to 10x your development speed.