ą®ą®©ą®æą®Æ ą®ą®¾ą®²ąÆ ą®µą®£ą®ąÆą®ą®®ąÆ, Buen DĆa, and Good Morning from New York City :)
Iāll be sharing a tweet I loved.
A Tweet š¦
I donāt think people understand how ridiculous the last 10 years of corporate software was.
For the last 10 years, I've been building brand new software systems. Exclusively.
Systems executives dreamt up.Ā
Systems product managers dreamt up.
Systems software engineers dreamt up.
From scratch.
The goal was how can this system scale to millions of users. Quickly. Making money wouldnāt be bottlenecked by the system, but rather by the marketing teamās ability to acquire customers.
Zero interest rate policy (ZIRP) had investors and management chasing more than profits. They wanted the whole market. Books like Blitzscaling, by Reid Hoffman - founder of LinkedIn, detail the strategy ofĀ
āscaling up at a dizzying pace that blows competitors out of the water. The objective of Blitzscaling is not to go from zero to one, but from one to one billion āas quickly as possible.ā
But once the federal funds rate was raised from .25% to .50%, managementās tune changed. Winning the whole market was no longer a concern. Now it was, āYouāre spending too muchā.
Management was now incentivized to find cost savings.Ā
Funding for new projects was slashed. Projects almost done were paused. And engineers who worked on these dreamt up, whole-market grabbing systems were suddenly hit with
Any profitable system became sacred. Luckily for me, instead of a meeting with Dr. Cox, I was offered an opportunity to focus on a system that makes the company ~$30B/year. A mature system.
A system whose codebase has no tests.Ā A system where the team is afraid to change the code. A legacy system.
The suggestions in
tweet are 100% correct.Implementing test cases establishes baseline behavior.
Configuring CI/CD automates the running of these tests. If passing, deploy!
Monitoring to validate the code change in production is running as expected.
Fallback to a working version when a code change isnāt acting as expected.
Iāve applied these suggestions to a new system. Iāve never applied these suggestions to a legacy system. But, I have a friend who has.
He recommended that I read āWorking Effectively With Legacy Codeā. He applied the principles at two different companies. It worked both times.
We need to establish the expected behavior of the codebase by adding tests.Ā
Monitoring and fallbacks without testing before deployment leads to finding failures too late.
At first, I wasnāt too thrilled about focusing on a legacy system. To reverse the rot. But the incentives of corporate software have changed.
Over the next 2-4 years, at big companies - engineers will be refining old, money making systems. Not building brand new ones.
And I just wanna be close to the money.
With Love,
Janahan
P.S. If you liked this post from Often Wrong Club, why not share it with someone who would like it too?
P.P.S. If you wanna learn how to make pliant, puffy corn tortillas from scratch - check out this video!
Whenever you're ready, there are 2 additional ways I can help you:
1. If youāre looking to break past the senior software engineer glass ceiling, Iād recommend starting with this affordable course. These are the secrets Iāve learned from going from a mid-level to a Distinguished Engineer in less than 4 years. Join 97+ students from over 20 countries.
2. If you want to grab coffee in New York City, hit reply to let me know when youāre in town ā
> a system that makes the company ~$30B/year. A mature system.
> A system whose codebase has no tests.
Iāve spent the past 4 years, part-time, on and off, improving the front-end tests in a fintech company. They have a mature, 10+y product that (mostly) evolved with tech. The front end, although strated from jQuery and Backbone, now feels like a modern stack to work with (all the latest React and build tools). It takes time and effort but if it makes you money, itās a reasonable investment.
Luckily my new move was close to money. Survived this time..
hope you staying safe and things gets better soon. Stay safely