Few people possess the knowledge that TOPdesk’s senior developer Roel Spilker has about Java. Not only is he actively working with this programming language since 1999, he is also co-inventor and creator of Lombok. This is a game-changing tool that enables tens of thousands Java programmers on a daily basis to code quicker and prevents them from making mistakes. “In many cases I wonder how to improve the code.” But how does he do it? And what can other developers learn from this in order to keep improving their developer skills?
When did you start programming?
I am interested in computers and electronics since childhood. When I was ten, my cousin got a commodore 64 and I started creating and programming simple games. From text adventures to taking down space ships. Together with a friend from school I also created games for the ZX spectrum.
How did you turn your hobby into your work?
After high school I studied Computer Science for two years and switched to Mechanical Engineering for another two years. There were several reasons why this didn’t fit into what I wanted to do.
Through a friend I started working as programmer for a company in The Hague. Unfortunately, this company went bankrupt in 1997. After that, I worked at different places through a temping agency , but this was never longer than three weeks — at my own request I must say. This way, I was able to experiences a lot of things such as working at a butcher, as an air freshener repairman and for an export company that did business with the United Arab Emirates.
After this I started working as a petrol station attendant. Here I got to talking with a customer who was a software developer. He pointed me to some companies that were looking for programmers. This is how I ended up at OGD in May 1997 as software developer for the program Lift. Two years later I was a full-time developer working on TOPdesk 3.
Which software developers are your biggest inspiration?
I am very interested in the work of Joshua Bloch and Brian Goetz. Not only for the tons of work they have put in the Java platform, but also for their contribution to the way you create code. They both continuously think of how to improve the field of expertise, what the next step is, where the gaps are and which mistakes need to be corrected.
Do you use their message in your own work as well?
At TOPdesk we’re always working on improving the field of expertise. A good and recent example of this is Continuous Deployment. Instead of having a release twice a year, we have many smaller ones. This isn’t an improvement of our code, but of our entire way of working.
I also ask myself what can be improved. Many programmers know the mantra ‘prefer composition over inheritance’. But how to do this is a different question for developers. This question doesn’t have a simple and one-sided answer, but I would like to show you how to do it.
How do you share your knowledge with other developers?
I mostly do this via code reviews. I don’t just look if the code looks good, I also search for improvements and answer the question on how to come to a better solution. It’s mostly about how you work on the code: what do you see in it, how do you recognize code smells and how do you rewrite it to make it better?
What is the most effective way for a programmer to gain more knowledge?
I talk to colleagues and other programmers about new techniques, ask what they read and tell them about my discoveries. Conferences and contact with former colleagues are important sources to me, as well as news groups, mailing lists and tech sites.
However, the most important source of information is the network that I’ve built up over the years. This network includes people who message things because they think it is interesting for me. I would advise everyone to actively share information.
What advice would you like to give other programmers when it comes to improving yourself?
There are three things I would like to convey to fellow programmers. First and foremost: the best code is often no code at all. Many programmers instinctively react to a request with the thought, “I can program this, no problem”. But by talking to a stakeholder and discussing the underlying problem, you often reach a different and easier solution.
One example of this: one of our testers found a mistake that was triggered by pressing a button. I discovered that this mistake was in TOPdesk for almost a year and that none of our customers had reported it. The best solution was to remove the button, which leads to fewer code. I want to encourage developers to not program when there is an easier solution at hand.
My second advice is to see if you can replace things that hardly no one uses by something better. Especially in the product you’re working on. Is there a feature that one customer uses? Remove it and offer an alternative to this customer. This is always better than having to maintain this code for years and years.
And number three: don’t forget to clean up bits of your software. When you’re replacing an existing framework it sometimes seems like a waste to rewrite other code in order to use a new framework. But the consequence is that you’re stuck with two different frameworks you need to maintain and understand. This approach slows you down in the long run, just like the feature that is hardly used.
This probably isn’t one of the most interesting things to do as a developer…
I understand that people like to do new things and that rewriting old code isn’t the most interesting work to say the least. However, just the fact that you don’t have to drag along the old code makes it that cleaning it up has business value. And if you can’t see the value of adjusting the old code, you have to wonder if it isn’t better to remove it entirely. It seems that the code is not used by many customers, because if it was there would be more priority for the module in which the code is located.
What do you believe to be the most important characteristic for becoming a better developer?
If you want to become a better developer, you need to have a real interest in how everything works above all else. Read documentation and code and see if they correspond. Look at other people’s code and think about it. Not only code from your TOPdesk colleagues, but also from different Java standard libraries. Think about how they were constructed. This might not be correct in all cases, but you can still learn from it.
Always try to push your boundaries by doing things you’re actually not ready for. One exception to this advice concerns multithreading. It’s simply too easy to make mistakes in this. So, I would advise you to, if possible, stay away from it.