29 An Interview with Paul Blundell¶
Paul is Head of Engineering and a Google developer expert for Android & IoT, based in Liverpool in the United Kingdom. He is a remote Android expert who enjoys innovating within his company and growing his engineering skills. In working with teams, he values communication, continued learning and mentorship.
Paul Blundell
Connect with Paul¶
Twitter: @blundell_apps LinkedIn: /in/blundell Website: blog.blundellapps.co.uk
Interview¶
You have over 57,000 reputation points on Stack Overflow, which makes you one of the top contributors. How do you find the time to contribute so much?¶
My Stack Overflow score has come over ten years of industry work. I started contributing answers about six years ago. That’s 10,000 rep points per year—roughly 1,000 per month or 250 per week. You could provide two or three answers per week and with compounding interest get the same score. The point here is those big successes may look amazing, but they are made up of little steps. If you want to achieve something, take the first step. If you have never answered a question on Stack Overflow, start by making your goal to answer one question.
Contributing regularly and making it a habit is the secret. To form a habit, you have to do something repeatedly, and that means you have to enjoy it. I enjoy helping people, and I enjoy learning by getting to the bottom of problems. Combining these two things is what keeps me checking Stack Overflow every other day and contributing to helping others. Find something you enjoy, and then find an outlet for it.
You’re the author of Learning Android Application Testing. What did you learn from writing a book that you might pass along to an aspiring writer?¶
Writing a book is hard work! The book I wrote was a revised edition, so I had a rough guiding structure in place already. I learned that writing a book is just like any other problem: You break it down into its smallest components and build it back up. The publishing team really helped with this. In general, when you write a book, there are a lot more people involved than just the author. My writing process went like this: I wrote a sentence or two about what I wanted the reader to have learned at the end. Then, I wrote a sentence or two about what type of reader would read this book, and then a list of bullet-point steps to get from the start to the end. Then, I took each of these bullet points and repeated the process: What is the end goal of the bullet point? I found the starting point for each point and generated a list to get the reader from A to B. That’s the magic of writing a book! It’s the same process I use when writing blog posts, just scaled up to many, many pages.
For an aspiring writer, I would recommend they drop all other hobbies while writing the book. You want to give the book all of your attention because you want to get it completed. A half-finished book would be a very heavy burden hanging over you, and once you put a project like that down, it’s quite hard to pick it back up again. I’d also tell them that writing a book is entirely possible. Start by breaking down the problem into small chunks, and remember: No one writes for the money.
You’ve offered some concrete steps to tackling a complex project. Does that advice apply to leadership, as well? What does great leadership look like to you?¶
Leadership can come in many forms. It’s not just about being in a management position or having control over people or budgets. Leadership is about helping people. It’s about showing them the light at the end of the tunnel and showing them that getting there is possible. You can be a role model without realizing it and without being in a standard leadership position. I believe in servant leadership, which means enabling others and sharing power and responsibility. A good leader listens to those around them and makes sure team members have what they need to succeed. When the opportunity arises, a good leader finds the team best suited to succeed in the project and enables them to take ownership.
Are there specific resources that have helped shape your beliefs about leadership or that have had a lasting impact on how you do your work?
Turn The Ship Around! by L. David Marquet is a wonderful example of leadership, showing how to create a culture of leaders, not followers.
Clean Code: A Handbook of Agile Software Craftsmanship and The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin and have to be mentioned as resources. They set out what a professional programmer should be and how they should act. These books guided me and my early career a lot.
Introducing Neuro-Linguistic Programming: Psychological Skills for Understanding and Influencing People by Joseph O’Connor and John Seymour is an amazing book to open your mind to the other skills you need in the workplace. If you want to stick to programming books, 97 Things Every Programmer Should Know: Collective Wisdom from the Experts by Kevlin Henney is also a great reference for improving your pull request conversations—it’s like if you’d sat in the pub for the previous 25 years and heard great anecdotes from fellow developers.
What do you wish someone had told you when you started software development that you had to learn the hard way instead?
There are definitely lessons I’ve learned the long way around, but because of that, I’m a more rounded developer. Having a shortcut at the beginning isn’t always the best idea. That said, I wish I’d known that programming is more about the conversation and expressiveness of the code than it is about a correct answer. If you can explain to those around you what the code is doing, then that code or project will be more successful in the long run than a project that works for reasons no one can understand.
What negative trends do you see taking shape in the industry right now?
Everyone is trying to solve problems. Some people may take a complex route to the answer, but they’ll learn, so I rarely call people out as wrong. Also, history has a habit of correcting people. I’d rather talk about what I believe will be the most successful industry trends in the future.
There’s a reason everyone is taking a functional approach to programming right now. The benefit I see in it is the immutability and the guarantee of a known state. Allowing people to debug and avoid crashes is much easier. This is possible in OO programming, but it’s not enforced in the same way. On the other hand, OO programming is much better at showing what is going on in terms of the domain and the lexicon of the product and what the rest of the business is talking about. I believe most apps are going too far in the functional direction and too easily dismissing what object-oriented programming brings to the table. The future is some combination of them both.
Outside of programming, edge computing and IoT is so on-trend. There’s a real push for cross-platform development to succeed, and the latest attempt at this is Google’s Fuchsia OS. My understanding is that this OS is trying to be the answer to all hardware, from low-end embedded devices through mobile and all the way up to desktops. This new OS, combined with edge computing and computer-inference and machine learning required to be locally on the device rather than in the cloud—this is the place to be and the wave to ride for engineers in the next 10 years.
What would you recommend to a fellow software developer who wants to transition to a management role?
Remember that as a manager, you’re there to make other people succeed. Managers succeed through others succeeding, and sometimes that means they leave their managers behind. Before becoming a manager, ask yourself whether being in a management role will motivate you.
Novoda, where I work, has an open-source learning program called the Novoda Crafter University. I’ve given talks on it including at Software Craftsmanship London. Novoda NCU is a guide to learning for our engineers, and just recently we added a module on Management. Two books from this I really recommend are The New One-Minute Manager by Ken Blanchard and Johnson M.D., Spencer, and The Truth About Employee Engagement: A Fable About Addressing the Three Root Causes of Job Misery by Patrick M. Lencioni. I would say, if you read these two books and embrace their teaching, you’ll have a stable core of what it takes to be an amazing manager of people.
“I often see developers favoring “new tech” over paying attention to the details… Attention to the details allows you to understand core concepts and the reasons behind shiny new libraries to become a thought leader rather than a user.”
What is one core concept that most software developers don’t pay enough attention to when trying to grow their careers?
I often see developers favoring “new tech” over paying attention to the details. It’s great to stay current, but there’s no point in embracing the latest reactive library or dependency injection framework if you don’t try to understand the reactive paradigm at its roots or know how to do manual dependency injection. Attention to the details allows you to understand core concepts and the reasons behind shiny new libraries. This way, you can become a critic and thought leader rather than a consumer or user.
Another example of the importance of attention to detail is reading your own code over and over. Once your code works, don’t just ship it, read it again for clarity. Ask yourself whether someone else will understand it. Walk away from the code for twenty minutes and see if it’s still clear. This attention to detail is what separates good developers from great developers.
What resources do you rely on to stay current in your industry?
A strong peer network is always important, whether virtual or physical. There is always more information than you can consume; however, if you share the top ten percent of what you learn, and your peers around you do the same, then you’re all learning from each other and helping each other.
I also rely heavily on learning through side projects. It’s fun to create things that solve a problem. For example, once I created a script that parsed all pull requests in a GitHub repo and pulled out all GIFs to show a history of the product evolves. I solved that problem and also learned a lot about the GitHub API and recursion. Sometimes side projects can be directed learning. For example, I want to learn about technology X, so I think of a scenario that might be interesting to make an application about. Another time, I research what technology would be the best solution. If you’re stuck on a side project, explore Stack Overflow, where other people share their problems or projects. Often, I have to learn about a new subject before I can solve a new problem.
What are three development tools you can’t live without?
Google! Seriously, I google everything! Sometimes it’s to use tools like formatting JSON, converting millis to dates or a regex helper. Other times, it’s programming answers or tech insights. I come across my own blog posts or Stack Overflow answers sometimes, which reassures me that there is a known answer, though then I worry about having forgotten it. Everyone googles, and googling efficiently is a skill to embrace!
The second go-to tool I use is Slack, formerly ScreenHero, which is used for remote pairing sessions. It makes coding in a pair so smooth. It’s such an invaluable tool. The integration with Slack allows for more distraction when pairing, but the tool is still great for feeling that you and someone potentially across the world are working on the same problem.
The third is my IDE, IntelliJ or Android Studio. It automates so much about my daily tasks and is always improving, especially the refactoring menus. While refactoring is also possible manually, the power to inline classes or rename across a whole project allows me to concentrate more of my time on solving problems and therefore doesn’t give an excuse or barrier not to refactor. Understanding the power of the IDE is understanding what it is doing for you. Refactoring: Improving the Design of Existing Code by Martin Fowler explains the mindset of breaking down problems, everything is step by step, showing how to tackle complex refactoring issues.
Speaking of daily routines, how do you set yourself up for success every day?
I don’t! I’m a night owl. I stay up late tinkering and don’t stop until I complete a task! Then I make sure I get my eight hours of sleep to be ready for the next day. The effort to make sure I get a full night’s sleep is what I think is important.
How do you stay highly productive for long stretches of time?
For me, high productivity doesn’t occur over a long stretch, but I know what high productivity feels like. When I’m feeling productive, I make sure I’m working towards a task I want to complete, versus when I am feeling unproductive I play around. I’m not highly productive for long periods, but I am highly productive for long sessions interspersed with downtime. Giving myself that downtime,to browse cat GIFs or play the Switch is what spurs me on to do the next iteration of productive work.
Paul’s Recommendations¶
- Your Money or Your Life: 9 Steps to Transforming Your Relationship with Money and Achieving Financial Independence | Vicki Robin
- Blundell Android Developer tutorials and blog | blundellapps.co.uk/