What happened in my 2017, and refocusing for 2018
December 24, 2017
First and foremost, I’ve deleted all my blog posts that came before this one. I did this because after re-reading most of my blog posts, it was clear to me that I didn’t really understand what I wanted to get out of this blog. I had posts that were kind of all over the place. Some posts were absolutely written just for the sake of writing them which makes absolutely no sense because I don’t advertise or share my blog anywhere. I put the link to my website into several profiles, but I never really expect anyone to read anything on here, yet I was forcefully writing. In the new year, I’m going to be changing that. For the people who know me personally, they know that I’m more of a story teller. I tried to write my blog posts in a reference style like the blog posts by Dan Luu, but it just didn’t come out right. Instead what I want to do is tell stories that are all built from my experiences as a software engineer. Stories of triumph, stories of mistakes, etc. With all that being said, it’s time for me to tell the story of 2017.
At the beginning of 2017, I was a software engineer at Josh.ai. I was about 6 months out after leaving school with only one class left for me to get a college degree. This also means that I was about 6 months in to my full time career as a software engineer. I’ve been programming since I was in middle school, but it’s definitely different to be a full time software engineer, as opposed to a hobbyist one. My time at Josh.ai has given me a lot of insight to what kind of software engineer I want to become. When I first started full time, I was working on our Android app. I was also one of the DevOps/SysAdmin-adjacent engineers. We used Heroku for our platform, which meant there was less to do, but I was more interested in the cloud world than some of my peers. My last major function was that I did the packaging and shipping for the physical parts of our product. It was a small company, so there was a lot of work to go around.
It was around this time that I was approached by a technical recruiter from Google. I have a love hate relationship with the idea of working at Google. I go through phases of really wanting to do it. My rationale is that Google is the place for me to become the best version of myself. But then I think that even though Google is said to be against most corporate red tape, there are still the politics of joining a larger company. Not all of the work there is glamorous, and the variations in between teams and their abilities was a bit worrysome. At the time, my work was becoming a little stale, and tensions in the office were high which I think is normal for an early stage startup. Regardless, I obliged the recruiter and we began the process of interviewing at Google.
Years earlier, I was infatuated with the idea of working at Google. More so than I have been since. Looking back, it was insufferable. I would talk about all of the perks that I read about online. I would tell everyone about them, and that’s all I was interested in talking about. I could feel this coming back but I did what I could to mitigate it. Nobody wanted to hear me babble about how wonderful the free food and tech stops are. On the bright side, all the research I had done, had netted me a lot of information and references for preparing for an interview there. I started reviewing some of those materials to help prepare me. I was doing practice coding problems in most of my waking hours, to the chagrin of my (at the time) fiance. I scheduled as many practice interviews as I could on Pramp and Interviewing.io. I even reached out to a second degree contact who worked at Google. I had him practice interview me. The phone interview went well. I just had to write a binary search in Google Docs which was a strange coding environment, but the interviewer laughed along with me when he could clearly see my muscle memory inserting vim bindings into the document. In between the phone interview and the on site interview, my recruiter invited me to join for a lunch session at the Google campus in Boulder, CO to talk to some experienced interviewers and to learn more about how the interviews are supposed to go. I eagerly attended. It was the first time that I could get interview information directly from the source and not from some random post I found on Quora.
Eventually, the day came for me to interview. I drove to Boulder and got there almost half an hour early. I was calm most of the way, but once I pulled in and found a parking spot, it’s when the nerves started to hit. Eventually, I got out of my car and went to the front desk to get my temporary badge. There were two other people in the lobby waiting for their recruiters to pick them up and start their days. The interviews themselves weren’t anything particularly difficult. My first question involved keeping a running count of API requests, my second interview was a graph problem, my third interview involved designing an LRU cache, fourth interview was another graph problem, and my last interview had to do with string manipulation. I left the building thinking that I definitely didn’t bomb the interviews, but I wasn’t confident enough to know that I had gotten the job. A week or two later, my recruiter let me know that they would not be moving forward with my interview packet, and I tried not to be too sad. The turmoil at my current job had softened which helped ease the pain of the rejection. I never did find out if the other two that were waiting in the lobby with me had gotten job offers.
Over the next few months, I discovered that I actually had a lot of fun being an interviewee. At the time, there was nothing specific at my job that made me want to interview elsewhere. I actually just enjoyed the process. I think most people only really interview when they’re looking to leave a job. On top of that, you only interview at a couple of companies before you pick one to join. This means that the average software engineer might only ever interview 10 to 20 times in their entire life. Most people that I know hate the whole process. They feel like they’re being judged and they don’t like it. I sought to go out and become as comfortable as humanly possible with the whole process. I interviewed with a lot of companies, and I applied to even more jobs. I saw all kinds of offices, wrote all kinds of coding challenges, met all kinds of people, and was exposed to all kinds of interviewing styles. One thing is certain though when it comes to interviewing software engineers. It’s very hard. You’re trying to figure out if you want to pay a person, but you’ve only ever spent a few hours with the person. It’s hard to translate that into whether or not you’d be cool with having them around for 40+ hours a week.
Soon it was July. My affair with interviewing was starting to come to a close. The fun was fading and we were hiring more where I was working. We had hired a product manager who was awesome. Everything was ramping up because we had a trade show that we wanted to really impress at, and that took place in Q3. It was time to focus again on work. By this point, I had traded working on the Android app with one of my peers. I was now working on our flagship code base. It was large and messy. It had all kinds of artifacts of startup culture. Many features were experiments that never panned out and were never removed. There were many comments labeling code as temporary and that we’d get back to it. Unfortunately, the high velocity that we had early on in the code base, had accrued us a significant amount of technical debt. It was becoming harder and harder to introduce new features and every one that we wrote was cementing the clumsy code that it sat on top of. You couldn’t re-write anything to improve it, because that would mean you need to re-write a bunch of other code that depended on the first code. We didn’t have time for that with the trade show coming up. It was frustrating. One of my coworkers had announced that he was leaving and I was to inherit the portion of code that he worked on over the last two years. At the same time, I was working on a device integration with a device that had a nightmare of an API. It was slow and unreliable. I had stopped applying to jobs. It was time to get really zoned in.
I used to frequent a local Slack, dedicated to the developer community in Denver. A company that I had spoken to before had posted saying that they were looking to hire someone. I had talked to them in November of 2016, and after some really poor timing and the free plan of Slack only keeping the last 10,000 messages, our communications fell through. The manager that I was talking to left to go on vacation and in that time, and I had reformatted my computer and never logged back into the Slack channel. I didn’t even think to get some other means of communication with the manager. I assumed that they just weren’t interested. That July, the same guy was posting about wanting to hire someone, and I reached back out to him. It was a bit awkward to start the conversation with how weird things had ended (at least from my perspective). We talked, I did an on site interview with them, and received a job offer. I remember being very conflicted about what to do, but I ended up taking the job with FullContact.
This is where the year started to really take off. I started my new job as a backend engineer at FC, supporting our massive data pipeline that powers our API. I was using all kinds of technology that I hadn’t gotten to use before. Our stack lives on AWS, and we used a flurry of libraries that I hadn’t heard of. It was time for me to kick it into high gear in terms of my consumption of learning materials. I’ve always been a hoarder of learning resources, and I’ve always been really into my self improvement. It’s one of my most closely held values, is that I want to always be improving. When I started, people told me that coming up to speed was like drinking from a fire hose. The tech at FC had been built over 3x the time that Josh.ai existed as a company. At Josh.ai I watched almost everything get built. At FC I was being handed an existing collection of code. It was awesome.
Even though everything I’ve done at FullContact has happened in 2017, some of these stories are still in the process of being unfolded. But, it’s these projects and problems I’m solving that will be the fodder for the stories I start telling in 2018. Thanks to encouragement from my manager, I’ve finished and documented 3 relatively major projects. The projects themselves aren’t anything crazy, but they’ve made it to a level of maturity that I don’t normally bring my side projects to. I look forward to talking about some of them in the future.
I do want to wrap up a little bit with an excerpt from the now deleted review I did of 2016 and what my goals were for 2017:
In 2017, I want to improve my knowledge on several aspects of the programming field. Firstly, I’d like to learn and understand much more about functional programming. I’ve been teased by it with RxJava and bits and pieces of Kotlin. There’s a reason that it’s growing in popularity and I want to understand what the hype is. The second topic I want to learn about is scaling heavily used systems. There’s a reason that products like MapReduce were created, and reasons why Google is able to return a result in fractions of a second, despite indexing trillions of web pages. I watched a few of the talks from @Scale and I’m really fascinated by the topic. Next, I want to deploy the lessons I’ve learned from the master package of The Effective Engineer by Edmond Lau. Many of the lessons covered habits or techniques that I’ve been using for years, but there are several gems in the main book that I think will benefit me greatly. Also in 2017, I want to become more knowledgeable about the state and techniques of web programming. I admit that I’ve held an elitist view over web/frontend programming for far longer than I should have. Technologies like NodeJS, ReactJS, and other languages like Go and Rust have all been on my list of things I want to learn. Along with becoming web-fluent, I’d like to create some web based product that has a non-zero number of regular users. It will be a busy year, but with the completion of school, I have a lot more control over how my time is allocated, and it’s just a matter of being responsible about it. Most of what I learned from this year all happened within 9 months, and a lot of it without having the same level of understanding of my own learning as I have now. I look forward to everything I will rant about in my recap of 2017 after having a full year to build on the knowledge that I’ve compounded to this point.
As for functional programming, I still don’t have any experience with writing in a purely functional language. Our code at FC is all written in a functional style of Java though. Mutations are frowned upon and pure functions are common. This is probably the topic that I learned the least about in this list. The second thing I wanted to learn about is scalable systems and distributed services. Being on the backend at FC has absolutely helped with that. We run a microservices architecture with services capable of handling many thousands of requests per second. We have load balancers galore and I’ve learned a lot about this field, so I’d call that a check. By the way, if you’re interested in learning the concepts of distributed systems, I’d recommend reading Designing Data-Intensive Applications by Martin Kleppmann. The last topic that I really wanted to cover was web programming. I created a free to use job board named ColoradoGeekJobs. It’s slow to load because the frontend and backend are hosted independently on two hobby dynos on Heroku, which means the applications will “sleep” if they haven’t been used recently. The website itself was built with MongoDB, Express, React, and Node (MERN stack). I’d call this goal as accomplished as well. Unfortunately, I didn’t hit the goal of having a non-zero number of regular users. I lightly touched upon learning Go or Rust, neither of which I ended up doing, but since it wasn’t a major goal, I don’t feel that bad.