Effective Interviews ⚡️ Chris Banes
Composer of the pixels 👾 GoogleDevExpert for Android. Previously Twitter, Google
⚡️ Welcome to the 3rd Effective Interview ⚡️ a series of written interviews with well-known engineers from the Android worldwide community.
Subscribe to get them in your email 📩
Today I have Chris Banes, yet another Android King! 👑
When the very first Android developer was about to land on Earth, Chris was already there, waving from the ground 🙋♂️
Chris is a true Android expert. He owned and led engineering for the AppCompat and Material libraries. His previous work impacts the developer experience of thousands of Android devs today. He led several teams and projects at Google, including DevRel teams. He also worked as a Staff Software Engineer at Google and Twitter.
🟣 Welcome to the Effective Interviews Chris 👋 it’s awesome to have you here 🥳
Thanks for having me Jorge! For those that don’t know me, I’ve been an Android developer for about 14 years now. Outside of work, I’m a big F1 and Football (soccer) fan, and increasingly find it hard to create time to play my PS5.
I recently(ish) moved back to the UK from Australia, and I’m now fully remote from Bath, UK.
🟣 How did you become interested in Android development, and what motivated you to work in this field?
Ha this is going back some time. I bought a T-Mobile G1 whilst I was at university (late 2008), and decided to create an Android app for my ‘final year project’. I ended up building a barcode scanning app, with an accompanying API service which checked prices on Amazon, etc.
I loved the fact that Android was an open ecosystem which anyone could build for, so once I left university I started a few Android side projects. The most ‘well known’ was a Facebook client called Friendcaster (previously called Blue Notify), which I eventually worked on full-time for 2ish years. This was at the time when Facebook were heavily into their apps being web wrappers, so users appreciated having a native client to use.
I spoke at a few developer meetups, and from there I joined Google.
🟣 You spent several years leading DevRel teams. Sounds very oriented to producing high-quality content and learning materials. What would you say are the key points for content to be approachable and understandable?
There’s an old DevRel mantra of ‘show, don’t tell’, which I think summarises what DevRel should be very nicely. By that, it means that the person/team producing the content should be authoritative on the message they’re trying to push. Without that, it’s basically marketing.
Reto Meier wrote a great set of blog posts on this quite a while ago.
When a lot of people think of DevRel, they tend to think about the public outreach side of things: talks, blog posts, videos, etc, but there’s a whole other side to it: writing samples, documentation, libraries, codelabs, filling gaps, acting as the zeroth customer. IMO that’s the more scalable and impactful side of things.
The idea of ‘show, don’t tell’ is that the person who is giving talks, etc has also done all of the rest of the things I spoke about above, to really know the message and be credible. The best DevRel-ers I’ve worked with are those who can do both equally well.
🟣 I am exploring ways to teach people efficiently (for my Jetpack Compose online training). What do you think people value more in this type of content?
I think for courses it’s very much based on making each section achievable and guided. You want people to feel that they’ve learnt and achieved something when spending the time on your content.
I like courses which are basically a list of codelabs which tackle a topic, with a defined end goal of something to learn. That way people can pick and choose what they take, without forcing them to take the previous sections. I really like the way that the Compose Pathways have expanded into playlists of content in a similar vain.
🟣 You traveled the world to attend and speak at tech events. It is one of the benefits we have in this industry. Any memories/learnings from it that you can share? How it feels to speak at Google I/O?
I think the biggest takeaway is that presenting is a skill which you learn through practice. Very few people wake up and are naturally good at speaking, so it takes practice and time to get to the point where it becomes more natural and less daunting.
That is to say: everyone can present at a conference! Lots of people avoid it because they feel too nervous and self-conscious, but being nervous at conferences is perfectly natural. Saying the wrong thing or making mistakes when speaking is natural. I still get nervous before going on stage, and make plenty of mistakes too!
For anyone wanting to start speaking, start small and build your confidence: maybe give some tech talks at work, or speak at your local developer meetup. Once you have the confidence, it becomes a lot easier to speak to anyone and anywhere.
I think I spoke at I/O 4 times, and each time was nerve-wracking. Not only because of actually presenting, but also the pressure of your talk being the de-facto documentation, recorded and analysed by developers around the world.
That happens a lot less these days, as the developer teams at Google have created a lot more pathways to ship updated guidance (sometimes too much), but back in the early-2010’s I/O was the place to publish guidance, which remained in place until the next I/O. The message and content had to be right.
The best bit about conferences though is seeing friends and meeting new people from across the globe. The I/Os at the Shoreline Amphitheatre are great because of the scale, but I do miss the old I/O’s which were hosted in San Francisco. That might just be me reminiscing though!
🟣 You worked as Staff DevRel Engineer and Staff Software Engineer. These roles require an ability to connect the teams and advocate for cross-organization work. Breaking barriers can be very hard in big tech. How do you approach it?
The biggest thing here is knowing how the organisations work! Who are the decision makers? How are those decisions made? What are the goal(s)? What is success? How do you measure that? These things take time to learn, and a lot of the time you will not know all of the answers anyway. Learning to work with ambiguity is a key skill the more senior you become!
For a more detailed answer, I highly recommend reading Tanya Reilly’s book: ‘The Staff Engineer's Path’. The section on the different ‘maps’ an engineer needs to navigate organisations is superb (as is the rest of the book).
🟣 You worked at Twitter (1.0 🔥). It was great to have the chance to work a little bit with you. How did you like your time there? Was it very different than your previous roles at Google? what were your main reasons to change companies?
For me, moving from Google was mostly driven by the fact that I had worked there for 9 years, and wanted to try something new! I am very grateful for the role I had at Google, and actually stayed in the exact same role and team for the entire time. I don’t know many other people in tech who can say that.
Change is a good thing though, and I wanted to try something ‘new’, going back to a more ‘traditional’ Software Engineer role. I could have tried to make that switch at Google, but I’d have had to go through the interview process for the role change anyway, so there wasn’t a huge benefit in staying.
My role at Twitter was very different to Google. I became technical lead of the Client UI Android team, which was responsible for all things UI in the app (similar to a platform UI team in other companies). The team was made up of 7 engineers and an engineering manager, and primarily responsible for making UIs easier to write for our 40ish feature teams. That included the rollout of Jetpack Compose which was a huge undertaking for us. Our ‘Branching out to Jetpack Compose’ talk goes deeper into this.
The biggest change for me was around how the teams worked, rather than the work itself. I found that the teams at Google don’t tend to spend much time on planning work, strategy, etc, and most teams tend to have managers who are also the technical leader (the TLM model). This is a generalization, as there are thousands of teams at Google and each is very different.
Twitter on the other hand was much stronger on consistent planning, sprints, retrospectives, and tying things back to company objectives. Sometimes too strong on it. Teams were also organised differently to Google, with a separate TL (tech lead) and EM (engineering manager) on each team. That was probably the biggest change for me going to Twitter. Going from a TLM to just TL doesn’t sound like a lot, but it fundamentally changes how you spend 60% of your time. I learnt a lot here, and I thank my old EM chain (Dan and Christian), as well as the rest of the CUI team, for bearing with me whilst I made this transition.
🟣 How did you experience the layoffs? Since it is pretty common these days, what would be your advice for people going through a similar situation?
Tricky one. In some ways I got lucky in that I wasn’t technically laid off, I resigned, so everything was settled very quickly. As everyone is probably aware, the job market is tough right now, and it’s probably going to get worse before it gets better.
When I think about it, the skills which have really helped me are things not related to coding at all. Skills such as communication, strategy, knowing what is right for the customer, thinking ahead, seeing problems before they appear, are all super invaluable skills for all roles. I think these are the kind of things which make you stand out these days. This is by no means a checklist though.
🟣 What do you think about the current state of the tech industry? Are you optimistic about the future?
I’ll focus just on mobile development. My biggest fear right now is that mobile development is just unbelievably complex, and thus expensive. Twitter at its peak had over 150 Android developers, which isn’t at all an outlier compared to other similar sized apps. If you assume that each of those engineers had an average total compensation of $200k, there’s $30 million just in comp per year. Do we really need that many people to maintain an app?
I don’t blame engineers here, because I do think we as a community have over complicated mobile development in a lot of ways, and Android is probably the most complicated mobile platform of them all. Google has become more opinionated over the years with its development guidance and libraries, and that definitely helps to give developers a ‘north star’ to target. Teams can choose to deviate from the guidance, but only doing so knowing the risks and costs (deviate with purpose).
At the same time, the Android team doesn't always know what the right answer is, as the skills to write apps is different to creating a platform, so they need the community to drive certain improvements. A prime example is the adoption towards RxJava and Kotlin by the community, which then led to Kotlin and Coroutines being officially supported.
For large apps and teams, I really like the direction of sharing business logic across platforms, combined with server side rendering to reduce the amount of UI logic in apps. The best example of that at the moment is Kotlin Multiplatform, but there is still a huge elephant in the room: getting other platform teams (e.g. iOS) onboard with writing/using Kotlin. Sharing UI implementation via things such as Compose Desktop is cool, but I think it’s less useful for larger teams right now.
🟣 At Google, you worked on backporting features to old Android versions as part of your work for the AppCompat team. Sounds like a challenge. Could you tell us about a project that you found especially challenging?
All of it was challenging, to be honest, but in a good way.
This was a time when the majority of platform development happened in the yearly platform release, and AndroidX didn’t even exist (it was called the ‘support libraries’ back then). Towards the end of the release, I’d go and start pulling in changes from the platform into AppCompat, but the mechanism was haphazard at best. I used to have some shell scripts which opened up a diff tool comparing AppCompat vs frameworks/base (the platform), and then manually copy over diff chunks over, hoping they’d work. If they didn’t, I’d then go in and work out how to make them work.
The most impactful was probably backporting drawable tinting, and what it led to. This was for the Lollipop release, and the team had added drawable tinting to the platform, as a way to reduce the number of theme specific drawables. Since Lollipop was the first release containing a Material theme, all of the drawables had changed meaning that I somehow needed to copy over the drawables into AppCompat, and still keep the tinting working.
At first, I wrote some shell scripts which copied over the PNG files, and then applied the hardcoded tint colour via ImageMagick, ready to be checked into git. This worked but meant that developers couldn’t make use of drawable tinting (unless they were minSdk 21+ of course). I ended up writing what is now DrawableCompat.wrap() and the related functionality, allowing developers to tint any drawable back to API 7.
But of course, having to manually wrap every drawable in code is pretty gross, so I then ended up creating the now plethora of AppCompat specific widgets which get ‘injected’ at runtime via a LayoutInflater.Factory. These widgets implementations were initially there solely to provide the ability to set drawable tinting via XML attributes, all invisible to developers. They have also been used for many other use cases too, including downloadable fonts, and various Material Design Components features.
🟣 What are the main points to keep in mind when designing a library that will be massively adopted by thousands of Android devs around the globe?
First up, you need to have a reason to work and spend time maintaining the library. It could be that your company uses it and is therefore ‘sponsoring’ it through your time, maybe you’re using it in a side project, or even getting paid via sponsorships.
That reason will disappear at some point in the future, so it’s important to be truthful with yourself in how long you see yourself working on it. Seeing a library languish with no updates is a sad thing to see, so having an exit plan is also important.
At a more practical level, I think it’s important to publish your library consistently. Properly named releases, automated snapshot releases, clear changelog/release notes, documentation, and testing is the minimum bar which I personally look for when looking to use a library.
🟣 Sometimes UI development is a bit undervalued by people. I think it can be pretty complicated and also visually rewarding. You have worked on several aspects of Android UI. Would you say that UI is your preferred part of an Android app?
UI is the most impactful place to work for me as it’s so visible to the user. If you increase performance of some database query by 20%, the user will barely notice, but if you create some new UI animation then it’s very obviously noticeable.
That said, there has been a tendency lately for Android developers (and mobile developers in general) to specialise into specific parts of mobile apps. This is mostly a ‘big development team’ problem, but when you zoom out a bit, the problem space of app development isn’t actually that large. Of course there are lots of exceptions to this over generalised statement, but the vast majority of apps are pretty simple CRUD apps.
If we loop back to the future of tech industry question earlier, I see engineers specialising into fairly niche parts of mobile development, which might actually hurt their career long term. That’s OK of course, if it makes the engineer happy. I really like the ‘t-shaped engineer’ metaphor here, where engineers aim to be specialised in (at least) one part of the stack (vertical), but they also have an understanding across the other parts of the stack (horizontal).
🟣 If you had to name another Android developer that you’d like to get interviewed, who would it be?
Christina Lee.
🟣 If you could give one piece of advice to aspiring Android developers, based on your personal journey and experiences, what would it be and why?
The biggest advice I can give people is that only you are in control of your career.
It’s very easy for engineers (especially early on in their career) to think of managers as a kind of parental figure, guiding their career and pushing them to take on new things. That is kind of true, but managers are employed by the company, for the interests of the company. A lot of time these two sides align: growing engineers to take on new things helps the company become more efficient and better at shipping.
But there are also times when the goals don’t fully align. It could be as simple as you not agreeing with the direction of a certain project, or as big as you being sidelined on decisions, promotions, etc.
Now I’m not saying that managers are all the same, because you will definitely see lots of different management styles throughout your career. But this is why it’s important to grow a network of people from different teams, different companies, or even different roles, who you can ask for advice. Different perspectives could help you see things in a different light.
🟣 Where can readers find you?
You can find me at all of the usual places: Twitter, Mastodon and my blog. Don’t be shy.
🟣 Thanks so much for sharing with us Chris 🙏 See you around! 🙋♂️
More interviews lining up already 🔥 if you want more, check all the interviews published so far 👇
If you like this type of content, consider subscribing to this newsletter and joining the other ~1400 people that already read it every day 🚀
