Software Engineering vs Software Programming

Are we “Software Engineers” or “Software Programmers”?. Are we using both as if they were the same?. If we look at “the first” chapter in the book “Software Engineering at Google”, and see that they dedicate a whole chapter for that, we can assume they are not the same. It’s a chapter worth reading and gets all the details they expose. Today I want to show you my vision through a little description and a real example of each one.

Software Programmer

Photo by Florian Olivo on Unsplash

Programming is how we generate more software, so a software programmer is just a person who is able to create software, just that, a piece of code that does something.

Also, programming is a part of Software Engineering.

Software Engineer

Photo by Christina @ wocintechchat.com on Unsplash

A software engineer is a person who has to take care of much more than just create software. Software Engineering has to think about:

• time: how long is the solution for. Is it a short term solution?, is it for a long time?, maybe we don’t know…
• scale: how big could it become?
• trade-offs: benefits and problems for each solution

Now I want to expose some real examples of my daily work that could fit in each of those categories (engineering and programming).

The programming case

A corner case was detected and some element statuses weren’t updated correctly. After reviewing the code and understanding the problem a fix was made.

Now we need to fix those statuses that remain with incorrect values. Create a little program that:

• Found the incorrect elements
• Look for the correct value
• Update the status in each incorrect element

We just need to create a piece of software that executes those instructions and define how to run it.

That is, there is no need for thinking of other things but the correct instructions to solve a concrete problem.

The engineering case

We need to help our users to go through the most complex step in our contracting process, it’s a key process and it’s dependent on external services and it may fail some time. When it fails, it makes the process slower for our users and gives more work to our support team.

We evaluated several options:

• Option one: add additional steps for the client in the process to help them run a alternative process
• Option two: create a scheduled task to run a process that caches information to be used during the process

First thing we took into consideration: the effort for each solution.

• Option one would require backend work along with apps (IOS and Android) work. The process to be implement it’s quite complex and has several new steps and changes. Anyone who works with native apps knows about the releasing process for each platform and the problem when a new bug is discovered. So being a complex process and a business problem not well known by native apps, it could lead us to a higher time to release, a possible bug, to be a bad solution and need to remove it from the process, etc… . A remembering: a native app when it’s released, it’s done, it’s not up to you to ensure the user has the latest version (at least in a simple way).
• Option two requires only work for the backend team, it reduces the process complexity avoiding synchronization between teams, only the team with business problem knowledge is involved, a possible bug could be solved with no user interaction (only updating the backend). At the same time, this solution could not work for some users. But, here, it’s where incremental changes comes to play and other task would be planed to solve this cases (also reducing the changes and reusing already existing features)

Once we have a winner option, it was time for us to think about the process and design the process taking care of the different details:

• The amount of data to be processed: use the correct concurrency, algorithms, data structures and design patterns.
• The availability of the external services: call concurrency, timeframes for executing the task.
• Task abstraction, configuration possibilities: do the process agnostic and allow configure the task to responses the needs.
• Task results: write logs, create monitoring and dashboard, save result data for historification process and be able to analyze results.

As you may notice, I used the word “we” for the actions in this example, and that, the “we”, is one of the most important differences between programming and engineering. Engineering is a team work!

So as we can see, the “engineering” process requires program software but it’s just one step of the process. There is much more in the process and most of the time we should try to be “Software Engineers” and be “Software Programmers” when it’s required (when we are just writing a simple code).

What can we do to be better at each one?

Software Programmer

• Master your principal programming language and learn others.
• Master your editor, key bindings, debugging tools,… .
• Improve in data structures and algorithms.
• Learn most used structural and behavioral patterns.
• Improve your testing skills.

Software Engineer

• Improve communications skills (listening, writing, speaking).
• Learn architectural patterns.
• Increase your abstraction capacity.
• Learn about systems design.

Those are some of my examples and recommendations, and I hope this helps someone. I you like it, follow me on Medium for other articles!.

Do you have any other definitions or examples for these two concepts?