Developers are at heart, problem solvers. We use code to solve problems for our users, our employer, and even other developers! To be a coder is to be a problem solver. To solve those problems our most important skill isn’t our ability to write code, it is our ability to fully understand the problem we are presented with and implement a solution to make it go away.
It could be writing a parts management app for a regional mechanic, reducing the checkout process from 4 steps to 2 for an e-commerce site, or making a Github action for your team that publishes to your Slack each time a build fails.
These are all quite big problems and you might be thinking “Simon, I’m new to programming, it would take me forever to make one of those!”
That’s fine, because really these are groupings of smaller problems, which are themselves groupings of smaller problems, until we get right the way down to the building blocks of our code.
Each line of code we write solves a little problem.
It is the smallest instruction required to accomplishes the task at hand so that the next line of code has what it needs to solve its part of the problem.
You see, code at its heart a set of very specific instructions that tell a computer how to solve a problem for a user. Having a good understanding of that problem is the key first step to building great software. Let’s take one of the above examples and break it down into some smaller chunks: writing a parts management app for a mechanics:
- Some way for a garage to record that they have taken delivery of some parts
- A place to record what stock each garage has
- Some way for a mechanic to subtract 1 or more items from their locations total when they use a part
- A method to correct the amount of stock a location has for loss, breakages, or prior human error
- Some kind of warning system that tells the central purchasing manager that a location is down to the minimum number in stock
- A way for the purchasing manager to request one location send stock to another location
- Some method for the purchasing manager to place an order with the supplier
Suddenly this feels a whole lot more manageable doesn’t it? (The last problem sounds general enough we could probably hook into an existing service that already offers that kind of functionality)
To prove the point a bit more let’s take the first of those and drill in further: “Some way for a garage to record that they have taken delivery of some parts”. Let’s look at it as a user flow:
- The user opens the delivery screen on the stock manager app
- They tap a “Take delivery” button
- They search for and select the item from the global list
- They set the quantity
- They select if it is a new order (maybe even enter the purchase order number), or if it’s from another store and select a transfer order number
- They click save
- They are asked to double-check and confirm the entry is correct
- The app saves this to the central database
We’ll stop there but you can see that we are quickly breaking this problem down into smaller and smaller chunks without writing a line of code. Once you fully understand the solution to the problem you can present this back to users to make sure you’re correct and then start writing code making sure to get feedback from users at every step of the way.
When you find yourself in an interview and the question of “tell me about a time you solved a problem and tell me the approach you took” it’s this kind of answer they are looking for, breaking down a large problem into smaller and small chunks.
This is one of the many topics covered in the Coding Unicorn E-Book.
One final note:
Many of the small problems above are common to many, if not all software projects, so breaking your problem down and identifying the generic problems will allow you to find pre-made solutions that are industry standard, so you can focus on adding user value and not reinventing the wheel. Things like databases, UI frameworks, libraries to make network requests are all common tasks and there is no point in writing that stuff yourself from scratch.