11–20 of 732 posts
I like this one > At scale, even your bugs have users. Something I discovered the hard way over many years of maintaining rclone. Fixing a bug has consequences and there are sometimes users depending on that bug! xkcd: https://xkcd.com/1172/
"With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody."
I like this one > At scale, even your bugs have users. Something I discovered the hard way over many years of maintaining rclone. Fixing a bug has consequences and there are sometimes users depending on that bug! xkcd: https://xkcd.com/1172/
First place I worked right out of college had a big training seminar for new hires. One day we were told the story of how they’d improved load times from around 5min to 30seconds, this improvement was in the mid 90s. The negative responses from clients were instant. The load time improvements had destroyed their company culture. Instead of everyone coming into the office, turning on their computers, and spending the next 10min chatting and drinking coffee the software was ready before they’d even stood up from their desk!
The moral of the story, and the quote, isn’t that you shouldn’t improve things. Instead it’s a reminder that the software you’re building doesn’t exist in a PRD or a test suite. It’s a system that people will interact with out there in the world. Habits with form, workarounds will be developed, bugs will be leaned for actual use cases.
This makes it critically important that you, the software engineer, understand the purpose and real world usage of your software. Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems.
Every engineer should read this. It's a wonderful collection of heuristics that might seem banal, but which are shimmeringly true. The two that stand out are > Novelty is a loan you repay in outages, hiring, and cognitive overhead. and > Abstractions don’t remove complexity. They move it to the day you’re on call. as a warning against about being too, too clever.
There's rarely a bullet point advantage that some new language or tech stack can offer me that would outweigh ten years of observation of how a familiar setup behaves in production, such that the space of unknown unknowns is reduced to almost nothing.
#2 and #14 are tough pills to swallow. It's not enough to be right, or even have a long track record of being right. You usually have to convince others that it was their idea all along, but still advocate for yourself at performance review time.
Earlier quoted context omitted.
There's rarely a bullet point advantage that some new language or tech stack can offer me that would outweigh ten years of observation of how a familiar setup behaves in production, such that the space of unknown unknowns is reduced to almost nothing.
My personal rule is that the new technology stack item needs to either make is possible for me to build something that I couldn't have built without it, or needs to provide a productivity boost significant enough to overcome the productivity lost by straying from the more familiar path - even harder for team projects where multiple people need to learn the new component.
My #1 issue with mid level engineers is that they like complexity and find complexity fun and interesting.
An experienced engineer knows that complexity is irritating and frustrating and that a simple solution is harder and superior.
A solution that simultaneously solves the problem and reduces complexity is almost the definition of genius. If you are good you will do this a few times in your whole career.
> If you win every debate, you’re probably accumulating silent resistance.
Every engineer should read this. It's a wonderful collection of heuristics that might seem banal, but which are shimmeringly true. The two that stand out are > Novelty is a loan you repay in outages, hiring, and cognitive overhead. and > Abstractions don’t remove complexity. They move it to the day you’re on call. as a warning against about being too, too clever.
But at the same time lessons aren't learned by reading what someone else has to say. They're learned by experience, and everyone's is different. An engineer with "14 years at Google" hardly makes them an expert at giving career advice, but they sure like to write like it does.
This type of article reads more like a promotion piece from self-involved people, than heartfelt advice from someone knowledgeable. This is evident from the author's "bio" page: written in 3rd person, full of aggrandizing claims of their accomplishments, and photos with famous people they've met. I'm conditioned to tune out most of what these characters have to say.
If this is the type of people who excel in Big Tech, it must be an insufferable place to be.