What do you think is the most important skill to become a better software engineer? Writing code efficiently? Being a quick learner or maybe communication and team work? All of this is important to thrive as a software engineer but there is something the best software engineers do that others fail to do.
The most important skill for software engineers is to know when not to write code at all. You will see why this such an important skill, when it makes sense not to write code and what you need to do to get good at it yourself.
Better software engineers save costs
Not writing code saves money in many ways because software engineers are expensive. It’s therefore wise to only let them write code that can pay back that cost. Every line of code not written saves the business money. Furthermore, every line of code written is a liability which incurs further costs. You have to run, monitor, maintain and test it – all of which costs more money.
Good software engineers spot bad ideas early
Do you know what the “cost of change” is? To paraphrase: Ideas are cheap, code is not. To change a requirement in a Jira ticket is pretty easy. The further an idea moves towards its implementation the more expensive it gets. It’s cheaper to change a wireframe than to change a fully-fledged screen design. And it’s most expensive to change something once it’s developed and deployed.
That means for you as a software engineer to become more valuable for your organisation you should be able to spot bad ideas as early as possible and stop them in their tracks or to transform them to something better.
Complexity destroys usability and good software engineers know it
When you just build everything that could bring in a bit of money soon both your product and your codebase will be cluttered and unusable. So it’s important not to treat feature requests in isolation. A simplistic view could look like this: It takes us $10.000 to develop and we will earn $500 per month on the feature. Therefore in 20 months we’ll have made our money back and everything else is free profits.
But this simplistic view falls apart rather quickly. Your feature consumes resources. It needs to be maintained. Your feature might only be used by 5% and will make it harder for the other 95% of customers to find what they really need.
As a software engineer you spend time on maintaining the code and it makes the codebase harder to navigate, potentially causing edge cases or slow test suites.
The most important skills how to become a better software engineer
If you want to become a better software engineer you should build your radar for knowing when not to write code. Following are a few strategies to do that.
Get better at dealing with uncertainty
Ideas are a fuzzy construct with a lot of unknowns. So you need to learn how to work with that uncertainty. A great way to do this is to practice your back of the envelope math. A great framework for making such calculations is the RICE prioritisation framework. You just assess the reach, impact, confidence and effort of any idea and get a clear picture to compare ideas against. Most ideas fall apart with such a quick assessment already.
You can equop an idea with your rough calculations to make them more graspable for stakeholders. As a software engineer that means knowing a bit about the business and industry you’re operating in. If you know that your company has 500.000 paying customers and the best case is to convert 1% to a higher paying plan you can calculate a dollar value you can speak with non-technical stakeholders about. The same goes for the cost side: You can roughy assess how much an engineer earns, how long a feature would roughly take and other costs. With those numbers you can make a clear case to either move ahead, refine or axe an idea.
Practice your rule of thumb estimates with real world examples
So in order to improve your software engineering skills you can practice more quick and rough calculations. It’s a fun game you can play with other companies as well. Got a cool new idea yourself? Try to get a realistic number of how many people would want to pay for that, how much you could charge and how much operations would cost you. This will strengthen your communication muscle with business.
Technical implications can change the outlook and design of a feature tremendously. There is an interaction between product and tech and you can become the expert in that field. To be able to understand the technical limitations and implications of a feature you need to apply your knowledge about the technology stack as well as business specific knowledge and then apply the “back of the envelope” math we talked about before.
Here’s an example: Your product manager of a note taking app has the great idea to allow your customers to store HD images. You can quickly calculate your active customer base * the uploaded pictures * a few MB and then figure out how those could be stored and at what cost. Depending on how much you charge it might be a terrific or a horrible idea. Maybe you also know that you already have data storage issues to a product like that won’t be feasible with the internal infrastructure at the moment.
You don’t need to build everything yourself
There is something between writing code and not writing code. Maybe an idea is feasible but the organisation just isn’t set up to implement it right now because it’s a bit out of everyone’s core domain. Let’s go with the example before and assume that the image storage for your note taking app is an economically feasible idea. But the technical limitations prevent it. As an engineer the solution might be simply to store the data in the cloud with Amazon S3.
So an important skill for software engineers to decide whether you should write code or not is also to know the ecosystem you operate in. Oftentimes there are existing solutions you can simply use. A great example are CMS. You probably have heard of WordPress but there other more flexible solutions like API-based CMS like contentful.
As software engineers we like to build things but that doesn’t make it the right choice at all times.
You will need help your stakeholders find the essence of their idea and see how it can be solved with even a simple Excel sheet or other no code/low code solutions.
Understanding people’s needs
You need a lot of empathy and a basic understanding of user research if you want to be able to identify their core needs. Otherwise you get lost in all the unimportant stuff people like to share. After a while you might see the point in ideas like user centric design, design sprints and user interviews. At the same time your product management skills strengthen as you learn about prioritisation techniques like MuSCoW or cost of delay
The best software engineers don’t identify with their code
If you want to become a better software engineer you need to stop identifying with your craft and focus on what brings value. In highly specialised world it’s important to have someone who build bridges between business, product and engineering. This could be you. If you want to get better in knowing when not to write code you can:
- Get involved in the ideation process as early as you can
- Practice your “back of the envelope” math to evaluate ideas quicker
- Become an expert in the company’s technical system and its limitationsn
- Learn about solutions outside your core expertise like low code and no code solutions
- Understand what people want by exploring user research
- Explore prioritisation techniques so you can dismiss the unimportant stuff
The most important skill for software engineers it’s about knowing when not to write code but with this comes a whole lot of other skills. Your goal is to become a more holistic software engineer who builds bridges between the business, product and engineering.