Speed in innovation and software development is increasingly becoming a decisive competitive factor for companies. So it's no surprise that software developers' roles are changing. What skills and knowledge do they need to be – and remain – successful?
To get to the bottom of this, I spoke to an expert who knows from many years of experience, Lars Brößler, Senior Software Developer at Endress+Hauser.
Karin: What changes have you noticed during your career?
Lars: In over 20 years of experience, I have been through it all. It started with very, very small projects, where you developed applications as a single developer with one programming language, a bit of SQL, and maybe some HTML knowledge. Back then, you didn't think about a version control system, about the hundreds of open source libraries that are in every application nowadays. And automation was not a thing back then. […]
Today, it's no longer enough to just focus on programming. Especially with all the automation, with the CI/CD (Continuous Integration/Continuous Delivery) mentality and with the awareness that agile development methods can have a huge impact, a lot has changed for the developer. Knowing how to code is no longer enough. […]
All the things you need to consider nowadays can be overwhelming. Code Quality and quick feedback from the customer, that was very rare in the past. When I think back to my first few years, I got a task: "Here are the requirements. And we'll meet again in three months." And after three months it came out that what I had programmed was not quite what the customer wanted. Today, I seek to get feedback as quickly as possible, which in turn means that I don't just develop, but also have to ask for feedback and be able to present what I'm developing.
So, more soft skills are needed than 15 years ago. You no longer work alone, but in small teams and in these teams you should make sure that everyone is on the same level. Of course, you always have your specialists for certain areas. But it's important to bounce ideas back and forth.
Everyone can contribute something to software development. Everyone has different ideas, and sometimes more experienced people don't even think about some of the points a more junior person brings to the table. Have you thought about that? Or how about doing it this way? And all of a sudden, completely new ideas and perspectives emerge. That's a huge change that has taken place over the last 10 or 15 years. It’s great, but it also has some challenges. You have to keep learning. […]
Karin: How can developers gain these skills and knowledge about new topics (like licensing and security)?
And what support are you getting from your company?
Lars: What we do in our company is that once a year we invite a coach to train the entire team on a certain topic. But that's just one part of it. For me, taking initiative myself and learning about new topics on my own is just natural. Of course, I partly do this in my free time, simply because I enjoy it. But it's also important that in your workplace you can set time aside for learning.
We are very fortunate that this is supported by our management and that we are given one day a month. To choose a topic that is new, that is urgent, and that could be relevant for us, and we get time to learn about it for a whole day.
Also, specifically for security, we are using "gamification." We have done security challenges where we have provided an application with security vulnerabilities and our developers were allowed to attack these applications. Of course, there was a scoring system and a little prize for the winner. It was a lot of fun.
In addition, several times a year we have two consecutive days specifically dedicated to security issues. We have lots of old applications that are no longer in the current development phase. But of course, software is aging, libraries are getting new vulnerabilities or there are still old vulnerabilities in them. So we defined something like "back-hunting"-days when we look for vulnerabilities in the old applications and solve them. […]
Apart from that, another big thing for us are conferences. They really help to get an overview of what new trends are currently in the market. If I come across exciting topics at a conference, I will then present them to all our developers to allow for a transfer of know-how.
Lastly, online training, even self-paced training, has also become more popular lately. This is very, very helpful for me as a software developer, because it allows me to have my own pace. I can tackle these training sessions when I have time and feel like it. […] If there are even code examples and maybe a little competition, it's fun. And you become competitive when you see a colleague suddenly getting 10 points more somewhere. Then you try again and do better and better. This gamification offers incredible incentives and it's also fun. And that's the direction we're trying to go in.
Every day something new comes up that you have to learn about. You just need to have fun with it. It's very much a matter of attitude. In the past, it was enough to be an expert in one area. Today, that's no longer enough. I have to learn about new topics every day. Whether it's security or open source license compliance or whether it's simply colleagues from other cultures who think differently. […]
Karin: You just mentioned some of the soft skills, like initiative, curiosity, the joy of learning something new. What else is needed?
Lars: Communication is also very important. As a developer, I am no longer a lone fighter, I am part of a team. I have to be able to work in a team, coordinate with colleagues, and ask for help. So I need an openness and a culture of constructive criticism. In the past, this was simply not necessary, because I just hid away coding in my little room. That doesn't work today because applications have become far too complex for one person to manage.
So I have to be able to communicate. Not only with colleagues, also with the business.
Sometimes you have to question the requirements. Is this really what the client wants? Or is it just what they used to have before? Here, too, you need a good instinct to get the important information. Because the client can't write everything down or consider everything, and a developer in particular thinks completely differently. That requires good communication. […]
Time management has also become very important. That was never an issue for me before. I just sat down at eight in the morning and stopped coding at five in the evening. Today I have appointments, a security meeting here, and writing guidelines there. You can't do all that if you don't have good time management and learn to say no. That's important for the project, that it's important for a client, but also very, very important for you personally, because otherwise you wear yourself out.
Karin: How are you navigating the field of tension between the demands placed on a developer and the costs for the company?
Lars: I don't think there's a general solution. Some companies have the luxury to develop an application with a strict approach like "we have that much time and that much budget. And we'll just create as many functionalities as possible." But we rarely find ourselves in this situation. That's when and why the developer needs business sense.
A developer has to work efficiently. Every developer I know is like a child that loves to play. We like to try out the new fancy tools and try to build another gold edge here and another gold edge there. That's great. It's fun, but at some point the project manager will say to me "Lars! The budget is almost used up, but you haven't developed the core functionalities yet." Again, communication is key.
Information must flow from the business down to development and from development up to the business. You have to communicate if you face problems that make the process take longer. And the business has to communicate when there is time pressure or the budget is getting tight. We have to pass on this information as early as possible. This gives us the chance to intervene and steer things in the right direction.
Karin: Speed is also gaining importance today. If there is a new zero-day vulnerability coming out. How quickly do you know which applications you have it in? How has that changed compared to the past?
Lars: In the past, no one cared. People didn't find out about it at all, because there was simply no focus on security vulnerabilities. If I was lucky, there was a colleague who found out about it somewhere or I discovered it in the application I was currently developing and then forgot about it again. But for the other 600 applications that we had running, I never found out because I might not even have known that we had this vulnerability in there.
This has now changed. It's still not perfect, but with the automation of our CI pipeline, we scan at every check-in, and also applications that are in production. I get information that new vulnerabilities have been found in old applications and then I get a corresponding email with those issues.
In the beginning, we looked specifically at a tool that allowed me to check for every open source library what vulnerabilities it contained. So I decided to check [one of our] applications and see what vulnerabilities we had in it.
In the POM (Project Object Model), where all the dependencies were configured, I manually checked each dependency. But there were over 120 dependencies in this application, [all of] which I had to check manually. After 20 dependencies and well over 2 hours of work, I said "No, I can’t do this anymore."
That's what led us to automation.
We needed a tool to find vulnerabilities easily, allowing us to focus our energy on understanding what the vulnerabilities are and fixing them. Finding them manually is inefficient, and the developer gets tired of it very, very quickly. It just doesn't work.
So there's definitely a need for automation. It's quick and I can get automated information about applications that I'm not currently scanning, but that are in production. This is the only way I can guarantee a reaction time of a few days.
A few years ago you had weeks to find a vulnerability after it became known. Until it actually got exploited by attackers, weeks went by. Today you only have a few days…if at all. […]
Karin: We have talked a lot about the past and current changes and challenges. How do you think the role of the developer will continue to change in the future?
Lars: Automation definitely is an important point. More and more is being automated.
It starts with the fact that we are automating the creation of databases in production. That we're automating monitoring and alerting much more. We need much higher speed, in terms of time for development or time from requirements to production, and we can only achieve this by automating things.
It's crazy to think that we used to spend a day or two just building a release. It was just a waste of time. That was because we didn't do it often enough. But if I do it 20 times a day, it works within a few minutes at the push of a button. That's huge.
Containerization is another big topic. We may not be at the forefront of this in the company, but more and more we need to think about how we deliver software, how we deliver patches, how we deploy our software internally in our data center. Docker containers are a great thing. I can start it at the push of a button. There's still a lot of potential there.
In development itself, of course, this means I need a broader spectrum, so DevOps has been a topic for us for a long time, DevSecOps is increasingly on the rise. That means that security aspects are also taken over by the developers, not just by the operations team. Another big thing that's on the rise is the involvement of the developer in the business, so that he understands what the business wants. […]
CREDITS