40 An Interview with Danny Preussler

Danny is a mobile developer by heart. He lives and works in Berlin, the city he loves as much as Android. Danny signed the Software Craftsmanship manifesto as a strong believer in the value of life long learning. He dreams in clean code and could speak about unit testing all night. That’s also his favorite topic when speaking or writing about Android. Danny was in charge Android for eBay’s classifieds business in Germany before moving to Groupon to build a team there bringing mobile to life for merchants. Even before Android came along he programmed for mobile phones and every device that could run some kind of Java. Currently he is using his learnings about media streaming at Viacom for the music app SoundCloud. His first computer was a Robotron KC87 and he still loves technology. In fact so much he has a magnet and an NFC implant.

Danny Preussler

Connect with Danny

Twitter: @PreusslerBerlin GitHub: github.com/dpreussler Medium: @dpreussler LinkedIn: /in/danny-preussler-557a3b79

Interview

You’ve been advocating for better testing in Test-Driven Development, or TDD. How would you define “better” testing?

I’ve been looking into testing for quite some time now. I actually gave my first public presentation to a tech audience about ten years ago at a Blackberry developers conference. Even back then, I was focused on Unit Testing. I’ve learned a lot since then.

I see developers caring more about testing nowadays, which is something I really like. Especially with Android, testing wasn’t a priority in the early days. Now, developers have testing in mind, but it’s still not as important as it should be. When corners are cut, testing is the first thing that is skipped. But skipping testing is a bad practice.

We all look to heroes like Kent Beck, Martin Fowler, and Uncle Bob, who’ve contributed a lot of great quotes about testing. Martin Fowler said something to the effect of, “Refactoring without testing is like changing shit.” I couldn’t agree more.

You might think you can write high-quality code without testing, but once the software is out, and probably even before, things will break. This is where I believe testing is beneficial.

Tests are about so much more than testing functionality. They are documentation. They are something that the next developer can utilize. Testing is the one thing that enables effective code.

You know, I tried a lot of things in testing but, at some point, I felt there was something missing and something is still wrong. My tests were still flaky. Doing TDD solved these problems for me. In other words, I found the best way to do testing—for myself.

It sounds like you think the best way to approach testing is on an individualized basis. Is there anything developers often underestimate when we are developing our tests?

In terms of quality, I think we are not putting enough effort into the tests themselves. We learn all these rules, like not to repeat ourselves, right? Often, developers ignore this when it comes to testing. But tests should be as clean as production code. The same rules apply! Make your tests easy to change! If you change functionality, the changes in your tests should be small, as well. But very often, the reality is duplication everywhere. It’s at that point when people start to hate testing. However, the real problem may be that the developers didn’t apply the same principles to testing that they applied to their code.

That’s an interesting perspective. I’d like to know more about how you’ve developed your point of view. What are some books that have had a lasting impact on how you do work?

There are several books that have made a significant impact on me. The first is Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14 by Scott Meyers. I started my career as a C++ developer, and this book kick-started everything for me. It’s still the best-written and most engaging IT book I’ve ever read.

Then there is Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin; it changed the way I program. It’s the one book I recommend to every single developer out there.

Finally, one called Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems by Steve Krug. It’s about how all of us can easily set up user-testing. Having a big UX lab isn’t necessary. Most usability bugs you find by just giving your software to someone to try. You could even take a competitor’s app or website, the perfect prototype for what you probably want to build. Test those with your users. These are some examples from the book.

I’m sure we’ve all been impacted by resources that have become standards in the field, even if we haven’t encountered those resources directly. What about your direct experience? What have you invested in, whether that investment was material, immaterial, or an investment of time, that has provided you the highest investment in terms of revenue your career?

I could mention Clean Code again, as I spent just a few euros on the book and it made a huge impact.

But I’ve also invested time in free activities that paid off in a big way. A few years ago, I started attending a software craftsmanship meetup. I met developers that had a completely different mindset. It was all about learning and coding together and getting out of our comfort zones.

I still go to one of their conferences per year. I highly recommend joining these conversations. Pairing up with someone working in a new language or on a different topic from your own is definitely worth doing.

“Don’t over-engineer. I’ve done that… I learned to be more pragmatic and build what’s needed without trying to build a spaceship.”

We all have a lot to learn from each other. What is something you wish someone had told you when you started developing that you had to learn the hard way?

Don’t over-engineer. I’ve done that. Like splitting everything into tiny modules, trying to build this one perfect system that fits everywhere. Later, I realized I had missed one point and we always will. I learned to be more pragmatic and build what’s needed without trying to build a spaceship. Often, what you need later will be different than what you imagine now.

Here’s another important lesson: It’s okay to say no. If you know that you can’t make a deadline or can’t build a feature, say no. Raise your voice. I think a lot of developers don’t do this. I’ve been in situations where everybody sat together knowing that we wouldn’t make the product in time, but no one said a word. This is especially something that especially happens to junior developers.

Finally, I’ve learned that it’s okay to fail. I mean, it happens. Learn from your failures.

Sometimes there is a collision between people who are focused on products and developers. Developers need to see the technical sides like complexity. They know timelines might not be achievable. As a software engineer, how would you face these problems? How would you let another person know that something couldn’t be done or needed to be done another way? In other words, how exactly would you say no?

I’m very direct. When I need to say no, I say no and tell my reasons. If necessary, I will explain why I think something isn’t possible.

That’s important, if I leave just a bit of doubt, the response might be, “Yeah, but come on, give it a try.” In general, I think we need to be firm when we say no. Often, saying no is an opportunity for discussion. Maybe your colleague has a different opinion for different reasons, for example.

I like when everyone puts what they have on the table. You may start with disparate opinions, and after discussing, both parties might end up somewhere new, whether or not they agree with each other. This is exactly what we need to do in this kind of situation. Is the “no” “no,” or has one person missed the point? Maybe one side just understood something wrong or maybe the other person didn’t know how complicated the situation was. It’s important to talk things through and uncover these assumptions.

I agree. Transparency is important in these conversations.

Sometimes I feel that people in different roles speak different languages. For example, many developers don’t like to talk to stakeholders because they feel the stakeholders don’t speak the developer’s language. The stakeholder might not understand what the developer wants to say. This is a problem.

But also, trying to understand the other’s position is important. Developers don’t always ask why we are doing something. In response to a job ticket, a junior developer might follow the description without asking what the point is. What is the task we are trying to achieve? Frequently, there is a better, maybe simpler way to respond. I think the more we discuss a project, the more specifically we can identify our goals. In the end, a timeline that seemed unachievable may be achieved by using different strategies.

In our industry, it seems a common aim for developers to jump up to the corporate ladder and become managers. What are your thoughts about this?

Yes, but I have a feeling things are changing here. There are still many developers out there who want to become managers. But many veteran developers are still coding and teaching. I hope that developers will stay in development but regularly dedicate a portion of their time to sharing their knowledge. They might not be coding all day. They become mentors.

I can use myself as an example. At some point, after I became a manager, I went back to development, full-time development, and went back and forth ever since.

Uncle Bob keeps saying that every five years the numbers of developers worldwide doubles. Think about the number of junior developers out there who need instruction from those of us who came before them. We may need fewer managers but more mentors.

Since you know what it’s like to be both the developer and the manager, what would you tell a software developer who wants to transition to a management role?

First, I would ask why he or she wants to become a manager. Is there a desire to manage, or does it just seem like management is the next step on the career path? Are they following a perceived trend, or is it really what they want?

When considering a move to management, one question you have to ask yourself is how much you can still code, and how much do you want to code? Many developers who make the leap into management want to keep coding. On the one hand, it’s great to have managers with current knowledge. On the other hand, it’s difficult to play multiple roles.

Companies are finding different ways to deal with this. In the last ten years, I’ve seen the emergence of leadership roles for engineers like Team Lead, Architect, and other principal roles, and then there are management roles focused on managing people. In some cases, this organizational style means your boss might be paid less than you. I think this is really a game-changer.

Also, once you become a manager, two problems arise. First, it’s harder to find a new job because the industry needs fewer managers than developers. Second, as a manager, by the time you’re looking for a new job, your technical skills might be outdated. Who’s going to hire a manager with outdated knowledge? It’s important to keep these things in mind.

How do you keep yourself learning new things and staying up-to-date on every new framework technology?

I follow Android Weekly and Kotlin Weekly. Platforms like Medium send you recommendations based on what you read. Those recommendations often help expand my interests or knowledge base. But in the end, it’s all about talking to people. Go to meetups. Go to conferences. It’s not so much about the content you’ll see. It’s more about informal information sharing. I was introduced to Kotlin in this way, and one week after hearing about it, I started using it. You can’t overestimate the importance of these experiences.

Another way I learn about a new topic is to talk about or blog about it! Because there’s always that moment when you have to dig into the topic and you’ll find out at least one thing that you didn’t know before.

There is this Chinese saying, right? If you want to learn something, teach.

Yeah. It’s totally true.

You’ve spoken at many conferences. How would you recommend someone gets started speaking at conferences?

I’d recommend starting with a meetup because it’s a smaller audience. Start with an audience of ten people and work your way up. In front of a smaller group, you can be very technical. In the end, speaking at a technical conference or a technical meetup is just sharing what you know, right? It’s easy to forget this. This is the one tip I would give people who are nervous to speak to a group: You’re probably the person who knows the most about your topic. Talk about what you know.

Many conferences include a short format, like “lightning talks.” It’s much easier to do a 20-minute talk than to deliver a full hour. Start small, and ask people for feedback. Then, do it again. The second time will always be better than the first. You learn from the mistakes and from feedback, and you improve. Don’t give up after the first time. Even if your first public speaking experience went well, try to give the same talk again.

Let’s talk about your daily routine. How do you set yourself up for success? How do you keep working through the day?

I don’t really have a morning routine. But I think the best moments are those when I’m starting with something active like going running. I live by the water, so in the summer, I like to start my day with taking the kayak out for an hour. I feel much more relaxed when I start my day with something active. I use my bike to commute to work, whether it’s five minutes or 45 minutes. Exercise gives me the energy for the day I would say. Then comes the coffee, afterwards.

What’s your best advice to a person starting a career in software development?

Here’s an important lesson: Every developer will face a situation in which a fixed deadline requires the scope and quality of a project to flex. When you’re asked to compromise quality for time, here’s my advice: Don’t make something quick and dirty. A temporary workaround will live much longer than you might think.

What are your views on remote work?

In my last job, I became a fan of remote work. In general, I think it’s here to stay. It’s the future of work. We have to learn to adapt to it because it’s easy to get remote work wrong. Many people who work remotely find increased happiness. They are much happier if they can work from home, for example. They may also notice a productivity boost.

But remote work also can lead to a productivity drop for a team. For example, if everybody is sitting in one office and one person is working remotely, or if the majority of the team is in the office and a few developers are remote, the productivity will likely not increase. Often, the problem is that the workflow isn’t set up to be remote-friendly.

You have to adapt a lot of your daily routines and tools to be remote-friendly. I think you only learn that if most of your developers are remote. For example, if you’re trying remote work, it’s best if everyone works at least one day from home a week, if only to understand the experience. There are many things like this that you need to adapt to make work remote-friendly.

In general, I love remote working. I can go to different cities and work from a café or home office, or at a conference, and I feel very productive. I like having this freedom. This is something that long-term I want to do more, but there are a lot of things that you have to get right with the team to make that possible.

How can a company implement a good remote-work policy? What are the first aspects that they should care about?

In general, a company that wants to implement remote work needs to assess whether the tools it currently uses will work in a remote setting. I think all remote teams have something like Slack, which allows everybody to communicate. A company going remote should move all discussions into this kind of tool because talking in meeting rooms leaves the remote workers out. In the end, it’s all about documenting your decisions and making sure everyone has the same information.

As well, try to make remote work a nice atmosphere. I try to build this when I build a team. It’s hard, but possible. For example, if you have two offices, set up a camera with a constant stream of the office so remote workers feel connected.

A company going to remote work should anticipate a lot of video conference meetups. This means using tools, and of course, tools break. You can easily waste 15 minutes trying to fix your video conferencing. Be prepared for this. Have a backup plan. Okay, Skype doesn’t work today; let’s all go to Hangout. The best tools aren’t necessarily fancy. You can draw on a whiteboard in front of the camera. Use what tools work best for your situation.

A primary challenge is to adapt to an asynchronous way of working. We are used to synchronous communication. It gets much harder with remote work. With remote work, colleagues may be in different time zones. Answers may come six hours after questions. The whole idea of remote work is to get the best talent, and the best talent may not be local.

At some point, to accommodate time zone differences, you’ll have very early or late meetings. Keep your meetings to a minimum. At one company that I worked for, we had a daily developer call held in the evening when the people in New York were waking up. We also had a daily morning meeting. So only part of the development team was there. Sometimes this was five minutes, and sometimes it was an hour but it was the most effective meeting we had. Be really pragmatic about this.

In the end, remember that even remote workers should meet face-to-face. You have to come together, not only to discuss things easily, but also to feel connected. Go out and have fun together, right? I think this is really, really important. Often, companies choose remote work because it’s cheaper. Bringing people together is an additional cost that’s needed to create a team feeling. Having trust between team members is so important. Face-to-face meetings help build that trust.

Many companies choose to work remotely because it’s cheaper. I think a company’s motivation to go remote should be a move to a global workforce. What do you think?

I totally agree. There are two things that remote work provides: The remote worker gets happiness and freedom. The company gets the best talent pool in the world. The moment we open all jobs and resources globally, we can compete for the best talent.

Is there a tool you use for remote work that is maybe not that well-known and you would like to share?

I’m a big fan of Screenhero. It may have been integrated to Slack now. I’m not sure whether Screenhero is still 0.8. It was the first tool to allow for remote pairing, which was really, really awesome.

To do pair coding right?

Exactly. With Screenhero, you could share one screen but use two mouse cursors. I think a lot of those things are integrated right into Slack so that you can draw on the other person’s screen. This is super important for sharing things.

Finally, how do you stay focused through an entire day of distractions?

A lot of developers want to be in this flow, this highly concentrated mode where they don’t do anything but code without interruptions. In reality, working like this is very draining. I prefer a more relaxed environment. I like to ask questions and listen to music while working.

Which brings me back to TDD. Small and continuous test cycles allow developers to build in time for distractions and interruptions.

That reminds me of another tip I’d give to a junior designer: When you have a list of things you need to do, start with the ones that are quickly done, even if they are the ones that you don’t like to do. This way, you can accomplish a volume of your TODO list quickly and spend more time on the one thing that takes three or five hours. Following this system, you’re not stressed at the end of the day because you didn’t do all these small tasks. This has really helped me.

Danny’s Recommendations

• Clean Code: A Handbook of Agile Software Craftsmanship | Robert C. Martin
• Effective C++: 55 Specific Ways to Improve Your Programs and Designs | Scott Meyers