“Whenever I see a button, I want to push it and see what happens,” says Brecht Yperman, senior software developer at TrustBuilder. From his teens, he had a keen interest in technology, and he is still very passionate about what it can achieve.
How do you decide what to develop first for our customers?
Brecht: At TrustBuilder, we work in an agile way, with fortnightly sprint meetings which are very interactive and collaborative. On a higher level, product management and product owner set the priorities on what new features need to complete our product. In our sprint planning meetings, we look at what is most important, how long it takes to develop, etc. We define the priorities as story points, see how many issues we can tackle in one sprint, and that’s how we plan the next two weeks, using Jira to track our progress.
The order in which we tackle the points is related to the priorities. Usually we tackle the bugs first, and then move on to new features or improvements. As a developer, I have the freedom to decide in which order I work through my list. Sometimes I put something on hold in order to finish some low-hanging fruit first. That gives a bit of variation in my day. Beside the sprint meetings, we also have a daily stand-up meeting around noon. That’s where we see what we still need to do to reach the goals of the sprint.
The developer as a sculptor
What does a developer do exactly?
Brecht: Programming is not just constantly writing lines of code. Since we are a small company, we have a variety of tasks. We are told what functionality is needed, but we have some freedom in deciding how we will deliver that functionality. As a back-end developer, we can think about REST API design, database design and everything in between.
Every developer has his own style. You can compare it to a sculptor carving a statue. Some will spend a lot of time beforehand, thinking about what statue they want to chisel out of a block of marble, and only start when they have the exact vision of what steps they are going to take to get there. In comparison, I like to sculpt with clay, get going immediately, build something and go back a couple of times and then get to the final result. That’s a more organic approach. We get that freedom to develop our own way of working, but within boundaries.
With different styles, can you work well together with your co-developers?
Brecht: There are a number of standards we adhere to of course, and we enforce those standards, using tools (Sonar) and code review. But we do have the possibility of using our own style. On the other hand, being a small team, working together closely, we converge around the same goals. Jokingly, we sometimes say that our periods are syncing. A developer doesn’t work on an island. As soon as I have built something, at least one colleague will revise it. You learn a great deal from the revisions a colleague makes. To indicate the importance of something, we use the ‘Moscow’ principle of ‘must-should-could-would’. Peer review is very important, but that is more about style than about functionality.
You are a back-end developer. What is the difference in the way of working between a front-end and a back-end developer?
Brecht: There should be no difference. The specific difference at TrustBuilder is that our front-end guys work in Angular, with JavaScript, while we use Java on the server side. And, of course, they deal with CSS and HTML, to make the user interface look like Marketing wants it to look. But, in the end, the way of working is the same for back-end and front-end developers. Specs are defined, there is peer review, there is automated testing, etc.
What are your favorite tools?
Brecht: Eight years ago, I started using IntelliJ IDEA, and since then I have not looked back at Eclipse or NetBeans. So, IntelliJ IDEA is the tool I use most. GIT as a version control system is also a great tool. In my first job, I moved from not having any version control at all, to CVS with exclusive locking, to Subversion and then GIT. On an organizational level, Jira is an important tool, greatly reducing the number of emails I receive. All our communication goes through Slack when it’s urgent, or Jira if you need more follow-up. Jira has really replaced email as a collaboration tool for developers. In my opinion, Jira could replace email in other domains as well, on the condition that you can divide the work into issues.
Metrics for developers
When are you satisfied with what you’ve achieved in a day?
Brecht: That’s difficult to say. It can vary from day to day. Sometimes we have to help a consultant with an urgent issue, or we help the other developers. That can be a day well spent. I don’t believe in ‘lines of code’ as a metric. That’s a stupid metric. Sometimes just a few lines of code per day can be an achievement. And sometimes you are productive by deleting more lines of code than by writing new ones. Gaining an insight in how to do things better, can be productive and satisfying too.
How irritating are testers to a developer?
Brecht: Very irritating! Just kidding, we work very well together with our test team. When we change our ticket in Jira from ‘in progress’ to ‘done’, we write instructions on how to test and what to test. If we fill this out correctly and completely, the relationship between developer and tester works well. But, of course, a tester should not restrict himself to what I request. By going beyond that, the tester can detect more flaws.
How valuable is input from customers to your work?
Brecht: I don’t have direct contact with customers. My contact with the people who are using my output is limited to project partners like SecureIT in the Netherlands, and, of course, our own IT consultants, who do the implementation at our customers. That is really important. As a developer you need to know what a product does and how it functions at the clients’ end. You cannot do something well if you don’t get the full picture. Getting use cases from real life can deliver great insights to a developer. If I have to develop a feature, it works best for me if I know what value that feature brings to the customer. That also helps in working with DevOps in making the products as easy as possible to implement.
Collaborative culture and team spirit
What do you value in a company like TrustBuilder?
Brecht: I attach a great deal of importance to team spirit. At TrustBuilder we have a vibrant culture of collaboration, talking to each other, having a drink after work. That was my motivation to join the HR working group when they asked me. In a small company, you can have a real impact. We may have become a well-organized company, but we still retain a very open culture. I like that.
Are you interested in working at TrustBuilder? Check out our vacancies.
