41 An Interview with Mark Allison

Mark is a GDE for Android and software engineer with over 30 years experience. He is passionate about providing the user with the best possible experience. He has developed both server and client side, most commonly Android on the client side, but also for iOS, HTML5, Symbian, and J2ME. Mark started writing a technical blog blog.stylingandroid.com in 2011, which focuses on Android UI/UX topics, but often covers more general Android development techniques. It is recognized as the longest running technical Android blog and, aside from a six-week period where contractual issues prevented him from posting, Mark has published a new article every week since 2011. In 2014, Mark started Styling Android Limited, which provides freelance software development and consultancy services. When not being geeky, Mark likes to unwind by hurling abuse at football referees, specifically those who are unkind to his beloved Watford FC with whom he holds a season ticket. Mark also loves single malt whisky. Buy him one and you’ll have a friend for life!

Mark Allison

Connect with Mark

Twitter: @MarkIAllison Website: blog.stylingandroid.com GitHub: github.com/StylingAndroid

Interview

You’ve been both an employee and a business owner. What are the most significant differences in how you approach your work as an employee versus an owner?

As a business owner, I find I view some things in a much more detached manner. For example, when negotiating new contracts, the head has to rule the heart and do what makes sense from a business perspective. On one occasion, I was in a position where I had two separate offers on the table for different roles, and had to choose between them. However, only one of the parties involved had actually sent me a contract, the other had promised a contract but never sent it. In that case, it reached a point where I was forced to make a decision that was based on what was right for my business and ignored my personal feelings of which one I would prefer to do.

I also view the company finances as completely separate from my own. I am an employee of the company and it is in my own best interest if the company is in a healthy financial state so that I still get paid even if the company is not in a contract for a period of time.

What would you say to someone interested in transitioning from employee to business owner?

While I love running my own business, it may not be for everyone. Discipline is required both in the financials and in doing the admin or bookkeeping tasks. Although I have an accountant who takes care of much of the tax and accounting-related issues, there is still work that I need to do.

Is there anything you miss from working at a larger, more traditional company?

Not really, but it really is a personal thing. While it is easy to say things like I miss paid vacation and getting paid if I’m sick, I don’t really see that as an issue because I run my business so that I still get those benefits as an employee of my own company.

Now that you manage your own busy business, how important is networking to finding work or advancing your company?

Most of my contracts arise through word-of-mouth. I rarely go through third-party agents unless the company I’m contracting for requires it. In four and a half years, only one of my contracts has been via a third-party agent, the remainder has been direct. For the one that was via an agent, the agent was instructed to hire me by the company I would actually be working for, and I didn’t find the role through the agent. So networking is hugely important when I’m on the lookout for new contracts. I have also had some luck with some Android Slack channels where I have been able to put feelers out and have private conversations with people who are hiring.

What are some tricks for successful networking?

If I’m perfectly honest, being known within the industry for my blog is incredibly useful. I have a reasonably good following on Twitter mainly because of my blog and that is really valuable when it comes to putting the word out that I’m on the lookout for a new contract position.

Your blog, Styling Android, is remarkable in that it publishes a new article every week. That is an impressive pace! What is the secret to consistently publishing such quality content on such a regular basis?

Be a really hard taskmaster—on yourself! It’s nothing more secretive than hard work. When I first started writing my blog, I published content on an ad-hoc basis. I would write content as the ideas occurred to me, and then hit “publish” as soon as it was complete. However, quite early on, I recall reading somewhere that to grow traffic to a blog, it was important to keep a steady flow of new content. Having a somewhat compulsive nature—as I’m sure many software developers do—I decided to apply this by posting new content every week, and settled at 10 am. UK time on Fridays. There have been many occasions over the years where I cursed myself for deciding upon such an aggressive timescale but, apart from a six-week spell in which I was unable to post for contractual reasons, I have never missed a week. Even when I have vacation scheduled, I get posts prepared for while I’m away so that I can still meet my weekly post schedule.

How do you choose what content to focus on for your site?

I try to find content that I feel either hasn’t been covered elsewhere in any depth, or that I feel I can provide a different view on. On occasion, I find some cool APIs or tools of which I wasn’t previously aware, and simple enthusiasm for something interesting does the rest! For the vast majority of articles, I write the supporting code first, and then the article text really describes what I learned in writing the code. If there are any pitfalls, they tend to get flushed out while I am trying to get the code working, and then they become important aspects of the article.

I always feel that a clear narrative is required. Much as a fiction story has a beginning, a middle and an end, I feel that the same is true of a technical article. At the start, there is a problem that we identify, then we go through how to solve that problem, and finally we look at how effective the solution was. I have a number of posts that never saw the light of day because that clear narrative was simply not obvious to me once I had some working code.

As a consumer of content, which do you prefer: podcasts or books?

I always find the written word has more value to me than the spoken word, so it would have to be books. One of the reasons that I prefer books is that it can be much easier to find what you’re after if you need to return to a specific piece of subject matter a while later. A book often has a table of contents and/or an index that can help find relevant material later on. While some podcasts do provide a list of contents, books tend to do this much better.

What are the three resources that have had a lasting impact on how you do your work?

For Android, Mark Murphy’s books are always the ones I recommend. The Busy Coder’s Guide to Android Development is a great book for both beginners and experienced Android developers because it is so wide-ranging in its subject matter—plus, it is regularly updated so remains current. It’s the book I always recommend if anyone asks me how to get started in Android, and I have even gifted subscriptions to it to a couple of people. An honorable mention has to go to Reto Meier and Ian Lake’s Professional Android. This is another great Android book but Mark Murphy gets the nod from me because it’s kept extremely current.

For more general development topics, Robert Martin’s “Clean” series are helpful: Clean Architecture: A Craftsman’s Guide to Software Structure and Design, Clean Code: A Handbook of Agile Software Craftsmanship and The Clean Coder: A Code of Conduct for Professional Programmers. These books are really great for understanding of the organization of your code, and architecture can make life so much easier not just in the short term, but for the future you who may have to maintain the code you write now!

In terms of writing good Android code, Joshua Bloch’s Effective Java should be in every Android developer’s library. Even if your project is 100% Kotlin, much of what is covered is still very relevant in a Kotlin world. What is something you wish someone had told you back when you started software development, that you had to learn the hard way instead?

Never be afraid to discuss a problem with someone else. It doesn’t matter how experienced or inexperienced you are, often if you are stuck on a particular problem, explaining it to someone else can help you to understand the problem better. Rubber-ducking can be an extremely effective debugging strategy!

Are there any current industry trends that you think are just plain wrong?

Over-reliance on specific tools can be a really bad thing. It’s not the tools themselves that are the problem, but more the attitudes of developers regarding to how and where to use those tools that is the issue. This is by no means a new thing, so I’m not really highlighting a “current” trend as such, but more of a mindset problem that some developers have.

In current terms, RxJava tends to be rather over-used. Please don’t misunderstand my point, I do not dislike RxJava. What I dislike is how some developers see it as the solution to every problem. I have seen code where an Observable has been used to replace a for-loop. This achieved nothing other than making the code less efficient and more difficult to understand. It is the classic example of if the only tool you ever use is a hammer, then you automatically view every problem as a nail.

As I have said, this is by no means a recent problem, or a problem specific to RxJava. Back in my time as a backend Java developer, I can remember very similar attitudes from some developers with regard to Spring Framework. On one occasion I was discussing with another developer how we might go about implementing a specific backend and while we were still scoping out the problem domain, he started typing away. When I asked what he was doing, he stated that he was setting up a Spring Framework project ready for when we had decided upon the best approach. When I questioned if it was sensible to start choosing tools before we even understood the problem, I simply got a blank look.

What would you suggest is a better alternative to this trend?

Always understand your problem domain before you decide on the appropriate tools. Always remember that a screw does not stay fixed to a piece of wood if it is hammered in rather than being screwed in with a screwdriver!

In working on your projects, how do you start your day off with a bang? Do you have any secret morning routines that set you up for success?

Every morning before I start work, I go for a long walk of around four miles / 6.5 kilometers. It’s a great way to clean and organize your mind before starting work for the day. I often find that I do my best work in the morning after my walk because I have had a chance to think about how to solve the problems I’m facing. The simple fact that I’m far away from my keyboard keeps this as a time for thinking. It’s also good exercise, which is important when much of my day will be sedentary.

How do you stay highly productive for long stretches of time?

I try not to work for long interrupted stretches. I always take an hour for lunch because it helps my productivity when I switch off then come back to things. If I find myself stuck on a problem, often it can help to step away from it for a while and come back. Sometimes viewing a problem from a fresh perspective can give the necessary breakthrough.

“Every manager knows that they’ll get the best out of developers if they’re working on the things that they enjoy, and it provides developers with the best opportunity to do their best work.”

Overall, what advice would you give to a new software developer who wants to have a satisfying career—not just a successful career?

As obvious as it sounds, find something that you enjoy doing. If going to work each day feels like a chore, then you’re never going to have a satisfying career, and you’re less likely to even have a successful career if your heart isn’t in it. If there’s a specific area that you really enjoy, then make sure that the people you work with know that, and encourage you to work on the things that you enjoy. Every manager knows that they’ll get the best out of developers if they’re working on the things that they enjoy, and it provides developers with the best opportunity to do their best work. So it’s a win-win situation.

Mark’s Recommendations

• The Busy Coder’s Guide to Android Development | Mark L. Murphy
• Clean Architecture: A Craftsman’s Guide to Software Structure and Design | Robert C. Martin
• Professional Android | Reto Meier and Ian Lake