Design decisions. Or at least, they’re one of the things that comes next.
Code either works or it doesn't. With design decisions, things aren't as black and white. Alice decides to use redux to store all the state in her react app. John decides that he's going to use ECC instead of RSA for encryption. Sarah creates one users table to store 3 different types of users.
Are these good decisions?
We can’t know.
Code is always a means to an end. It’s never an end in itself. When we make (design) decisions about how to structure it, they need to be evaluated in view of the code’s purpose. We can’t know whether Alice, John, and Sarah made good choices because we don’t know what they were building and why.
For example, let’s say Alice uses redux for the first time for a side project. It increases the complexity her app and makes it harder to understand and work with than it would have been had she left redux out.
Was using redux a good choice? We can say (in this case) that using redux increased the project’s completion time and maintenance cost. We can also say it helped Alice learn redux.
Let’s say Alice’s goal was to learn redux. Maintenance isn’t an issue because she doesn’t plan to maintain the project and completion time isn’t an issue because she has a lot of unstructured free time. In this case, it’s fair to say using redux was a good choice in view of this goal with minimal downside.
In another scenario, let’s say Alice’s goal was to deliver an easily maintainable, working application to a client as quickly as possible. Here, it can be said that using redux was a poor choice in view of this goal because it increased completion time and maintenance cost.
At companies, things get more complicated. There are multiple, competing goals. The CEO wants to launch as quickly as possible. The CTO wants maintainable code and minimal tech debt. The product team wants a large feature set. Design wants pixel perfection and cross-browser compatibility.
Time and resources are limited, so priorities have to get made by the business. These priorities then become the basis for the design decisions that get made in the code. (NB: In an ideal world these decisions are settled by the time work gets assigned to an engineer, but in practice they are often not)
To be an effective software developer, you need to make sure the design decisions you’re making align with priorities that exist beyond the context of the code.
If you’re new to development and this seems daunting, don’t sweat it — this is a skill all developers are honing all the time. Simply being aware of this as an area for growth will you enable you to cultivate this skill as you gain more and more experience as a developer.
Top comments (1)
Agreed, even in solo projects I've found it's more important to design a roadmap before jumping to the implementation. Programming is a tool, so you'll find a lot of people who can do the implementation part but not everyone can do the design part as successfully.