Throw Something Back
Maya Angelou said you shouldn’t go through life with “a catcher’s mitt on both hands.” You need to be able to throw something back. Arnold Schwarzenegger made a related point when he said, “Don’t ever, ever call me the self-made man.” Nobody gets good at this job alone. Most of what you know came from someone else, and the way to pay that back is to share what you’ve learned.
Two mitts
Engineers catch a lot. A reviewer explains why the retry loop needs jitter. A teammate shows you how to find a regression with git bisect. A stranger’s Stack Overflow answer unsticks you late at night. The library you pulled in this morning is years of someone’s evenings.
Early in a career, catching is the job. You should be absorbing everything you can. The trouble starts when that never changes, and ten years in you’re still only taking: answering questions grudgingly and keeping the hard-won knowledge in your head.
Nobody is self-made
Look at how you write code and you’ll find other people in it. Your instinct for small functions probably came from someone’s review comments. Your habit of writing the test first came from a pairing session or a book. The way you structure a pull request, and the error you always check for because it burned someone once, you picked up from somewhere.
We’re shaped by the people we work with and what we learn from them. That’s most of the story of a career, even if the résumé only lists one name.
Sharing scales what you know
Learning something new is half of it. The other half is taking the time to share it. Knowledge that lives in one head has a bus factor of one. It also has a throughput of one: every question routes through you, and you end up answering the same thing for the fifth time in Slack.
Write it down in the README once and it answers the question for everyone who comes after. Teach it to two people and three people can handle the next incident.
As a leader, your impact shows up in what the people around you can do when you’re not in the room. Sharing, teaching, and mentoring are the best way I know to scale your knowledge and experience that far.
Ways to throw something back
None of this needs a formal program. Most of it fits inside the work you already do.
Mentor someone. A regular half hour with a newer engineer goes a long way. Ask questions before handing over answers; “what have you tried?” teaches more than the fix does.
Pair, and let the less experienced person drive. When you’re the one typing, narrate your reasoning: “I’m checking the logs before reading the code because the error names the service that failed.” The reasoning is the part they can’t get from the diff.
Treat code review as teaching. Compare two comments on the same change:
Use a transaction here.
These two writes can leave a half-created order if the second one fails. Wrapping them in a transaction makes it all or nothing.
The first comment gets the code fixed. The second one means you probably won’t have to leave it again.
Write things down. Architecture decision records, runbooks, onboarding docs, the postmortem nobody wants to write. Writing reaches people you’ll never meet, and it keeps working after you’ve changed teams.
Blog. I started this blog to write about what I learn as a software engineer. Some of it is small, like a Docker Compose networking yak shave. Small posts are often exactly what the next person pasting that error message into a search box needs.
Throwing it back makes you better
Teaching pays you back, too. Explaining something out loud finds the gaps in your own understanding fast. A new engineer’s questions show you which parts of the onboarding docs are wrong, and a review comment that explains the why makes you check whether the why holds up.
You caught a lot to get where you are. Throw some of it back.