21 An Interview with Ty Smith

Ty lives in San Francisco and has held team lead and engineering management roles at many unicorn startups including Uber, Twitter, and Evernote. He has specialized in building scalable mobile apps and developer tooling since 2009. He is passionate about software craftsmanship, engineering sustainability, and building teams focused on delightful user and developer experiences.

He’s an active angel investor and advisor focused on helping startups scale their mobile and open-source strategies. He cares deeply about the open developer community, is a member of the Google Developer Expert program, regularly speaks at international conferences on Android, as well as organizes the SF Android Google Developer Group and Droidcon San Francisco conference. He’s an avid enthusiast of biohacking, longevity, and transhumanism, and, with his spare time, he enjoys science fiction, cooking, traveling, wine tasting, snowboarding, and scuba diving.

Ty Smith

Connect with Ty

Twitter: @tsmith Website: tysmith.me

Interview

You’ve been working as an Android engineer since 2009. Tell us a bit about how you got started and what the process was like developing applications for Android?

In 2009, I was graduating from college and had been working full time as an engineer, going to school during the evening. It was a very, very stressful time in my life. I was working for a small consulting company doing Ruby on Rails development; the company was targeting mobile customers, really for the first time. So we had a handful of iOS engineers, but iOS was very new at the time, especially its third-party app development. Android was just really coming out into the public, too—I think 1.5 or 1.6 had just dropped.

The tooling was awful, and I hadn’t had any mobile experience. I was a little more interested in iOS development at the time because we had some iOS engineers around, but I was happy to do my server-side development on Rails. We had a pretty large customer, Zagat; it was a restaurant review service, later acquired by Google, subcontracting their mobile apps to this company. So we had a third-party contractor for the Android development side of it; we’d been doing the iOS side. Unfortunately, the contractor had to step away from the project early on. So this left a small consulting company with a very large client and no Android resources.

My boss at the time, Mekka Okereke, said to me, “Hey, Ty, we have this big client. We don’t have any Android resources. We have this timeline of about three months. What do you think about learning and shipping the Android app at that time?” And I think my response was something along the lines of, “I don’t think you’re asking me to volunteer. I think I’m being volun-told, here.” He shrugged and we got on with it and it was a hectic project.

I was learning and he was learning, and we were trying to ship it very quickly. But it was a very successful first launch of Zagat. The clients were happy.

Once I picked up Android there, with that first app, I did a couple more at that small company. The main contractor who hired us for Zagat reached out to me and offered me a job to work for them full time at their company Handmark. I was in Dallas then but had been taking to heart the idea of moving to San Francisco, California. I’d been doing Android for three years at that point—the tooling was still awful, it was still Eclipse and very slow, no dependency management, etc. They were not fun times. So I started reaching out to companies in the Bay Area.

I was hired by Evernote and relocated out to the Bay area. That was my first real Silicon Valley experience, seeing that startup grow from right under a hundred people to maybe 400 people before I left. I developed a lot of my technical chops in a way in which I had a lot of other peers that were pushing me that were much more driven than what I had experienced in other areas of the country working.

That also got me introduced to working on development tools. I worked on their single sign-on client and their external APIs. That was an opportunity for me to start doing developer advocacy for the first time and discovered I loved it. I joined Twitter for a few years. The tooling kept improving, and Android finally started to become something that our iOS peers didn’t make fun of all the time. We started to see a lot of maturity in the tooling. After about three years, I moved on to Uber, continuing to do developer tooling and external advocacy. I started doing external API work—things like deep links and single sign-on and our API usage, speaking at conferences and doing open source. Eventually, I moved on to lead our mobile platform team and spent some time managing them as well.

So it’s been an interesting journey. I’ve seen Android mature a lot over the last 10 years since I’ve been working on it. It started as a very painful toolchain. But a lot of people worked on it just because of the idealism of an open-source mobile experience, as well as a very limited market size at that point, and it has become a booming mature developer ecosystem at scale, and we see a much better developer experience for our Android engineers than for our iOS engineers.

What considerations would you offer to a developer who is thinking of making a move to Silicon Valley?

I think it’s a personal decision for everybody. But Silicon Valley is still a unique place with this incredible amount of opportunity and energy. And some other great areas of the world have a big tech field, but it still doesn’t compare to what you will see here. It is not for the faint of heart. When I was living outside of Silicon Valley, I was a tech enthusiast and I consumed the tech news and I always felt like an outsider reading about it or hearing about it or whom you know is impacted by it.

It wasn’t until I was living here and my friends became the thought leaders that you regularly listen to talks by and read books by. Very quickly I started to feel like, oh, I am contributing to this community. I didn’t feel like that was something that I could have bridged the gap between before I was here and I had the incredible support network that was pushing me in that direction as well.

It’s not a cheap place to live, so there are sacrifices to be made, especially in your first year or two. A lot of people move out here and they say, well, I’ve done the math on what I can get as a salary out there, and it doesn’t financially make sense. I would say that’s often true for the first year or two that people live here, but the opportunity and the network that you build as well as the eventual equity that is often much more competitive out here often offsets that in the long run. That’s something that a lot of people should consider when you’re coming out here, not to compare your first year of work to the standard in Silicon Valley.

Some argue that one solution to this problem is remote work. What are your thoughts on this?

I am a huge proponent of remote work. While I am a big believer in living in San Francisco and the Bay Area, and I did mention there are many other great places for opportunities as well—Seattle, New York, Denver, all have very booming tech scenes. Something to consider, when you start looking at remote work, is if a company hasn’t designed their culture around that from the beginning, it can be pretty frustrating for all the parties involved—things like if the meetings are remote-friendly or water cooler chat is done over Slack. At the first company I worked in, we were all remote, and it was a great experience. We felt a lot of camaraderie. We felt a lot of collaboration. A lot of alignment.

Since then, I’ve worked at companies that had various perspectives on remote workers. The more common Silicon Valley perspective is hesitant about remote work. The preference is for people to work together. Then if someone has a lot of leverage, they can negotiate to be in a remote role. I see the trend moving in that direction, but it’s starting in the smaller companies first. I’ve seen several friends who have started startups and they have a much greater talent to pool from so they start with remote only. They don’t have to worry about the cost of an office as well. So it’s a great idea.

What would be your recommendation for a company that wants to go remote?

Starting early is much better for the culture, otherwise, you’re going to end up with a lot of teams that try to shift; a company may say they are going to hire one remote person and that one remote person then feels very isolated because the team continues to have the chats in person, just casually. I just turn to my neighbor at my desk and we talk about something for a while. Maybe at the end of that conversation, I post a one-line status update in the group for that remote worker to follow along. But that’s not the same experience. So designing inclusive communication very early is necessary.

Second, it’s much more difficult to have remote higher-level management folks. So often, I’ve seen that roles that allow for more independent work are sometimes more remote-friendly—engineers, designers, etc. Then, when you start looking at management, directors, and founders, having them be co-located, working with teams, is more common. Co-location allows that in-person collaboration that’s needed to drive the strategy and the vision of the company, but it does potentially isolate those remote individual contributors. It also, in many ways, limits the career growth of those individuals because, to advance the career ladder as an engineer, you hit a point in which, even if you’re not managing folks, you need to broaden your scope and use other people to broaden your impact. So one common complaint that I’ve heard from long-term remote individuals is feeling limited in career growth because it can be difficult once it’s time to move past these areas of technical collaboration to strategic collaboration.

You’ve mentioned the career ladder. You’ve been a person that has been working as an engineer, later on, you’ve been a lead engineer and you’ve also been managing other engineers at Uber. How easy is the transition between those positions? What recommendations would you give to other engineers looking to manage others?

I spent a lot of years in different tech lead roles, leading teams, mentoring folks, and wanted to build out some experience managing and helping folks grow in their career directly, and being accountable for that. So I spent a little over a year in a role at Uber called a tech lead manager. The tech lead manager role is available at some of the bigger Silicon Valley companies. But it’s not a full engineering manager. So we have three roles in the tech ladder. We have the individual contributor, we have the engineering manager and we have the tech lead manager.

The tech lead manager differs from an engineering manager in that they should have a much smaller team, ideally three to five people, and they are still responsible to be technical, to contribute code and design reviews and architecture reviews and have those technical conversations.

But they are also managing folks and responsible for the career growth of those people. So that’s the role that I stepped into. As a former tech lead and as a mentor to many folks, that seems like a pretty natural career progression. There was a lot to learn as an engineer, the engineering manager would tell you. I read a lot of books. Fortunately, I had a great team of folks that I was taking over, where I had some previous interactions with them. There was already that trust that had been built. I spent the year honing the management side of it. Now I ended up stepping out of the tech lead manager role back to just pure engineering, more of a tech lead role. I did that with a lot of deliberation and some hesitation. But I felt like it was the best path forward for the team and the best path forward for my well being in the short term.

Usually, I don’t think a tech lead is a the right role for managing teams. It’s better to split the role to two different people. That allows someone to avoid context switching and focus on what’s important to grow the team in two completely different directions. I needed to decide between committing fully to being an engineering manager, stepping away from the technical side or stepping back into a tech lead and engineering role and giving up the management. And based on what drives me, where my interests lie, I committed to stepping back into an engineering role and letting the team be managed by an experienced manager who could take on a lot more folks than I was able to as a tech lead manager, and really grow the team to what’s needed for the amount of responsibility that we had.

For the long-term career of a developer, is it compulsory to move into the management ladder?

I think that is a stereotype. I think that, at many companies, it’s true. I’ve been very fortunate to see a lot of the top tech companies that I’ve worked for have very defined career ladders for both and define it deliberately as two different skill sets. I’m very glad that I built the skill sets of being a manager, and I will very likely manage folks again at some point in the future, but I don’t see that as a requirement to progress my career, nor do I see it as a requirement for most folks at these big companies.

I can continue to impact strategically on a large scale and have those conversations that I was empowered to have as an engineering manager, as a tech lead, as a high-level individual contributor. I think a lot of people don’t do that, by default, but that’s often there and just is kind of a thing that needs to be taken. And my experience as an engineering manager, the connections that were built there, the skills that were learned, will be very valuable in me being a regular engineer again, in stepping into those conversations and having a position of authority in understanding what I can be impacting.

So I see a great path to grow past the stereotypical aging-out range, 35 or 40, as an engineer, but I think the experience a person brings is most valuable in the scope they can impact. Higher-level engineers aren’t just programming; they are spending a lot more time organizationally impacting. They are doing larger architecture. They are getting folks aligned on the technical strategy of what the company should be doing. They are establishing new processes. They are reviewing a lot of what is coming out from the lower level engineers. Those require a lot of experience in a position of wisdom and that’s where you see a lot of older engineers, naturally, fall into this. Will every engineer want to stay on the engineering track? No; a lot of folks want to build that experience. They want to build their own little empire. They want to hire out a group. They want to become a director. They want to become a CTO or something like that. But I don’t think that’s necessary anymore.

We’re talking about an experienced manager and leaders. How do you define a good leader?

I think that a good leader spends most of their time empowering their folks to grow and become self-managed. I’ve seen great leaders and I’ve seen bad leaders. Great leaders recognize the strengths of the folks and they try to give them opportunity to take advantage of those strengths and manage themselves. When they recognize the weaknesses, they try to give an opportunity that will grow that person past their weakness.

I’ve seen way too many bad leaders micromanage and not adjust their management technique to what each person needs, and they would talk a lot more than they listen. I would think, especially as a manager, you need to be listening about 80% of the time. Bad leaders are blind to the empathy that a leader should be demonstrating and not demonstrating that servant-leader mentality that needs to be had.

Those all create bad team dynamics to work on. I think as a crux of that, a lot of leaders, a lot of managers, are so focused on building their own career, that they just want to empire build. They want to take on new projects. They just want to set up new folks on their team to become managers, so they can have managers reporting to them, even if it doesn’t necessarily make sense for that person. They are just doing what they can to aggressively move themselves up, and I think that that’s an anti-pattern that’s detrimental to teams. Your leader needs to understand what the team needs and what the person can do to impact that.

“It’s critical to your growth to have a very good mentor to give you advice, push you in the right direction, set up accountability and give you the feedback that you need.”

Leadership is closely tied to mentorship. What are your thoughts on mentorship in our community?

The thing about a mentor relationship is it’s volunteer time from both people, and the time of someone whom you would want mentoring you is extremely valuable. So, while some companies have mentorship programs and people can get involved with them, and they are very official, I’ve found that your career growth is your responsibility. Let’s start with that. That you will have managers and you will have mentors and you will have senior engineers to try to push on you and to try to help you but at the end of the day, you are an adult with a career and your growth is your responsibility.

So recognizing this, it’s critical to your growth to have a very good mentor to give you advice, push you in the right direction, set up accountability and give you the feedback that you need. But if we follow the idea that your career is your responsibility, it’s also your responsibility to drive finding that mentor. I think it’s especially important for a junior engineer. They need to step out of their comfort zone and they need to find someone and be active in advocating for that person to mentor them. They need to be extremely receptive to that person’s feedback as well. What I found before is that as a mentor, your time is valuable. If this person isn’t acting on your feedback and adjusting and making you feel like the advice that you’re giving is being utilized, then you might not be interested in continuing that relationship.

We’ve touched on several trends, here—remote work, career growth, mentorship. Are there any other trends you think are problematic and what would be your solution?

One thing that I’ve noticed in the last few years in the mobile space is a lot of the big companies focusing on creating huge apps with many teams working and creating features for those apps. The apps get quite bloated; you see this in everything from Google to Facebook to Uber. Once we started pushing on further app adoption in the emerging markets, the biggest constraints that came up were lower powered-devices and lower throughput networks—just a lot of constraints where these large-featured apps were considered problematic. The apps were too big and people can’t have them on their device, can’t download them on cellular, or their devices are too slow to run these large bloated apps.

So you started to see this prominent trend of creating light apps that are specific to certain regions. And I think, in spirit, that’s a good idea, recognizing that there are these other markets wherein you do have a large demographic of under-powered devices and trying to account for that. But what we’ve seen is that there’s a demand for light apps in general; it’s not just in those emerging markets. Because once those were available, once you had Facebook Messenger Lite emerged, for example, people in the United States, in Europe and other first-world countries with flagship devices began to prefer the Lite experience. They prefer simple, smaller apps with less bloat, less complex user experiences and fewer features—apps that focus on the core experience.

So, I think this Lite trend, in general, is a little bit problematic, but we should learn from that and try to move back to the core of products with the idea of simplification and creating lighter user experiences.

For companies that would like to move toward simplification, what would you recommend?

A prioritization of the company on the Lite perspective across their apps. Google, for example, released dynamic-feature loading for app bundles recently; I think that’s a really good start. It takes quite a bit of internal work often to rearchitect and design your app in such a way that different chunks of it could be downloaded over-the-wire dynamically.

I’ve been a big fan of progressive web apps; for example, the Twitter mobile web experience is fantastic. Chrome’s API and other general web APIs are getting better in areas like storage in the browser, rich notifications and more. There are several apps that I would be perfectly happy using a progressive web app, and I have been one of the biggest proponents of native performance best user experience, etc. I’m often the first one grilling React Native or some of the other cross-platform tools.

But I’ve seen some very lightweight and performant progressive web apps, and I think that would be a much more adaptable place for a lot of these companies to start with. One reason for this adoption is size constraints companies run into. iOS users are often throttled by the amount of bandwidth that they pay for per month, for example; they still have limited size on disk and they care about the performance in their app. Apple has certain size constraints that I’ve seen companies run into—their over-the air-limit for an app, for example. The over-the-air update limit for an app was 50 megs, then bumped to a hundred, and now it’s at 150. But several apps ran up against that size limitation and it became a huge problem.

At Uber, our rider app started getting very, very close to that, and it became a code red at the company with people trying to investigate how to trim off the size from the app so that we could continue downloading over-the-air and not require WiFi. Fortunately, Apple bumped the limit to 150 because some other companies were dealing with that at the same time. And things like bundling Swift just make iOS apps larger in general. But we’ve had a number of our very senior iOS engineers now take up the mantle of caring about the binary size, performance, etc.

And I think the progressive web app and mobile web, in general, can also solve part of that iOS problem as well. If you’re doing something like dynamic feature loading or something that’s very Android-specific, for example, in a company in which you’re developing products across all the platforms, I’ve seen that it often becomes difficult to sell prioritization of network that is Android-specific. You go to a product manager and say, “Hey, we want to build up this dynamic feature loading for Android,” and they say, “Great, how does that compare to these other features that we could be building that are in both iOS and Android?”

So doing something like the progressive web apps, when it makes sense, allows you to target both products.

And then once you’ve seen your market proof out, you’ve seen the metrics that you want, moving into the full Native experience when it’s needed, is a great way to do that.

Is there something in your career that you have learned the hard way that you wish you would have known when you started in software development?

That a management role that requires a lot of technical contributions is often not the right role for a team. I think hiring a manager is hard, and often companies try to allow that role to exist as a way to fill a higher need because they have engineers who don’t want to fully leave the technical track.

But, with some exceptions, I think that’s the wrong role for most teams, and having a pure engineering manager and separate technical leaders that are solely responsible for those avenues of growth for the team is a much healthier position to be in and that’s something that I learned by going through that for a year.

In terms of hiring, there is a lot of controversy about whether whiteboarding is an effective way to hire talent. How do we hire the right people for these roles?

That’s a really hard question. I don’t think there is a silver bullet, here. I think flexibility is required. Some folks thrive in an interview style, like a whiteboard style interview, who are extroverted. They are comfortable sharing their thoughts, speaking out loud, and they are very clear communicators. Those are skills that are important to understand when you’re hiring a person.

But it also can exclude folks who are shyer, that take more time to warm up or are just very nervous in a high-pressure situation. So if you were to give homework or a project instead, it might empower that person who is shyer, who can work on their own and then submit it. That could be very valuable, but a lot of folks don’t have time to do the homework; if they are working on homework, that’s many hours out of their day, too. Not everyone has the luxury of that time. It’s kind of a point of privilege that you can take out time in your evening or time off work to study. Imagine a single mother who works all day, comes home and takes care of her family is trying to change her engineering job; she has very little time to study data structures and algorithms, and to do homework, right?

So having flexibility and empathy in the interviewing process is going to take us a lot further where we can understand the constraints of a candidate and be adaptable to them. For someone who discusses their discomfort with the interview process, leaning more on the data points coming from a homework assignment is probably a great start. For someone who doesn’t have the time to do the homework, figuring out how to get that data out of an on-site interview is valuable.

I think even when it comes to on-site interviews, there is quite a variety in how they are done. You have everything from purely whiteboarding to coding challenges or pair programming on-site. Candidates might use the whiteboard to diagram something but then hop onto a computer for implementation of the code. I think that having the flexibility and trying to reflect real-world working constraints is going to take us in a better direction in hiring.

At the end of the day, we’re trying to get data about the interviewee, right? You want to have enough data that the candidate and your team are going to be good colleagues and collaborate well. You want to know that who you hire can be trusted to produce and be accountable for what they need to be. With that as the end goal, there are a lot of different ways we can take the interview process, and they need to account for the variability in the human condition.

You’ve been doing Android and other industry advocacy. How did you get involved in this?

When I was learning Android, I remember watching speaker videos of folks I looked up to.

But I also thought it was something I could never do—be at a Google I/O event, talking to a large crowd, explaining very detailed topics. I was at this tiny company in Dallas at the time.

Once I moved out to Silicon Valley and I started building my confidence, I voiced to a friend who was our developer advocate that it terrified me but it would be amazing if I could do public speaking one day. He pushed on me hard to commit to a talk. He said, “Okay, that terrifies you. The best way to get over that is to do it.” And I took that advice, and I ran with it. There was one company event that we were hosting at our conference, and there was an upcoming joint conference in London, and I submitted talks to both. It was my first time speaking publicly and giving a tech talk.

I remember preparing a ton and being terrified. Public speaking is unique. A lot of people don’t like public speaking. I was one of those people who felt like a deer in the headlights. But I prepped a lot, and I got up there for the first event, then the second event, and once I started getting into the content, it started flowing. By the end of it, I was feeling good and I had a huge confidence boost as well. So, with that, I started submitting more papers. Before I knew it, I was giving regular talks every year. Those folks whom I had originally looked up to in those videos when I was starting to learn Android in 2009 were now friends of mine whom I was spending time with casually and hanging out with at conferences. We were traveling together.

It was this moment of reflection, where I looked back at myself and I said, “Five years ago, you would never have thought that you were doing what you’re doing now.” So, really what got me involved was my fear of getting involved. It was a growth area for me, and by pushing on that growth area and fully committing to that I was able to create some velocity.

The second aspect of that, though, is that I care about working with other developers. So a lot of the tooling I am working on is developer tooling. I get to work with customers who are my peers, who give me great feedback, and who help me improve my craft. It’s different than consumer products. So this idea of engaging with them in person, making personal relationships and meeting new folks has become an incredible draw, which reinforces the velocity that I wanted to have. I’ve never actually worked full time as a developer advocate, yet I’ve been in conversation with mentors of mine who are very, very established tech people who have introduced me as one of the best developer advocates they know—even knowing that I’ve never done that full time.

This has been a huge compliment to me, and it’s helped me recognize that maybe, at some point, I do push fully into the developer side of things. A lot of this has been influenced by my wanting to push past this personal growth area, as well as finding love for working with other engineers.

What advice would you give to someone interested in public speaking?

When I started, I kind of followed a very stereotypical recommendation, which was to have a little bit of alcohol before you speak. Get a little bit of liquid confidence. So for the first few years that I spoke, I would often have a shot or a glass of beer right before I went up. Just enough to cool the nerves. What I found is that you will build this confidence on your own and that, at some point, being in front of people will be very comfortable, and you can be your natural self. But in the beginning, it’s okay to help bootstrap yourself. So account for the fear and push through that, understanding that it will eventually be comfortable.

Do you think that public speaking is for everybody? Is it something every developer should try to do?

It’s a skill to develop. I don’t think that people are a natural fit one way or the other. I think some people are more natural fits, but I don’t think it’s mutually exclusive. It is a healthy skill to develop because it pushes on your ability to communicate ideas, to grow as an engineer, and to be able to engage and empathize with other people. I know most engineers won’t click on those set of skills, and they will keep things very technical. But one of the biggest growth areas from moving from just a high-performing senior engineer to a much higher-level staff or principal is being able to step out of working purely in your technical domain, purely on your own, and start to empathize and have those soft skills to work with other folks. I think that external advocacy and external presentations are a great way to help build some of those skills.

Folks who went through a traditional computer science degree at a university did get some communication classes or humanities classes in other “softer” areas outside of computer science. We engineers have used bad communication as a crutch to not develop professionally because we put our value into other areas. I think that’s toxic to our industry. If you were working in other non-technical roles, and if you were not able to work well with others, you’d be out. You’d either have to fix that or be out.

Yet, as engineers, we’ve had this stereotype of being a bad communicator because we are engineers. We just don’t understand people. And I don’t think that’s true. I think that a lot of people embrace that stereotype as a reason not to grow those skills because they don’t have to. But that’s a problem for our industry. That’s not a natural state.

What insight do you gather from other resources? Are you more into books or podcasts?

I’m a really big fan of audiobooks. I found that I have very limited time as it is and I prefer the substance matter of a full book with a longer narrative. I can dive in and explore a topic. I can fit audiobooks a lot more easily into my life; I can listen to those while commuting, at the gym, etc. I’ve been pushing on increasing the speed for listening to those slowly over time so, at this point, it’s become a very efficient way to absorb that information. I only reference back to hardcopy books when necessary for diagrams or specific things that are not capturable in an audiobook.

What are some books that have had a lasting impact on you as a developer?

A book that’s helped me frame how I communicate is Marshall Rosenberg’s Nonviolent Communication. It’s a book about the language of communication and how to empathetically debate, negotiate and understand another person’s point. It creates a framework for considering how you’re interpreted and how to interpret someone else in the professional workplace and personal relationships with resounding effects.

Another book that probably had the most pronounced personal change for me was Mark Manson’s The Subtle Art of Not Giving a F-ck. It wasn’t necessarily the book itself that had this paradigm shift for me. He originally wrote a blog post about this a few years ago. And I read it at a time in my life when I had been over-indexing on idealism and caring about things being done the right way. I was spreading myself too thin and fighting way too many battles. And it was taking a really strong toll on my being and my health and I was at a place where I needed to make a major shift.

Reading this post and understanding this model of prioritizing the number of f-cks that you give was helpful—treat them as a limited currency. I started thinking about my life in that way, where I had a limited amount of things that I can care about. That was a turning point for me to have a bigger focus on sustainability, wellness, and health. Not only did that affect me in my personal life but it carried over into professional growth as well. I gained the ability to deal with conflict at work and understand the amount of skin that I had in the game. I was willing to be a lot more reflective and pause to be less emotionally tied to those conversations. With that comes much more measured persona, much more emotional detachment for conflict and things like that. And that’s just helped me grow a lot.

On the technical side, Uncle Bob’s Clean Code. I read this years ago and it just helped me start thinking about larger systems and the impact of tech debt, as well as how properly defined architecture allows for scalability, showing the ramifications of bad architecture.

The other is Effective Java by Joshua Bloch. I think that’s one that a lot of Java developers will refer back to as the Bible of Java development. It has some of the normal problems with technical books of having content not reflected in a newer version of Java. However, there’s a lot of very solid fundamentals that are communicated across many object-oriented languages. Having worked in many big companies where we’re trying to understand how to speak in a common language and get aligned, I found that the principles that are communicated in that really go a long way in helping people get on the same page and get aligned in the sort of technical excellence that would be expected in a larger company.

In addition to your other industry contributions, you’re also an angel investor. What does that mean and how can one become a good investor?

There’s quite a variety in how people do angel investing—everything from going in with a micro VC group to individual investments in companies. My background, so far, with angel investing started when I was at Twitter, and I was put in contact with a few folks who were putting together a micro VC fund. That grew pretty slowly with members; I think we’re up to 20 or so members. The name of that group is Specialized Type; what we do is invest alongside the big venture capitalists, joining different funding rounds with these companies.

So we go in alongside them and invest a very small amount, and our value-add is that the entire group of investors comes from a deeply technical background with domain expertise in one area that the company would like to use as an advisor. We have folks who have security expertise, machine learning expertise, and scaling storage expertise. My value adds to that group has always been the mobile experience, Android, hiring, and open source. So, over the last three years, we’ve added several companies to our portfolio, and I work with them off and on; the time varies month by month.

I work with the founders and the senior leadership of those companies to help them in those specific areas and in what their needs are. Now it’s been really interesting because it’s helped grow my career in a way that I didn’t originally expect. This has been a nice way for me to take a slow ramp into the logisticals of investment; they have an incredible network to utilize to learn additional things about the investment process.

From that experience, I’ve then been able to take my knowledge and start to work with individual companies in which I’ll personally invest and then come onboard to help advise them to work through the problems that they’re having at an early stage. It’s been very interesting, stepping outside of the normal perspective of engineering to understand the bigger company problems that these companies are dealing with, and to use the technical expertise that I bring to help them solve those issues.

What are the main benefits that getting into angel investing can bring into your life?

Ideally, financial if the investment works out. The entire idea of getting in on these companies and helping them grow is a return. But if you get past that, then it does help, with an incredible amount of networking potential, growing a lot personally and helping to grow others in your network as well.

Ty’s Recommendations

• Nonviolent Communication: A Language of Life | Marshall B. Rosenberg, Ph.D.
• The Subtle Art of Not Giving a F-ck: A Counterintuitive Approach to Living a Good Life | Mark Manson
• Clean Code: A Handbook of Agile Software Craftsmanship | Robert C. Martin