Welcome back to The Making of a Development Team, where I get to interview my teammates and show what Detroit Labbers are made of. I rounded up 14 fellow Detroit Labbers to talk about what they do, what they love, how they got here, and what makes them tick.
For today’s post, I sat down with Android/iOS developer Stuart Kent. When I first started at Labs in the Beta apprentice class, Stuart was a newer developer, which allowed him to empathize, and coach apprentices through issues that junior developers tend to run into. He is a good luck charm, gives incredibly thoughtful feedback, and an excellent foosball player.
So, Stu, tell me a bit about yourself.
The path to DL started when I went to university to study math when I was still in England. I am English (for those reading). That’s the normal thing to do — go to school in the country where you live. My then-girlfriend, now my wife, decided to attend Cambridge as an American, which is not the norm. We started dating in our first year, and by the end of school, we were still together. Then the both of us came to graduate school at the University of Arizona, despite neither of us liking hot weather. We spent six years in Arizona, both still doing applied math. Applied mathematicians are the normal mathematicians! It’s a lot like the accountants and the actuaries.
After six years, my wife wanted to carry on with her research, while I had a different idea. I found that the length scale of work was way too long for me. You could work on a problem for months or years with minimal results. With mathematical research, because it’s all brand new and cutting edge, the avenues you go down are all based on intuition. You can work six months on something and discover that what you thought was possible is actually not. So it was difficult to stay motivated through that. I knew that whatever I did next, I wanted to solve problems on a more frequent basis even if things were smaller in scope and easier.
When we got to Detroit, my wife started her postdoctoral position, and I started to look around for myself. There were two main career types that interested me: automotive engineering or programming and the new IT scene. I sent applications to both types of companies and got no response from the auto companies due to my lack of an engineering degree. By the way, this is where I see Detroit Labs having a leg up in being able to attract talent. They took a gamble by interviewing and hiring me even though I had no practical experience, and I think it’s worked out pretty well for both me and the company!
What was your dissertation on, and where is it currently framed?
It’s an intersectional problem that touches on electrodynamics and fluid mechanics. It’s a fairly abstract treatment, but the problem that motivated it is physically relevant in many ways: coating medication in very fine covers, extracting fresh water from beneath islands surrounded by salt water, oil extraction from underground. But again, even when you are doing research and it’s going well, the likelihood that any of that work makes it into real world application is minimal.
It’s currently framed over by the coffee.
That’s right, we are so proud! What was it that drew you to development?
I had done enough mathematical programming that I knew it was something I didn’t mind doing. I enjoyed it because I could problem-solve on a frequent basis, instead of longer periods of time, like six months. I always looked forward to doing the coding part because I would get satisfaction. There were still parts of mathematical programming that I was less enthused about but don’t need to do now.
I had had some experience with MATLAB, which is optimized around linear algebra. It’s also procedural, so it is mostly “start at point A and end at point B.” I had also used Mathematica which works with algebraic evaluation. Way back in school, I had projects where I used C. The month or so before applying to Detroit Labs I brushed up on Python.
I took away two main lessons from my PhD: the importance of building up context when problem-solving, and how to work and learn independently. In programming, once you have learned the basic grammar, much more of your mental energy is spent thinking about the bigger picture. I definitely understand why people think of development as a craft, and I love that aspect of it.
So you started here before we instituted our apprentice program. What was that like? Was it like a cowboy on the plains? How did you find your way and succeed?
Macklin Underdown joined three or four months before I did. By the time I arrived he already seemed to know everything. Mackie was my assigned DL buddy, so I ended up working a lot with him, and he understood my pain as he had just gone through the same process. It was a very unstructured beginning. I don’t know what I expected. I was told to follow the standard Detroit Labs Android boot camp. I started out with a Treehouse course that threw you straight into building an app. This app had a crystal ball in it. You would hit a button and it would generate fortunes.
By the third or fourth day, we were going to write custom shake detection. This was way too fast a curve for someone who hadn’t done any Object Oriented programming before, or used Java! (Plus, custom shake detection is really esoteric – I’ve never needed it since!) So I stopped following the boot camp and instead focused on core Java for about a week. After that, I started back up with the official Android docs, which have a much gentler and more practical progression than the Treehouse course did.
When I was hired, the initial goal was that by the beginning of March I would be on an actual client project as a junior developer. After two weeks or so, I started sitting with Bryan Kelly (lone developer on a client project at the time), and I was phased in gradually. The initial boot camp plan that I was on started with learning, then moving to an internal project, and also a hack project. This is where I started to make Landmarked for Android.
Landmarked is an app that gives virtual tours of Detroit, which at the time only existed for iOS. It seemed like a good starter app to play around with because it is heavily map-based, and the client app I had been working on was as well. I split my time between the two, slowly ramping up the time on the client project. I went to an early client meeting with Bryan just before a release, and he was furiously fixing bugs while I had no idea what was going on! After that I was more comfortable skipping client meetings if I thought I would benefit more from using that time to keep learning.
Follow up question, same vein: at what point did you decide that it was time to try learning iOS?
I came off my first client project after a year and three months. I was definitely ready for that, I was so familiar with the code base that I wasn’t learning as much as I thought I could. It was easy maintaining, and then the code base was such a huge size that we couldn’t easily try new technologies. I honestly feel like all of our developers should learn both platforms, I think it’s useful for the company to have that flexibility and is very useful for the individual. Learning one after learning another is not that difficult. Many of the paradigms are the same, just implemented differently.
When I joined my next client team as an iOS developer, I was worried that I was going to slow them down, but it was easy for me to get up and running and be productive in a couple of weeks. Subtle differences popped up in between learning the two. I will say now another year on from then, it’s not really possible to stay completely up to date on both platforms simultaneously, but it’s still nice to be able to look at the code and figure something out without having to ask someone on the other platform. It really is awesome. On one client project, we had a cool spinning animation, and I was able to take a port some of the Android code to iOS to make sure they looked identical.
Do you have any advice for mentees about learning from a senior developer?
The biggest thing is being aware of what you do and don’t know and the extent as to how much. I remember very early on I didn’t understand how click handling worked. I knew it was super important for mobile apps, so I spent a couple of days just writing out in full everything I knew and was learning about them. Deliberate practice is critical. A developer is most dangerous if they think they know something that they actually don’t understand.
Which is your favorite?
I find that I prefer working on Android. The biggest advantage to iOS is being able to work in Swift. The Swift of Android is Kotlin. It doesn’t have the same first-party support but the documentation is good. I’m hoping we can use it on the next client project here.
In all other regards, Android is a less surprising platform. The source code is completely visible. I am not a huge fan of interface construction in iOS, it seems a little too magical at times. But I will say that I would be happy to be assigned to either in the future because I do like both.
I know from experience, and have heard from many others, that you are easily approachable and an incredible mentor (I am humblebragging for you). Is there a specific structure that you have found that is effective?
I would say that there are a few main elements.
To be approachable is to communicate enthusiastically by default. “Do you have time?” “Sure.” vs. “Sure!” It has helped me feel like I am easy to approach. The fact that I started not too long ago is also an advantage, because I still remember what it was like to not understand fundamental concepts like click handling.
I don’t think I am the best at letting people guide themselves, but what I try to do is look to put things in context. So apart from just answering questions, I try to explain things like historical precedent and how I personally knew how to discover that answer.
We can’t talk about clients specifically, but have there been any features of note that really melted your mind?
There was an intense refactor that involved taking apart and reassembling a core app feature. Nothing changed visibly, but I was undoing technical debt that was causing consistency issues. If I was the original author of that code, it might have been easier to modify to achieve what I wanted, but the teardown was effectively essential for me to even understand how everything was meant to work in the first place!
Switching gears, what do you hack on?
I tend to mix it up quite a lot. Sometimes client work, sometimes not. Lately, I’ve been wanting to do a security teardown of an app to learn more about that. Sometimes I write blog posts for my own blogs. Sometimes abstracts for conferences. I don’t have a long-running project of my own at the moment, but I have a backlog of things to work on but haven’t been able to.
I want to make a Chrome port of a Safari plug-in that auto-deletes a branch after you merge it. I would get to learn how to build a Chrome extension and not have to manually delete the branch every time!
Tell me about your open source projects.
I have two main ones, BugShaker and Amplify, both for Android. BugShaker is a tool to make it much easier to collect a bug report: when you shake your device, it prepares an email containing device info and a screenshot ready to send to your dev team. It’s super useful for QA and totally possible to use in production as well. Users/testers can send you a real live production bug. Amplify is a library that subtly encourages and directs user feedback. The original idea was described by a now-defunct company. I rebuilt this idea for Android as an open source project, and it is now used in a few client apps here at Detroit Labs. It’s a good tool for collecting both positive and critical feedback.
LIGHTNING ROUND:
What did you eat for breakfast today?
Chocolate digestives (I was out of cereal). They are cookies. Usually cereal.
What was the last movie you saw?
The new Bourne film in London – I paid an outrageous amount for the ticket.
If you had one item in the zombie apocalypse, what would it be?
Weapon, definitely some kind of weapon.
Best decision you ever made?
My decision to apply here was really good. We are still in the Detroit area two years after my wife’s postdoctoral position ended because of this job.
Best advice you’ve ever gotten
I enjoyed reading Kate Catlin’s blog about advice for your 25-year-old self, you should all check it out!