Stop Adding Features! A Lesson for Start-Up Engineers

I am the lead UI engineer at Simulmedia. I've been with the company for 5 years, and was one of its original engineers. Simulmedia is the 3rd startup I've worked for (all led by Dave Morgan our Founder and CEO). Most any engineer who's worked at a startup probably has a similar story to tell one of a product that needs to be built quickly, yet has the flexibility to adapt to what's sure to be a changing business model. Tight requirements are at best nebulous if they exist at all, and are likely to change many times before the product's first release.

Let me take you back to the start of this adventure. As the very first UI team lead at Simulmedia (leading a team of one), I found myself in this very circumstance circa late 2009. With a strong desire to iterate quickly while keeping learning curves low, I chose Google Web Toolkit to build our new company's first interface. I could code in Java, and let it generate cross-browser JavaScript for a "Web 2.0" experience. Within a mere couple days, the first deliverable (user authentication) was up and running. And within weeks, I felt confident our architecture had stabilized and was ready to meet whatever demands the business had of it.

As time passed, the product we built was providing more and more assistance to our user base. These were exciting days! Essentially a rapid-prototyping tool, the interface was fulfilling its intent. I could quickly add new features as the business indicated demand for them. The framework, built for speed and simplicity of development, practically led the developer into the new feature as if following a simple checklist. However, despite all its new and deeply desired capabilities, the UI itself hadnt really matured as a product, and neither had the engineer writing it (me).

Flash forward to November of 2013. With the intent of adding exciting new product offerings, we staffed up the Simulmedia Engineering department rapidly. We gained a lot of diverse experience, and a lot of new viewpoints. While not something I had thought about day-to-day, a lot had changed in the tech landscape since our product started its life back in 2009. So with all these fresh perspectives, we endeavored to give our product portfolio (including the UI) a fresh start.

After a rather brief period of research, we (excitingly, it was now a we environment) settled on Ruby on Rails and AngularJS for the new user interface. While coding in Ruby is VERY different than Java, as a risk-averse guy I personally found the conventions that Rails provided rather comforting. These conventions could keep us from making architecturally unsound decisions that wed pay for later on down the road. Going with something like a pure JS framework provided a bit too much wiggle room for folks who were learning as they built.

(Alert: now things get technical!) Despite this structure, we still had lots of things we had to figure out on our own. The collective knowledge on the Internet didn't quite get to a consensus around Rails and AngularJS integration, but we end up foregoing the standard Sprockets-based asset pipeline for one built with GruntJS. Additionally, it seems that CoffeeScript might be interesting, so we standardize on it over writing plain old and much more familiar JavaScript code. For SCM, we adopt Github despite having always used Subversion. Need to share some of the GruntJS stuff among multiple projects? Let's build it into an NPM package. Might we need to reuse some MVC components we've built in Rails for another (perhaps externally-facing) application? Let's create a Rails 4 Engine for that. Long gone are the GWT days of just writing Java. We now have lots of different and new-to-us tech in our stack, and we need to be good at all of it.

As each release goes by, we certainly get better at using all these new technologies weve opted to include. However, comfortable has not made its way into the plan. There's a constant re-evaluation of our usage of each of these. We begin to do more and more with AngularJS, and start using Rails more as a mechanism to serve up a bunch of different little Single Page Applications. The pipeline approach gets rethought, and we go back to Sprockets. Engines get refactored, and more new technologies get added into the stack.

Now we are in early 2015. Members of the UI team are building APIs. Members of the data team are enhancing the interface. Suddenly there's no such thing as a "UI engineer" or a "Rails engineer" or "insert-label-here engineer". We are constantly challenging our own personal preconceptions of what we're good at, or what our individual roles would dictate we "should be" doing. We are constantly challenging ourselves as engineers and as Simulmedians, and we are thriving.

And the benefits of challenging ourselves are most definitely tangible. Not only are we adding new talents to our skillsets at an astounding rate, our results are getting stronger and stronger. We're not just adding features anymore. Don't get me wrong -- you can build a great product and continue to get better at your day-to-day doing just that. However, gains in overall engineering savvy become harder and harder to achieve. Much like an exercise routine, we can't simply do the same workout day after day and expect to keep improving indefinitely. If we change things around -- throw in cross-training, go for a run, lift some weights -- our bodies are forced to adapt and we'll bust off that plateau. We all want and need to be well rounded and maintain our agility and relevancy in a competitive world. We can't necessarily know every new tech that enters the landscape, but if we've continually challenged ourselves, we can feel confident that well be prepared for whatever comes our way.

So next opportunity you have, think about new ways to do old things. Keep stretching yourself. As an engineer, you will be all the better for it, and the products you create will benefit!