Thoughts On Service
soft-skillsThis is mainly intended for volunteering in general or serving as an officer in the SCA but aspects are likely also generally applicable.
https://addyo.substack.com/p/21-lessons-from-14-years-at-google
1. The best engineers are obsessed with solving user problems.
The engineer who starts with a solution tends to build complexity in search of a justification.
2. Being right is cheap. Getting to right together is the real work.
The skill isn’t being right. It’s entering discussions to align on the problem, creating space for others, and remaining skeptical of your own certainty.
Strong opinions, weakly held - not because you lack conviction, but because decisions made under uncertainty shouldn’t be welded to identity.
3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.
First do it, then do it right, then do it better. Get the ugly prototype in front of users. Write the messy first draft of the design doc. Ship the MVP that embarrasses you slightly. You’ll learn more from one week of real feedback than a month of theoretical debate.
Momentum creates clarity. Analysis paralysis creates nothing.
4. Clarity is seniority. Cleverness is overhead.
In that environment, clarity isn’t a style preference - it’s operational risk reduction.
Your code is a strategy memo to strangers who will maintain it at 2am during an outage. Optimize for their comprehension, not your elegance. The senior engineers I respect most have learned to trade cleverness for clarity, every time.
5. Novelty is a loan you repay in outages, hiring, and cognitive overhead.
The punchline isn’t “never innovate.” It’s “innovate only where you’re uniquely paid to innovate.” Everything else should default to boring, because boring has known failure modes.
The “best tool for the job” is often the “least-worst tool across many jobs”-because operating a zoo becomes the real tax.
6. Your code doesn’t advocate for you. People do.
If no one can articulate your impact when you’re not in the room, your impact is effectively optional.
This isn’t strictly about self-promotion. It’s about making the value chain legible to everyone- including yourself.
7. The best code is the code you never had to write.
Before you build, exhaust the question: “What would happen if we just… didn’t?” Sometimes the answer is “nothing bad,” and that’s your solution.
The problem isn’t that engineers can’t write code or use AI to do so. It’s that we’re so good at writing it that we forget to ask whether we should.
8. At scale, even your bugs have users.
With enough users, every observable behavior becomes a dependency - regardless of what you promised. Someone is scraping your API, automating your quirks, caching your bugs.
This creates a career-level insight: you can’t treat compatibility work as “maintenance” and new features as “real work.” Compatibility is product.
Design your deprecations as migrations with time, tooling, and empathy. Most “API design” is actually “API retirement.”
9. Most “slow” teams are actually misaligned teams.
Senior engineers spend more time clarifying direction, interfaces, and priorities than “writing code faster” because that’s where the actual bottleneck lives.
10. Focus on what you can control. Ignore what you can’t.
In a large company, countless variables are outside your control - organizational changes, management decisions, market shifts, product pivots. Dwelling on these creates anxiety without agency.
This isn’t passive acceptance but it is strategic focus. Energy spent on what you can’t change is energy stolen from what you can.
12. Writing forces clarity. The fastest way to learn something better is to try teaching it.
This isn’t just about being generous with knowledge. It’s a selfish learning hack. If you think you understand something, try to explain it simply. The places where you stumble are the places where your understanding is shallow.
Teaching is debugging your own mental models.
14. If you win every debate, you’re probably accumulating silent resistance.
The short-term feeling of being right is worth much less than the long-term reality of building things with willing collaborators.
15. When a measure becomes a target, it stops measuring.
If you track lines of code, you’ll get more lines. If you track velocity, you’ll get inflated estimates.
The senior move: respond to every metric request with a pair. One for speed. One for quality or risk. Then insist on interpreting trends, not worshiping thresholds. The goal is insight, not surveillance.
16. Admitting what you don’t know creates more safety than pretending you do.
Senior engineers who say “I don’t know” aren’t showing weakness - they’re creating permission. When a leader admits uncertainty, it signals that the room is safe for others to do the same. The alternative is a culture where everyone pretends to understand and problems stay hidden until they explode.
Model curiosity, and you get a team that actually learns.
17. Your network outlasts every job you’ll ever have.
Early in my career, I focused on the work and neglected networking. In hindsight, this was a mistake. Colleagues who invested in relationships - inside and outside the company - reaped benefits for decades.
They heard about opportunities first, could build bridges faster, got recommended for roles, and co-founded ventures with people they’d built trust with over years.
Your job isn’t forever, but your network is. Approach it with curiosity and generosity, not transactional hustle.
When the time comes to move on, it’s often relationships that open the door.
18. Most performance wins come from removing work, not adding cleverness.
Deleting unnecessary work is almost always more impactful than doing necessary work faster. The fastest code is code that never runs.
Before you optimize, question whether the work should exist at all.
19. Process exists to reduce uncertainty, not to create paper trails.
The best process makes coordination easier and failures cheaper. The worst process is bureaucratic theater - it exists not to help but to assign blame when things go wrong.
If you can’t explain how a process reduces risk or increases clarity, it’s probably just overhead.
And if people are spending more time documenting their work than doing it, something has gone deeply wrong.
20. Eventually, time becomes worth more than money. Act accordingly.
Early in your career, you trade time for money - and that’s fine. But at some point, the calculus inverts. You start to realize that time is the non-renewable resource.
I’ve watched senior engineers burn out chasing the next promo level, optimizing for a few more percentage points of compensation. Some of them got it. Most of them wondered, afterward, if it was worth what they gave up.
The answer isn’t “don’t work hard.” It’s “know what you’re trading, and make the trade deliberately.”
21. There are no shortcuts, but there is compounding.
Expertise comes from deliberate practice - pushing slightly beyond your current skill, reflecting, repeating. For years. There’s no condensed version.
But here’s the hopeful part: learning compounds when it creates new options, not just new trivia. Write - not for engagement, but for clarity. Build reusable primitives. Collect scar tissue into playbooks.