Software engineering

Software Engineering is a branch of computer science and information technology dedicated to studying the complete life cycle of software.

Below, you’ll find a selection of technical articles related to software engineering. I invite you to explore them, you might find something that piques your interest.

IT? Software developer? Software Engineer?

If you are a colleague by profession, I don’t know if it will have happened to you like it did to me. Many times when I have to say what I do for a living, I don’t know what to say… Software Engineer, Computer Scientist, Software Developer…

Many times depending on who is asking me, I end up saying one thing or another. Can you imagine telling your grandfather that you are a Software Engineer? I don’t know, to me at least, it seems strange to me! 😅

I suppose it may have happened to you that when you answered with a ‘well, I’m a computer scientist’, an image like this has automatically appeared in your head.

And… no folks, computer scientists do NOT fix stuck printers, and we do NOT fix computers or electronic gadgets that won’t turn on. At least not most computer scientists.

But let’s get to the point, since you’ve come here to learn (I guess).

What is software engineering?

Software engineering is a discipline made up of a set of methodologies, tools and techniques used in the development of computer programs, also known as software.

Software generation is an intrinsically creative process.

Software engineering tries to systematize this process to try to reduce the risk of failure.

To do this, it seeks the application of methodologies, tools and systems, in the most efficient way possible, to achieve optimal results.

You have to be able not only to solve the problem, but to do it in the most appropriate way.

Software Engineering Phases

Software engineering is present from start to finish in the process of creating software.

Let’s see what are the main phases in this process.

  • Analysis of requirements.

This phase largely depends not only on the scope of the final product, but also whether or not it is successful.

There are many memes about this that I thought would be interesting to include, because as the saying goes, a picture is worth a thousand words.

Requirements analysis

In order for this not to happen, it is necessary to go through a clear, well-defined requirements phase that is understood by both the client and the software engineer.

  • Design and architecture.

Once the requirements are known, you can begin to determine the different use cases, to cover the different functionalities that the system must carry out.

In this phase, the different software implementation options will be studied, and its structure will be decided.

It is another crucial phase, as well as complex. Therefore, it is not something that is done only once, but rather iteratively, refining the solution as it is designed.

To facilitate the success of this phase, you can rely on the catalog of existing design patterns, where the experiences in other designs are collected, to avoid falling into the same mistakes again.

  • Developing.

Preferred phase of a high percentage of the computer industry.

At this point it will decide which programming language will be used to carry out the implementation of the solution.

Once this decision is made, the implementation proceeds. Always keeping in mind the good development practices, to try to avoid, from the very beginning, that the code becomes indecipherable and unmaintainable.

Without a doubt, a must for anyone who is interested in developing quality code is the book Clean Code, by Robert C. Martin.

  • Tests.

The great forgotten… although it is true that less and less. If you are a colleague by profession, how many times have you not come across the typical question of ‘But is that estimate with or without evidence?’

Nowadays software is not conceived without its tests. QA (Quality Assurance) has been on the rise for some time now and there are more and better tools that developers can use to guarantee code quality.

There are many types of tests, but perhaps the closest to the developer are unit tests, where each unit of implemented code is verified to work independently as expected.

As I mentioned before, today it is difficult not to find divided teams, where the developers implement, and the independent QA team is dedicated to developing the system tests to guarantee its quality.

  • Documentation.

This is another of the phases that always creates debate and that, in fact, with the appearance of the Agile methodologies have perhaps been further modified.

I like to see it as the phase that allows you to make the software known to anyone with sufficient technical capacity.

Imagine a shareable link that you could use to ensure that anyone delving into it has a proper understanding of the software.

That is the goal of this phase. So easy to say, so tremendously difficult to achieve.

In addition to being one of the phases that software creators generally like the least, and that directly affects the results in it being, again in general, mediocre.

People on development teams come and go, and software continually evolves. It is essential to have good product documentation, not only for what has been mentioned above, but also to save time, and therefore costs, because if we have that ‘magic’ link we will be avoiding a lot of time in knowledge transmission that would be done through other ways.

  • Maintenance.

Software is a living entity that normally evolves as time passes and with it needs. In this maintenance phase is where this evolution comes in to improve existing functionalities and respond to new requirements.

In addition, we also have corrective maintenance, which is perhaps the best known. The one who is in charge of fixing any functionality failure once the software is already in production.

Software engineer cycle

Software engineering goals

The objectives are always something perhaps too variable, at least if they are sought at a low level. At a high level everything can be summed up perhaps with ‘the product must be of quality’. But… how to get there? What other more specific objectives can lead us to that?

There is no solution to any problem posed. But it is possible to determine if one solution is better than another, or at least the pros and cons of each one.

Good practices and standards must always be kept in mind in order to apply them, seeking to get closer to that most efficient and empirically best solution.

Let me list below what are the main objectives that a software engineer should always keep in mind.

User satisfaction

After all, the software that is being developed has the objective of satisfying the needs of its end user.

This focus must never be lost, always being focused on understanding the purpose of what is being done.

Understanding the requirements is a tremendously fundamental and necessary piece before starting to develop for development.


You should always look for the product to be prepared for all possible scenarios. Not only those where everything behaves as expected, but also those where certain pieces may not work.

Reliability in software engineer

In any of these cases, the software must be prepared not to respond unexpectedly.

Furthermore, and also related to the above, you should always keep the goal of zero bugs in mind.

For this, it makes a lot of sense to focus on quality (QA) and to have a collection of tests that automatically guarantee that the product has no problems.


It is useless to have the best software in the world if we have gone bankrupt along the way and the income it produces does not exceed the costs. Fundamental law of any business; maximize profits.

In software engineering there are no exceptions.

We must look for the best solution, with appropriate costs.

Generally, the highest costs are usually those of maintenance. So one of the main objectives should be that the code is readable, easily understandable and flexible to changes, so that when the time comes to have to correct bugs, you don’t have to throw away the house and start from scratch. the beginning.

Continuously generate value

It is essential that the client sees evolution in his product.

Constantly adding value

Agile methodologies make it easy to achieve this goal, seeking to increase the value of the product every 2-3 weeks, in what is called a development sprint.

In most cases the product evolves as it is seen to grow. My experience tells me that it is very difficult to find such perfectly defined requirements that it is known from the outset how the product should end.

Generally, there is an idea, more or less clear, with more or less specific objectives, but as these are fulfilled and the software sees the light, it tends to pivot, changing things or even generating new objectives.

This is why it is essential that we do not hide in a cave to do what was signed in the requirements gathering phase without talking to our client or end user. We must have contact and as it evolves, always present the improvements and functionalities to the client to ensure that it goes down the line adequate.


This objective is also closely linked to that of costs.

As a general rule, efficient and high-performance software usually needs fewer resources such as CPU or memory usage, and that ultimately translates into lower costs and therefore more benefits.

And beyond benefits, many businesses simply need to respond in a short period of time, so on certain occasions it could be said that a certain and demanding performance is a fundamental requirement.


We must always, always, always keep this goal in mind and written on fire. Solving a problem generically by generating a unit of code that can be reused in many other places in the future saves effort and money.

Said like this it seems simple, but it is actually very difficult to carry out properly, especially in large software with large independent teams.


Never forget about your team. A good software engineer is one who doesn’t just care about his plot, pressing the best keys on his keyboard to generate the best code.

I would go so far as to say that no major software today is one-person. And that is why knowing how to work as a team is a point that I consider a fundamental pillar.

Transmit the objectives both at a high and low level, making sure that they have been well understood, communicate with the team to make them part of the strategy to follow in the short-medium term to meet the objectives and carry out an organized tracking of the work On a day-to-day basis, these are three of the points that I consider most important.

What does a software engineer do?

A software engineer in his day to day faces a variety of challenges, and the tasks may vary depending on the nature of the problems to be solved.

Software engineer tasks

Among those tasks you can find:

  • Modify existing software.
  • Build new software from scratch.
  • Analyze and design complete software systems.
  • Plan the software build process from start to finish.
  • Document flows to show what happens in a given software system.
  • Work in a team with other software developers, designers… etc, to reach common solutions.
  • Take care of factors such as security, cost and delivery times in the design and development process.
  • Facilitate team training with courses and/or documentation .

Software engineer career guidance

Surely there are more possible routes than the ones listed below, but these are the ones that I think are interesting to comment on.

  • Freelance contributor

Freelancers focus on deepening their knowledge throughout their careers, sometimes across multiple subject areas. They often value being creators and taking on more practical in projects. It is a role that requires leadership as they are trusted to champion and guide teams as well as setting a good example of work ethic and execution.

  • Team Leader or Manager.

This is more the way of traditional management perhaps. For this role, social and organizational skills are required to a greater extent.

You need to know how to build and lead successful teams, constantly maintaining motivation, delegating and assigning complex tasks.

Visibility is required within the organization, both internally in terms of collaboration and management of the parties involved, and externally in terms of representing the company to current and potential customers.

  • Freelancer

When you want to fly alone, you usually end up doing it.

Either from the beginning, or when certain experience and skills have already been accumulated.

If you are motivated and enjoy working in a variety of projects, this type of pathway can offer greater flexibility in hours of work and level of contribution.

  • Startup Engineer

Setting up a startup is also another possible way to explore.

Of course, if you decide to go this route, you will not only have the engineering job as such, but also the commercial, management and administration part that a company needs.

Of course, an interesting challenge for those who are motivated enough.

The skills or abilities needed will vary depending on the path chosen.

Software engineer skills