I felt private disappointment when, in my first engineering role, my manager informed me I would be working on the old stack. The company’s web application historically ran on a not-so-recent version of Emberjs housed in a monolithic repo; I’m not sure exactly how old it was, but git-blame often unearthed commits over 4 years old. The team had recently begun the process of migrating to the new stack: a set of React micro-frontends, a brand new UI component library, an Apollo graphQL service. Very sexy, the stuff of many a Medium post.
Because of politics, resources and all the other usual reasons, only a few features at a time were being built out in the new stack. I wanted to work on the new stack because it was hype, because I wanted those buzzwords on my resume, and most of all because I didn’t want to invest the time to learn what felt like a pointlessly old framework. Smashing “Emberjs” on my LinkedIn skills wouldn’t be bringing in any job opportunities at exciting companies. I want to be an astronaut, not an archaeologist.
But I was grateful for the opportunity to work on the team in the first place, so I did the work assigned to me. Sat through a very old Frontend Masters video, died inside a little every time I had to change the Ember docs version and get a huge “Deprecated” warning, and slowly waded into the codebase.
But with time, a few things happened:
-I finally really understood the difference between logic and presentation, what the M-V-C paradigm actually means. Having only learned React, I had never used an opinionated framework before or learned about separation of concerns.
-I became much better at reading and understanding code. The new stack was being written by about 5-7 of my teammates, whose design and thought processes I had become familiar with. For the first time, I was exposed to code written by at least 3 times that many people over several years, many of whom were no longer with the company. Many of the services had no real owner, so I was forced to come to my own understanding of the system.
-I became a much more deliberate engineer. The old code did not magically become elegant, less clunky, or more manageable. It continued to suck to work with, requiring both creativity but also measured steps to not break other things.
-I became much better at debugging. Having to climb over dozens of old files just to solve simple bugs, not to mention going without the tools and google searches I was used to, forced me to develop a better process.
Most of the aspiring developers I see on Twitter are much like myself, and have only ever learned React. Nobody wants to work under the weight of deprecated frameworks and mysteriously critical yet incoherent code. Few people, including myself, advocate for willfully working 100% on a legacy codebase — that path leads only to career masochism (or lucrative consulting). But being exposed to older frameworks, systems, or models will expand your mind.
To all the junior engineers out there, disappointed and disgusted with old tech, I suggest: embrace the legacy codebase, at least once. Learn something from the fossils of the creatures that lived and died before your time.