Neither. You promise to extend the platform but you need at least two years. In the meantime, you promise to build a patch to unblock things temporarily. Then, reorgs happen and everyone forgets the patch was a patch. Repeat this 100x times and that's how platforms evolve today.

https://twitter.com/kelseyhightower/status/1637838103267393538

Most of today's modern systems are duck tapes put together by duck tapes to make things happen. No company has enough budget to maintain a reasonable well featured platform unless they are a cloud provider because it's not their core business.

What people don't understand is you design X and end up with Y while scaling a service. Y is never the ideal design but the only option you have starting at X and not being able to afford any downtime. You start with the tech stack D, and the world moves on to H and makes your entire technological choices of X irrelevant. If you want to reposition Y to adopt more of H, you can't effective move forward for changing two things at a time.

This platform is great to practice mass communication skills by sticking to layperson language. But as a result of the unique way how I use it, people sometimes think I'm a layperson myself. I use this platform to practice language. It makes my writing better and more accessible. It allows me to write documents that are consumable by a large audience at large companies.

People responding that ORR is a solution is missing the point of this tweet. ORRs are incentivized to be done before launches, reviews should be continuous. Leaders should have an independent report on the investment they need to do.

https://twitter.com/rakyll/status/1488945228379672576

I've seen numerous times in my career that engineers can't get enough attention from leadership to invest time into maintenance. Reviews can bring an objective perspective. Reviews cannot mandate fixes but should portray the current state.

There is a thin window for a startup to be attractive for a very senior FAANG engineer financially. It's either early stage with a lot of equity or late stage before exit. Anything in between is higher risk for less compensation. If you are hiring a director-level engineer, and want to pay them paper money, the truth is you have to give them a percentage of the company. This is why their more reasonable exit is to start their own companies.

When I was a kid, I signed up for competitive swimming, classical piano, vocal training, painting, and some more extracurricular activity. My parents were supportive at first but started to question why I'm into many hobbies and have a short interest span.

https://twitter.com/mipsytipsy/status/1481491214062919681

Then I became interested in programming. It was a brilliant hack because I was touching so many different things yet they were all in the same box, and my parents wouldn't be able to tell how I was splitting my time.

If I'm starting a company:
- No Outlook or Word.
- No one will be in meetings more than 50% of their time, even the execs.
- Day job will take half of your time, the other will be inventing things.
- No heavy planning, we will instead build prototypes and write one-pagers. - Maintenance is harder than launching new products.
- Reliability and security are the #1 job.
- It's ok to specialize in operations.
- You're empowered to initiate instead of being stuck in an approval queue for years.
- It's ok to fail, we can only succeed once in a while.

Because tech believes it’s a fork and operating in a parallel universe. If you have been in the programming scene in the 90s, you can understand what I mean. Tech people believe tech is free from soxiety’s legacy issues.

https://twitter.com/rachelyhe_/status/1277704636238123013

We still see many people truly believe you can be whoever you want to be in tech and your skills are your only limits. They completely ignore how society and power dynamics work because they believe tech created enough space to free everyone from the world’s legacy issues.

I worked on several migration projects from SOAP services to microservices back in 2007-2010. We have done a lot of mistakes by following the hype instead of doing what was best for us. (a thread) We assumed sizing things small without understanding their impact on the organization and operation was the best practice. We had little experience operating a large number of services and didn't quite understand what will scale and what won't scale.

Google's interview system is not great but there are various reasons why it feels less than it is. Most candidates don't know what the goal of our interviews are. First rule, it is not about finding an optimal solution or any solution at all. You are interviewed for multiple skills simultaneously. Cognitive skills, communication, leadership are a few to name. If the point is not finding a solution, then what is it? Let me explain.

Today's rant: Both distributed traces and events don't give you much other than the overall flow and the components involved. Both signals are often very weak in debugging any latency problems. It is up to your capabilities to correlate them with additional data. Given the overwhelming amount of work required to have them end-to-end, I understand why no one really cares. You invest a year or two of into tracing, yet it only crack opens the door. You gotta figure out everything else yourself.