Writing code is easy
That is right, writing code is not a big deal. Engineers that just started their software career would beg to differ, but let me explain.
What does code represent?
At the end of the day, code is just instructions we pack together and send to the computer, so it can do its job. These instructions can be written in various languages and frameworks, but this does not matter at all for the computer. The variety of technologies matter more for us, the builders, the ones that actually use them to provide code.
But what job does the computer do? You would think: “it is clear, the computer compiles and runs stuff”.
You’re right, but you’re also wrong. This is the technical job, the process, but the real job is the business value the computer generates after running our code. That’s the real deal, that’s what you are paid for. And that’s what you have to teach your computer to do.
The computer does not care about the business value of the code. We do. Stakeholders do.
Lean back on your chair a bit and ask yourself this question: “does my PC care if the code I wrote does the right thing?”. If you answered no, then you understood where I am pointing at.
Value matters, code does not
As I said before, code means nothing without an intrinsic business value attached to it. This business value has to be the main driver behind writing code.
How do you define value?
This is a tricky question. Value is often defined by the stakeholders and then expanded upon by the product owners. However, we, the engineers, are also responsible of reflecting this value in the code we produce. So, at the end of the day, we have to make sure that we understood precisely what value we have to instruct the computer to generate.
This is one of the most overlooked steps in building good software. More often than not have I seen juniors that started to strum their keyboard without knowing exactly why and how.
In order to write code that matters, you have to understand why you write that and what will it produce, what parts of the system will it influence and so on and so forth.
Architecture is in everything
Architecture is not reflected only at system level. That is macro architecture and that is usually done by the solution architects. And yes, that is the most popular and the rockstar of software industry. But even the thinnest piece of code has to have an architectural basis.
The code’s architecture is basically the plan we have to set up before actually starting writing code. It has to define our code’s boundaries, interactions and outputs.
Failing to plan is planning to fail — Benjamin Franklin
You surely know that Benjamin Franklin was not a software engineer. But if he were, he would have probably payed a lot more attention to fine details and architecture, than he would have payed to actual writing code. Why? Because this thought process ensures the value that will be generated.
And this is, indeed, the hard part. And the one that matters the most.
Code is just a means to an end
Stop treating code as something worth of your attention. Code is just a tool. The framework you are working in is just a tool. Do you pay attention to your screwdrivers? Or you pay attention to what you achieve with those screwdrivers? Writing code is like using a screwdriver to build a system.
What matters is the reason of creating this particular code. Just like the reason of using a screwdriver.
One of the biggest sins in software industry is giving code too much credit and giving architecture, planning, communication, design too little credit. In the end, it’s those things that are not tangible that define the outcome of the code we write.
One of the most important things I teach my Web Programming students is to learn to communicate, plan and design before learning how to write code.
So yes, in conclusion, writing code is easy. Making sure that the code will generate real value is actually the hard part.