27.
An Interview with Annyce Davis
Written by Enrique López-Mañas
Annyce spends her day-to-day working as a Software Developer and Leader. She’s specifically been focused on mobile application development for the past decade. Annyce is also an Android Google Developer Expert, developing videos, blog posts, and conference talks for the Developer Community. She’s currently Director of Engineering at Meetup. There she uses technology as a tool to help others foster real-world connections.
Connect with Annyce
Twitter: @brwngrldev
LinkedIn: /in/annycedavis
Interview
You are a resource in the Android community, having been quoted across media as one of the key individuals to follow. In one of your blog posts, “So You Want to Be an Android Developer…” you give your readers a guide to get started or grow their current skills. What are the key takeaways from this article?
The key thing I want people to understand is that you need a good foundation in the basics: XML, Java, Object-Oriented Design and then you can add on to your skillset bit by bit. The other thing I’ve noticed with working on Android for so long is that eventually, Google will come out with their own version of the most popular libraries or patterns that the community is adopting. So sticking to the Jetpack toolchain is a good decision for the long run.
Overall, you are a very prolific contributor to the Android community through video tutorials, blog posts, and conferences. Where do you find your inspiration for new projects and content?
I get inspiration from my everyday activities. As I explore new technologies, frameworks, and design principles I always think to myself, “This might make a great talk/blog post/course.” I love creating content as much for others as for myself. I find the creative process very rewarding and it helps me to solidify the materials in my own mind.
What advice would you give to developers interested in starting to produce and share their own tutorials, articles, or presentations?
One thing I do is keep a running list of things that I’m working on, or I’ve learned recently in a markdown file. This makes it easier for me to draw on when I’m ready to create a blog post or presentation. I’ve also written about my process for conference talks and course creation. I would recommend they check it out as it’s still relatively close to how I execute currently.
In terms of your own development, what role models have helped shape your career?
Chiu-Ki Chan has had a huge impact on how I view myself as a developer and leader. When I first started speaking at conferences, she was the voice in my ear that told me I belonged and I had something worthwhile to say. I also appreciate how we can share ideas with each other and be open about our ambitions and goals. Hands down, meeting her turned my career in a whole new direction! Further, I appreciate my current manager a lot. His approach to dealing with diverse perspectives and personalities has really encouraged me to explore my own strengths and weaknesses when it comes to managing others.
Donn Felker, Florina Muntenescu, Ian Lake and Rebecca Franks are others who come to mind who have been positive influences.
Many developers rarely get any formal training during their education, relying heavily on soft skills in addition to their knowledge as developers. It seems soft skills are often underrated. What are the soft skills you consider more important when working on a team?
Being able to communicate effectively is key. This covers how you express yourself in meetings, technical documentation that you write, even how you come across on Slack. Being an effective communicator will help you to stand out from your peers.
In terms of using resources for your own development, which do you prefer: podcasts or books?
I prefer books. Although I listen to several podcasts, I appreciate being able to explore various topics in more detail and generally, books do that better. I also find it easier to grab a book off of my shelf and refer to something valuable that I remembered reading.
What are the three books that have had a lasting impact on how you do your work?
First, Head First Design Patterns: A Brain-Friendly Guide by Eric Freeman, Bert Bates, Kathy Sierra and Elisabeth Robson. Design patterns help you to apply software designs to your code to improve its flexibility and maintainability. I’ve read several books on the subject, but this one helps to bring it all together with a fun, quirky style. Instead of just tons of text explaining a pattern, it uses examples and silly scenarios to help you understand the reason for a particular pattern. In fact, I’ve found several examples in my current application where the Command Pattern has helped to clean up the code tremendously. I’d recommend getting the paperback version as this is one that you should keep in your library.
Next, The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change Paperback by Camille Fournier. “Actionable advice” is the best way to describe this book. It starts out by explaining what you should expect from a manager and then goes into how to be managed. This section was great for me because it helped codify some thoughts I had around where I want to go next with my career. Especially the section on taking ownership of your relationship with your manager and not just letting it be a top-down exchange. I have recommended this book to so many people at this point. If you’re still on the fence, just do it; you won’t be disappointed.
Finally, The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin. This book really spoke to me. It aligned with feelings and thoughts I already had around professionalism in the tech industry and commitment to tasks. I appreciate the very conversational style and the fact that the author shares the times when he failed to do the right thing and the bad effects. I feel like this is great for people new to the industry to read and internalize so that we can have more professional behavior on software teams.
What do you wish someone had told you when you started software development that you had to learn the hard way?
I wish that someone had told me there’s no such thing as just a minimum viable product, or MVP. Earlier on in my career, I would be asked to just put something together, simple, fast and does the job. We just need an MVP. But invariably it never stays as just an MVP and ends up making it into production and you have to live with that code for a long time. Although it’s important to move quickly in many cases, you still need to use a good design and have tests. So now, if I’m asked to do an MVP, I always design it in such a way that I could live with that code for the next year or two.
What is a current industry trend that you think is just plain wrong?
One thing I wish would die is the tendency to “poo-poo” on anything that you don’t personally agree with. For example, there is a resurgence of libraries that are based on the Service Locator pattern. There are die-hard dependency injection guys that make sure every chance they get they point out that something is not “real DI”, etc. This just seems to miss the point for me, obviously, these types of technology trends surface for a reason. They point out that there’s something lacking with the current, more popular choice.
What would you suggest is a better alternative to this trend?
I would love to see people engage in more useful dialogue. For example, if you see a trend that you don’t personally agree with, why not try to find out why things are shifting. Why are people getting fed up with the current solution? What can we do to make things better for everyone? Just more of a community spirit, instead of “us versus them.”
Currently, you are working at Off Grid Electric, which is a fully remote team. What are the most significant challenges of working on a fully remote, or distributed, team?
The biggest challenge is having visibility into what everyone is doing. When you’re colocated with your team you can just walk over to someone’s desk and check in with them. Or you can look over and see them deep in thought as they try to figure out a nagging bug. But when you’re distributed you can’t just do that, so it takes more effort to keep everyone in the loop.
“The best thing you can do as a remote employee is to be visible on your company’s chat platform, contribute to virtual meetings as much as possible and keep confirming that the work you do is valuable to the business.”
What are the best tools you’ve found for working successfully in a remote position?
The best thing you can do as a remote employee is to be visible on your company’s chat platform, contribute to virtual meetings as much as possible and keep confirming that the work you do is valuable to the business. I’ve seen many people leave remote positions because they started to feel that they weren’t working on high-value items to the business. This can happen easily, so you have to put forth the effort to stay in sync with the direction of the company and advocate for yourself so that you are always working on things that push the business forward.
In setting yourself up for work, how do you start your day off with a bang? Do you have any secret morning routines that set you up for success?
I start each day with a clean slate. Whatever happened the day before is in the past. I don’t like to let negativity linger in my life or in my mind. It prevents me from thinking creatively and from experimenting. I wouldn’t really consider that a secret, but it’s just something that I try to do and it helps when things get a bit crazy at work.
How do you stay highly productive for long stretches of time?
My favorite thing is to listen to brain.fm with noisli.com—the combination helps me to stay in the zone and I can easily focus uninterrupted for two hours at a time.
Annyce’s Recommendations
-
Head First Design Patterns: A Brain-Friendly Guide | Eric Freeman, Bert Bates, Kathy Sierra and Elisabeth Robson
-
The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change Paperback | Camille Fournier
-
The Clean Coder: A Code of Conduct for Professional Programmers | Robert C. Martin.