My First Ten Years; My Next Ten Years

This post was originally published on my previous blog jer-k.github.io

Published on 2019-06-30

I was recently attending DockerCon and Michael Ellison, CEO of Codepath, was giving a talk about the future of Computer Science education. He was telling a story about how he was recently in a room with a large number of CTOs and asked how many of them started programming before the age of 14. He mentioned that around 90% of them raised their hands. I let out an audible chuckle, turned to the person next to me and said “Well time to change careers, looks like I’ll never be a CTO.” While being a CTO isn’t the end all be all of a Software Engineer’s career path, I do believe it is a very desirable outcome. Later on, as I was back at my hotel, I was thinking about when I had started learning to program and it dawned on me that it has been about ten years since the spring quarter of my Freshman year at Oregon State University. I started reminiscing on all I had learned over the past ten years and decided I wanted to write a brief summary of my journey to becoming a Software Engineer and what I hope to accomplish moving forward.

College at Oregon State University (Go Beavs!): 2008-2012#

Let’s rewind back to September 2008, technically I was exposed to some programming during my Freshman fall quarter, but I remember I could copy the Python code straight from the textbook into some program we were using and it just worked; needless to say, I didn’t learn much in that class. During winter quarter we were introduced to Java, my first IDE, Eclipse, and thus began my struggles. I remember even the basics of conditional logic and loops were mystifying to me. Thankfully there was another member of my fraternity who was in his Junior year, also majoring in Computer Science, and he was gracious enough to answer my constant stream of questions. There was actually a point during that quarter where I was sitting in class and reading through the other Engineering majors offered at Oregon State because I was that confident that programming just wasn’t for me. However, there is a happy ending to this story though; I’m not sure when, but I remember there was a project when I had a moment of clarity and everything clicked, programming started to become fun. I continued to learn Java through the end of my freshman year, being able to write more complex programs and beginning to understand the fundamentals of Object-Oriented Programming; then I never wrote another line of Java in my life.

At the start of Sophomore year, I was introduced to C and continued to primarily write C through graduation. Much of that year was spent understanding the fundamentals of a lower level language like dealing with pointers and memory allocation. While it wasn't as fun as building games in Java, it taught me foundational pieces of Computer Science. I fondly remember one assignment in particular, which I had to write during Junior year for our Operating Systems I class. The assignment was to build a C program that drew people, houses, and trees to the terminal in ASCII. I don't exactly remember how this pertained to learning about the Linux OS, other projects had us modifying code in the kernel, but I recall I was completely obsessed with this project. I spent every extra hour of my day in Kelly Engineering Center trying to resolve bugs and figure out why I wasn’t able to render those dang trees! In the end, I didn’t complete the assignment to the full specifications, but I believe that I truly started loving the process that goes into taking specifications, writing a program, and debugging the issues that arise; I was falling in love with software engineering.

Senior year rolled around and I was required to do a senior capstone project, which myself and two classmates decided to create an iPad app. None of us had any experience writing Objective-C or developing iOS apps before, but we looked at it as great opportunity to learn a programming language that could be very applicable in finding a job after graduation. The three of us were paired up with a company, Veeva Systems, who were developing an API to power a Dropbox like solution, which allowed their users to view and sync files to the device for offline use. With API documentation in hand, we set out fumbling through iOS tutorials and beginning to piece together the application. I believe working on this project was my first exposure to Stack Overflow and to this day my highest upvoted Stack Overflow question came from one of our early struggles (Get the extension of a file contained in an NSString)! It was also my first exposure to collaborating on GitHub and I remember we were very annoyed at not being able to merge Pull Requests because we didn't understand how to resolve merge conflicts in .xib files. We actually ended up just zipping up the files and emailing them to each other and then committing the updates straight to master; professional software development at its finest! In the spring 2012 I had completed my course work and attended graduation where Michelle Obama gave our commencement address (her brother was the Men's Basketball Coach at the time). I was ready to begin my career in Software Engineering.

Early Career: 2012 - 2016

Lo and behold, the choice to learn how to create iOS apps ended up being a good one as I landed a six-month internship to build an app for a startup, with the option for the company to convert me to fulltime afterwards. I was given a mentor who did an excellent job of helping me start to learn Ruby on Rails and understand reading the API he had built out. However, no one else at the company knew iOS so I was left my own accord to build the app; let’s just say that Stack Overflow became my best friend. There was a point that one of my coworkers was trying to help me out and I noted how I would usually just go to Stack Overflow, copy paste in the accepted answer and it would just work (thank you to Objective-C for being statically typed and a pretty rigid UIKit API); needless to say, that was in early 2013 and he still jokes about it today. It ended up taking me just about seven months to actually finish the app and I was thankfully given an extension on the internship since I was so close to finish. I learned that I was capable of being able to take a project from conception to production where I was the primary developer, which was a huge achievement in my mind. The company seemed to think so too and I was extended a fulltime offer which I gladly accepted.

Upon the completion of the iOS app I was asked to dive right into learning web development on the company’s main Rails application. I started off mainly working on a bug tickets, which I’ve always felt is a great way to get an introduction to a code base; an isolated task with a clear definition of completion meant that I wasn’t spinning my wheels trying to create a new product when I didn’t even fully understand the breadth or depth of the current product. The company also happened to be in the middle of a re-write of the UI portion of the application so I was lucky to have a plethora of bugs to be able to tackle. Given that all the senior engineers had a deep understanding of Rails to help guide me, the time it took to skill up and understand concepts was exponentially faster than learning iOS. However, it wasn’t long until I was tasked with creating a new product, changing one of the initial user funnels from a full-page form into a modal. Myself and a member of the UX team went about collecting user info and iterating on designs until we were happy with the concept, which I set out and implemented. Yet again I found myself capable of being able to deliver products to production in a different language where I was primary developer!

It wasn’t long after delivering that product that the startup I was at ended up being acquired by one of our competitors, around the end of 2013. That meant a new office, new coworkers, and most of all new codebases and projects. The company tasked our team with leading the initiative for a new product line and we were going to build it with a mobile first mentality. Two coworkers and I were put onto the iOS team with a tight connection to the team working on the Rails API to ensure the integration went smoothly. We were able to launch the beta version of the application after six months. The company held a Dog Food Day to have other employees test out the application; everyone was impressed with the technology but noted the lack of polish, as expected with a beta app. Over the next year we continued to work on this application and I even picked up more work on the API side as some engineers transferred to different products, but ultimately this venture was deemed a failure. The company decided that it was just too big of an undertaking and shuttered the effort. This project was one of the first times I would be confronted with the fact that not all code ends up making a difference; sometimes you spend months or years on something only to see it shut down. I quickly learned that I need to take the experience I gained while building the project and apply that to the next, rather than dwell on things like ‘what if I had done something different?’

Currently: 2016 – 2019

Around April of 2016 that I got pulled onto a project that as deemed ‘the fifth or sixth time we’re trying to rewrite the vehicle data ETL pipeline.’ Myself and two others were tasked with turning that pipeline into a web app, which would consist of Rails and what, at the time, was called an isomorphic React application. I hadn’t written much JavaScript at this point, nor had the other two developers. Throw early React into the mix and we had a recipe for some road bumps; the hardest part was that the tooling and React versions were constantly being updated under us. It was a great lesson in what happens being an early adopter of a framework; some of the decisions we made were the accepted patterns at the time, we also used some early versions of libraries and ended up with some very tightly coupled code that works to this day, but should probably be re-evaluated. I’ve continued to maintain this project, to a much larger extent on the Rails side, adding more and more automation wherever possible and I consider myself to be the tech lead of it. The other two original engineers moved onto a different teams and new coworkers were added to the project. I applied the same philosophy of bringing the new engineers up to speed by having an onboarding session of the project and then assigning bug tickets to them until they were comfortable with the codebase and able to begin work on new features.

Work within that project started to dwindle at the beginning of 2018 and the company started to focus on a complete re-platforming effort. We were going to shut down all of our datacenters and move everything to AWS along with consolidating the projects to be Rails and React based or Java for Data Engineering; before we had Java, Python, Ruby, native iOS, native Android, and probably some other stuff I didn’t even know about. Given the re-platforming effort and the need for my project to become the basis of all vehicle data within company, I was tasked with working with different teams to integrate the data. The first step was to work with the Data Engineering team to create a pipeline in which I would export all the data into a database which they could access via Spark and extract into HBase. The collaborative effort between myself and that team did not take too long and I was moved onto another team which was working on one of the primary funnels of our consumer facing website. The funnel is the largest user of the vehicle data and I was the one most familiar with the schema so I set out to help that team understand what their data needs were and how to start building APIs around those needs. What I didn’t expect from this move was to have to dive head first back into writing React. The consumer facing website is a different repository than the data project and has had 10x the engineers working on it; safe to say the code was drastically different, but in a good way. It took some time to brush up on my React skills and come up to speed on the different patterns that were being used, but I’ve remained on the consumer facing website team since and can say that I’m comfortable in the frontend world these days. Finally, I’m happy to report that as of end of the 2018, the ETL process was given its EOL and the data project I was the tech lead of successfully became the new source of vehicle data for the main products within the company; it was three years of work between tons of different engineers, but we were finally successful where the other attempts had all failed.

That brings us to the present day. I’ve gone from a freshman in college who didn’t understand basic conditional logic, to an intern who really only knew iOS. From building up my initial Rails skills to being a tech lead on a Rails project foundational to the company’s data needs. From the early days of React to being proficient enough to hold my own. I’ve enjoyed almost every minute of the journey and still love being able to come to work and write code. But just as I’ve grown over the past ten years, I’m excited to think about where I might be as an engineer in ten years from now.

My Next Ten Years:

The first area I would like to learn more about is Functional Programming and Elixir / Erlang. As you’ve read, I started out with Object Oriented languages all the way back in my freshman year of college with Java and have been working in them ever since. While Ruby and JavaScript do contain many Functional Programming concepts, which I frequently use, I believe having a strong understanding of at least one functional language would allow me to think about programming in a new lens. With that, I’m totally enamored with Elixir. First and foremost, I’ve found the Elixir community to be amazing. People are always tweeting interesting things with #myelixirstatus, community leaders are active in Slack, and the number of books and resources to learn the language is growing every day. I've spent time on small side projects many times, but I recently starting building out an idea I had. Development is much slower than if I had chosen to use Rails, but I find the chance to learn and grow as a great opportunity!

Another area I have a lot of interest in is DevOps / Docker / Go. As the re-platforming effort happened, all the engineers were introduced to Docker to some degree. For the first few years I really didn’t spend any time learning about Docker; whenever I needed to fix something in a Dockerfile, I had no idea what any of the commands meant and I had to read the docs all over again. It was frustrating to try to fix the issue and it would end up taking much longer that I would have liked. Recently I started spending more reading and learning about Docker and I feel that the containerization movement will continue to grow.

Finally, it’s very likely that I will continue to work with Ruby on Rails and in doing so I’m hoping that I can continue to learn and write about my experiences. I have a ton of ideas in my head about things I’ve learned throughout my careers that I could write about, I just need to sit down and start flushing them out.

With that said, I’ll wrap this up and get started on the next post by saying thank you for coming along this little trip down memory lane with me. Hopefully another ten years down the road I’ll be able to reflect on this post and see if my areas of interest ended up aligning with my actual career.