Written by:

Aran Vink

What if you were a software engineer at Itility?

-->

The conscience
As a software engineer, I obviously work a lot with software. But at the core, I still am an engineer. This is not just an academic title – as an engineer, you are the technical conscience of an organization. When designing a software system, it is important to also take non-technical considerations into account, such as ethical aspects, regulations, privacy, information security, and societal matters regarding software.

"Being a software engineer requires very strong consultancy skills."

The art of creating
For the largest part of my time within a project, I work on optimizing the delivery process of software – called Continuous Integration and Continuous Delivery (CI/CD). This unites processes, architecture, organization, and technology. CI/CD is all about automation and processes – think: software pipelines, release automation, and version control. It is an ever-changing field, so besides broad knowledge of common tools, you should not be afraid to try and experiment with new tooling regularly. As a generalist, I discover underlying patterns and get acquainted easily with the tools I have at hand. This way, I combine new tools with known patterns when setting up the software delivery chain.

Scaling a software project

Cool as a consultant

Does this mean that you mainly work on your computer being a software engineer? No, it does not. Besides connecting applications into systems, my work involves connecting with various kinds of people. This ranges from IT architects to application developers, software testers, site reliability engineers and sometimes even lawyers. The key to obtaining a good result is having very strong consultancy skills. Especially when joining a project halfway, because you often end up rebuilding existing systems while the team of developers continues to work in the meantime.

To the rescue!

You probably noticed; I prefer joining projects from the start. This means I can quickly respond to choices that are made which affect the essential properties of the system. More commonly I join a project halfway, which makes sense: Innovations in the world of software are often started out of frustration. A developer starts writing code on a Friday afternoon to solve a pressing practical problem. The project slowly evolves into a prototype. Only after someone finds a business case, budget will be made available. This limited budget is used for developing functionality, without thinking too much about the way the software will run once in production. Only when that realization comes, the software engineer appears on the stage.

Our value in real life

So far, I talked about the skills that a software engineer needs to have. How are these skills applied in real life? I selected three cases which clearly show the role and value of the software engineer.

Full-stack development with the end user in mind
With one of our customers, we developed – from the very first line of code – a web application for the technical administration of hybrid cloud environments. What we did as software engineers:

Design interfaces between front end, back end, and external components.
Integrate all components into a production ready system for end users.
Safeguard non-functional aspects such as IT security and quality.

The added value:
Broad knowledge of technology and IT infrastructure was invaluable here, as it was our role to connect IT specialists with software developers. Despite the technical complexity, we continuously focused on our end users. And we didn’t go home until we were satisfied with the quality of the (final) product.

“Despite technical complexity, we continuously focus on our end user.”

Automated provisioning of VMs
A large customer uses a system that automatically provisions new VMs. This used to be a manual – thus very time consuming – process. Our role in this project:

Collect functional and technical requirements.
Find a feasible solution and described it in a design (both high and low level).
Implement, maintain, and extend the solution.

The added value:
With our ‘systems’ mindset we set out to fit our new solution into the existing software and IT landscape. This enabled the project to quickly deliver results. Afterwards the engineer seamlessly guided the project to the maintenance phase.

Streetwise API
TNO is developing a database that stores data of self-driving cars that are made available to customers through a web API. The dream: a single database from which all manufacturers of self-driving cars can learn and to which they can contribute. The role of the software engineer was crucial here, too:

Advice on choices regarding technology, from infrastructure to database structure, selection of the right cloud components, software architecture, programming language, and application framework.
Implement solutions within a short time frame.
Guide the transition from development phase to maintenance phase.

The added value:
Thanks to the consultancy skills of our software engineers, we gained insights into the requirements – step by step. To meet the customers’ requirements, we had to meet the requirements of our customers’ customers. By writing a clear design, TNO gained continuous insights into what needs to be provided. Because our software developers are experienced in development on cloud infrastructure, we managed to implement the API within a short amount of time as well.

Software engineer vs software developer?

As you can see, the work of a software engineer at Itility is quite different from that of a software developer. You continuously evaluate new tools, you collaborate with many different people, and you mainly work at the system level. Do you recognize this within your organization?

Software engineers: Google Trends shows we search for them increasingly. And the number of software engineers joining Itility each year increases too. But what is it you do in this role? And what is the difference between a software engineer and a software developer? Based on my experiences at Itility, I will explain the differences.

Stereotypes

Even software professionals sometimes struggle with the distinction. Some businesses alternate both terms in vacancies and job descriptions, other businesses do make a clear distinction between the roles. In the table below, I outline my experience – using stereotypes to explain the differences.

	Developer	Engineer
Looks at software as:	Product	System
Mainly contributes to:	Functionality	Architecture
Is involved in:	Development phase	Entire lifecycle
Programming languages:	Using a language	Choosing a language

"I think about the ‘end of life’ phase of a product before it is taken into production."

Of course, a developer will sometimes do things that are concerned with the system. And of course, an engineer will occasionally dive into the code as well. So why make the distinction? Because the software developer mainly works on single applications, while software engineers crunch their brains on system domains. Both tasks require specific knowledge and a specific skillset. For software engineers, this is what it entails:

Helicopter view
One thing is for sure – during my projects at Itility, the software I work with is highly complex. Too complex to know every detail. My main task is to make sure all subsystems work well together, and, eventually, run smoothly in production. This requires a bird’s-eye view across the boundaries of the different phases of a project. I think about the ‘end of life’ phase of a product before it is taken into production. Why is this important? Well, one day the product will be replaced with something better. Choices made during development have a huge influence on the amount of work that will be needed to replace it. I help customers make the right choices in that.