#48: Fear Of Code 😱

I don’t think people understand…

I made these lamb barbacoa flautas. Tortillas made by hand - 8.9/10

இனிய காலை வணக்கம், Buen Día, and Good Morning from New York City :)

I’ll be sharing a tweet I loved.

A Tweet 🐦

Fernando is a wealth of software engineering wisdom.

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”.

The red arrow shows the start of the Federal Reserve raising interest rates in March 2022.

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

~400,000 tech workers have been laid off since January 2022.

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

The Polymathic Engineer

tweet are 100% correct.

1. Implementing test cases establishes baseline behavior.

2. Configuring CI/CD automates the running of these tests. If passing, deploy!

3. Monitoring to validate the code change in production is running as expected.

4. 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!

I made these blue corn tortillas after watching the video above. Best I’ve ever made.

---

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 ☕