Go back

Software Engineering is More Than Just Coding

Created at: 2024-07-09 02:05

Last updated at: 2024-07-09 14:13 (36cce82)

Reading time: 6 min read (1006 words)




Table of Contents

I have a strong believe that most of the time, there is a clear separation between two concerns: software engineering and coding. Both look similar, both work together, but they aren’t the same.

Software engineering is more than coding on the aspect that envolves more about your work than just your pull request at GitHub. It’s more about the processes and patterns that you apply through your workflow that impacts what I mean by engineering here, in this blog post.

Software engineering is about the guarantee that, from the macro perspective, the product and the code that are you working on will correspond to the expectations that they have, both from the product and technical sides.

About the product side, it follows the expectations around the culture and what your company, product or anything else you working has, like:

About the technical side, the core properties that should be follow in my vision are:

About my thoughts around what I believe that are a responsibility of software engineers that are more than coding, I will wrote some of my thoughts below:

Documentations as a Resource for the Future

Documentation is one of the most important part of a project, in my opinion. It’s about the guarantee that the decisions and the resources that you have at the moment you wrote a code have been saved in a way that can be validated in the future, by yourself or any other developer that will need to maintain your code.

Having a powerful context of the past decisions brings for the table the ability to review it and understand why some options have been took or not. Some projects have been wrote by people that isn’t on the company anymore and you can’t contact them, then think how much easy would be for you when you try to run that old project if they have at least one documentation about “How to run Project X”.

Documentation brings to you a safe guarantee that, in the future, yourself from the past prepared all the place answering some of the future doubts that could exists.

Documentation should be a atemporal feature for anyone that wants to build a resilient, scalable, and maintainable software.

Tests as The Reinforcement Guarantee

If your code isn’t supported by tests, your code isn’t production-ready. I would say that for the majority of scenarios, you should have at least 1 test that guarantee the behavior of a given scope.

Recently, I read a great piece of blog posts from Matklad: How to Test, it brings some great material around how you could exactly test your software. And I believe that a strong software should be test oriented, in a perspective where you have the guarantee that, even if you inserted some specific new thing at your system, the feedback loop of the tests that you have will ensure that, if something have been break, it will be caught up.

Tests are the proof that the axioms of your systems, the rules and the guarantee that your system will be working on a specific way. They aren’t about what exactly users shouldn’t do, but it’s the guarantee that, based on what users really can do, you won’t have a breaking change.

Tests also let you move fast, with the security that if there is any breaking change, it will be easily caught by those ones.

In any other kind of engineering, you have tests, redundancy, and tools that provides safety through their work, like a civil engineer building a bridge. Tests, for software engineers, follow the same idea.

Migrations and Refactors as Engineers

As Linus said some time ago:


At the moment that your code goes to production, you have more concerns than just the usability of your code. How many people will be using it? How a breaking change will impact them if you inserted a new one? What are the implications? The second and third order effects of those changes? Can you think of the entire chain of consequences of this action?

You, as an engineer, should be carefully thoughtful about the decisions in your code. The implications of a specific change can impact a lot of customers in a harmful way that even you can’t imagine.

Backward compatibility is a term that I liked a lot. Being the guarantee of the interoperability of an older system (as said by Wikipedia), at the software side, it’s the guarantee that we will guarantee the same behavior of our APIs even for old clients.

Even for internal tooling or between shared modules across your codebase, you should carefully think in backward compatibility. You will always have a consumer of an API and, in that scenario, your API is the interface that have been exported by your functions and being consumed in other side of your codebase. The guarantee that it won’t break, or that will changed in every place, is a guarantee of less entropy through your entire codebase.


This is what I believe that are some specific part of a job of a software engineer, coding is one of the easier parts of the job. You have a lot more concerns to thought about your product, your code and other related aspect of the company.

And I believe that we should be more engineers and not just developers.