Becoming a better programmer: A Q&A with Anna Maier

Posted by Leo Kranenburg on December 20, 2016

It started with a two-week computer science course for girls when she was a teenager. Fast-forward fifteen years and Anna Maier is a successful developer who has been going strong for over 8 years at TOPdesk and who takes pride in solving the most complex of problems on a daily basis. We had the pleasure of asking her several questions about how she continually improves her programming skills – and how others can do the same.

Anna Maier

Anna, what sparked your interest in programming?

I’ve been interested in computer science for as long as I can remember, so when I saw a two-week course on the subject offered at a local university, I jumped at the opportunity. Unfortunately, it turned out to be very boring!

I didn’t want to give up on my dream of a career in programming, though, so I decided to combine computer science with linguistics, which also naturally appealed to me. I began learning all about how you can translate natural language into something that can be understood by a computer. Combining this with lots of programming really made things a lot more interesting.

And what has kept you interested in programming throughout the years?
I am absolutely addicted to troubleshooting. As a programmer, the problems you have to solve simply keep on coming! I’ve worked at TOPdesk for over 8 years now and I keep discovering new aspects of my profession almost on a daily basis. That makes it very easy for me to stay passionate about programming.

What do you hope to achieve as a programmer?
What I find interesting, is that the nature of my work implies that you are never done. What I mean is that although you can finish a project, the code itself is never finished. You can always find ways to improve it. If you want to be a good programmer, that’s something you have to embrace. That’s why my goal is always to create things that are well-designed and functional, and to improve them bit by bit.

What is your favorite programming language?
That’s Java, without a doubt! It’s a very robust language that still enables you to express yourself well. Unlike other languages, Scala for instance, Java also makes it easy to spot the cause of an error.

How do you master new techniques?
Like most developers, I’m always looking for new techniques or skills that can help me grow. When you try to master a new technique, I’ve found that it’s important to have a specific goal. With a concrete use case, it is much easier for me to learn something new. Whenever I find something that peaks my interest, the next step is to find a case that I can work on.

That’s why I love that at TOPdesk I can spend ten percent of my work hours on my own projects. These provide excellent opportunities to learn and experiment. A good example is the niko-niko board I made several years ago. This is a Japanese invention that shows scrum team members’ moods for each day. Everyone adds a smiley or an image onto the board at the end of a workday to illustrate how they felt that day.

What is the most important quality for any programmer?
Communication. You could be the best programmer in the world and know all there is to know about code, but if you can’t communicate properly, you’ll run into problems on a daily basis.

Being a good programmer doesn’t mean that you spend your days solely working behind a computer screen. You have to communicate and be able to give and receive feedback, to discuss and learn.

My advice is to always try to communicate in person as much as possible. Talk to people face to face rather than sending an email. With email, you don’t know what the recipient’s first response may be or whether they understand what you’re trying to say.

What message would you like to share with other programmers?
I would like to advise everyone to detach themselves from their work once in a while, and have a look around. Try to improve and find new things that interest you. Working in a scrum team, it’s easy to get carried away by the process and the focus on burning down story points, especially when the end of a sprint is in sight.

The danger there is that you can easily get stuck in a certain mindset. What I mean by this is that you may start to apply the same patterns over and over, for no other reason than that they have worked for you before, and not because they are the best solution for a specific problem. There might be a better, new solution waiting to be discovered.

In order to see this new solution, you have to take a step back and look at your problem from a broader perspective: who is affected by this problem, how will people use my solution, and can those people read my code??

I’m certain that there are a lot of people out there who know a lot more about code than I do. And of course knowing your language well helps. When you are programming with Java, you need to know how the language works and what you can do with it. This includes knowing about something standard like the collections framework. Make sure you learn as much as you can.

But writing code well takes more than just knowing your language You also have to keep asking yourself what is relevant and important for the project you are currently working on. Never unquestioningly apply something simply because it worked for you in the past or because it is trendy to solve it this way. Not all trendy patterns fit to all problems.

So how can you keep this open mind that is so important for a programmer?
That’s the easy part: just keep learning! It’s no use thinking that you know everything, because I can assure you, that is never the case. You will only lock yourself in, by finding one strategy that works for you and applying it to every problem you encounter. When it comes to programming, you won’t find the best solutions if you only ever take the easy way out!

 

Profile:

Anna Maier has worked as a developer at TOPdesk Germany for more than eight years. She is also the co-founder of the popular Java User Group Kaiserslautern, a community for Java developers located in and around Kaiserslautern.

About the author: Leo Kranenburg

More Posts