Why I left Josh.ai -- A short self interview
July 2, 2017
First, let’s go over a quick timeline of how I spent my time at Josh.ai
I joined in June 2015 as an intern working full time, up until August 2015 when I had to go back to school. During this time, I worked with Python in a production setting for the very first time. I learned about the Flask framework, and connected that to a PostgreSQL database. I’d used SQL databases before, but I had never used PostgreSQL specifically. All of this was put on Heroku and all of my work went into this project.
When the semester came about, up until January of 2016, I continued on Flask/full-stack development but I was doing it at reduced hours. At this point most of my work involved developing the personality of our chat bot system using a domain specific language which was built. I would also build internal tools to help us with reporting and automation of other processes.
In February of 2016, I was repurposed to help work on our Android application. At the time, we had a full time iOS developer, but the Android developer was a part time contractor. So I was working with him in order to get more of the Android work caught up and done. This lasted until May of 2016, aka the end of the semester and when I finished at school.
Fast forward to school finishing in the middle of May of 2016 and I become the only full time Android developer. This is where things start to really rocket. I started listening to Fragmented, and Android Developers Backstage which are both incredible podcasts. I subscribed to Caster.io which is an incredible learning resource for Android development. I watched what felt like countless conference talks on all sorts of Android development topics. I picked up RxJava and learned about reactive programming. I learned about compile time annotation processing. I started writing automated tests with JUnit and UI tests with Espresso. I had continuous integration and continuous deployment setup through BuddyBuild and new versions of the app were being distributed through a service called Beta. I learned about concepts of dependency injection. I had to figure out how to log things while they were out in production. I didn’t have the console for every person’s phone, so I used Crashlytics. This period really gave me a new found respect for developers who work on developer tools. You guys really make my life easier and more productive. I was programming full time for real, for the first time in my life. Internships that I had done before were going to end, so the projects tended to be small. This time, there was no end in sight. I just had to keep on writing code every single day. It was amazing. I was learning so much, I could hardly contain myself.
Then in February of 2017, I may have made a mistake. It’s hard to tell. I stopped learning anything related to Android and it became apparent to me that all I was doing at this point was implementing the next set of features. It stopped being fun. Through coincidence, one of my co-workers and I ended up swapping roles. He would work on Android and I would work on our C++ codebase. I have always been a fan of C++ and how explicit you have to be with your code sometimes. I know some people think it’s verbose but I enjoyed it. I felt like you had to understand a lot more before you could be really effective with the language. My day to day job was now having to control devices over the local network. It started out to be really great because I was totally out of my element. The codebase was older and had multiple developers contributing to it. When I worked on the Android app, it was largely just myself that I had to deal with. Simply put, the same thing happened that happened with the Android app. I quickly got the hang of things, and C++ is a much older language that doesn’t have all the tooling that Java has. It felt like there wasn’t as much for me to learn and it grew to become stale very quickly. It stopped being fun, and then circumstances became such that I had a good opportunity to join another company where they use a lot of modern technologies that I would love to learn. For my own growth, which I’ll go into more detail below, I decided to take the new job.
I will always be thankful for the time I spent at Josh.ai, and how much I learned there. I just know that for right now, I need to be somewhere else to fulfill what I want.
And with that being said, I’ve listened to a lot of podcast interviews and fireside chats that I make a decent interviewer. This is all free form. I don’t know what questions I’m going to ask myself as I write this.
What are your goals as a programmer? To be honest, I’m not really sure what my specific goals are. All I know is that I want to continue improving as a programmer.
What does it mean for you to improve as a programmer? How do you measure that? I think measuring it is incredibly difficult. It’s subjective, so I can really only talk about how I measure it. I measure the abilities of a programmer by how effective and productive they can be while solving problems that have entirely unknowable answers. One of the things that I greatly value is how capable are you with using the tools in your environment. For example, I prefer to use vim as my text editor. I want to be explicit and say that I’m not trying to say that using vim makes me better, but I’m always continuing to learn more about using vim to help me be more productive with my work. I’m always learning new shortcuts or potentially plugins that can help me. Another example is using git for your version control. Git has powerful features like partial commits which help make your version history very explicit in the parts of code that are related. Many times people just learn the bare minimum with these tools. I think that spending time with these types of tools to become proficient in that environment help to make you a better programmer. If you use an IDE, learn about the shortcuts that are in your IDE. Learn about plugins that you could integrate to help improve your development speed. I’ve always held the belief that my typing and my tools should not be the bottleneck of my development. I should learn and understand these tools so that I can use them swiftly and then get back to my real work.
Then there’s domain expertise which I think is deceptive. We shouldn’t be measuring domain expertise, but we should be focused on the ability to transition from one domain to another. Anecdotally, it’s easier for me to learn something if I already know something very similar and just need to understand the differences. For example, I learned C# as my first programming language. After learning C#, learning Java was incredibly easy. A good programmer should be able to identify which questions to ask to understand the differences between domains. I shouldn’t need to have written Java for 3 years just to get a job with that requirement. Maybe I’ve been writing C# for 3 years, which should count as the same experience, as long as I focused on learning what matters in those 3 years. Another problem with the depth of experience, or measuring in years of experience, is that not all people spend their time the same way. I make an explicit effort to make my 1 year of experience more valuable and effective than what I perceive to be the average. I spend a large amount of time reading on different technologies, even if I don’t use them. Getting the different view points is valuable because they give me different ways to think about my current problems. It helps me learn practices in other domains which also helps me transition between them easily if I ever need to.
The last big thing about improving as a programmer is improving my ability to breakdown large tasks into smaller, more manageable ones. This is where I’m the weakest and need to focus on the most right now. If you give me a large problem, for example, “Build a search engine”, I don’t really have much idea for how to get started. The ways that I breakdown a problem with that all leave me with tasks that are too large to really tackle. The process of breaking down problems should be recursive, but I can’t go very deeply down the three without losing sight of whatever original problem I was trying to solve. The solutions I come up with are also not very good at taking into account the other parts of the system. I’m only looking at one path down the recursive tree at a time.
How are you going to fix your weakness? I haven’t found a method that feels like a sure fire way to improve, but right now my strategy is to work on projects entirely alone, from start to finish. I know there’s a lot of value in working on a team, but I get that from work. If I need to work an a project on my own, and those projects slowly increase in size, then my ability to think about entire projects at once should slowly expand.