Earning Trust as a Junior Software Engineer
“The thing to understand is, trust is currency in software engineering. Your everyday actions are no more than a barter between your trustworthiness and coworker buy-in.”
Amazon publishes a list of leadership principles that govern their everyday business decisions. It’s worth a read, if only because not too many companies offer a look behind the curtain at their core strategies. I’m here to talk about what principle is most valuable (in terms of what we care about, which is career progression) as a junior software engineer getting their feet wet. When I was a junior engineer, mastering this idea propelled my career faster than anything else. And now that I’m no longer a junior, it’s the number one skill I look for in the folks I mentor.
Earn. Trust.
It’s super simple. I wager that most people reading this believe they are already doing a sufficient job of earning trust. You probably could be doing more.
Here’s an example of earning trust. Sam writes code and puts it in a pull request. Before asking for reviews, they proactively review their own code for iffy decisions and highlights potentially inefficient code for the reviewers. It’s like planting red flags all over their code diff, but in this case it’s a good thing. Trust is being earned here, because it’s clear that Sam is not trying to hide iffy code behind a smokescreen of other changes. If I am the one reviewing the PR, I begin to trust that Sam is being transparent and has not cut any corners.
And here’s an example of eroding trust. When Peyton has to review larger pull requests, they frequently approve without understanding the full picture of the change. The thought process is it’s probably okay, and thus a corner is cut. When one of these pull requests inevitably introduces a bug, it’s time to pay the piper. Senior engineers called upon to clean up the mess will run git blame , find the offending commit, and wonder, how did this pull request with 500 lines changes get approved with nary a comment? Trust is lost; Peyton’s stamp of approval is now vapid.
You can earn trust when you screw up: taking accountability is building trust. Take a second look at Peyton’s example. They didn’t lose trust because they approved a pull request with a bug. They lost trust because they didn’t provide an adequate paper trail for future audits (which are just git blame in the tech world). All they had to do to maintain trust was ask for clarification on iffy code and/or provide reasoning for approval. Even a comment like this goes a long way: “I’m going to approve because despite this large diff, existing code is not changing much thus the risk of regression is low.” In just one sentence, Peyton provided reasonable justification to do what they did. Auditors can dissect why Peyton missed the regression, but at least they aren’t left scratching their heads as to why an approval went through. You never want to make your seniors guessing.
The thing to understand is, trust is currency in software engineering. Your everyday actions are no more than a barter between your trustworthiness and coworker buy-in. You can spend trust, and you do it all the time in your day-to-day. Asking for an approval is spending your trust. Presenting a proposal to the team is spending trust. Asking to re-explain something is spending trust — this time, trust that you had a momentary lapse and are not a nincompoop.
A senior engineer can push a large swath of code through the finish line with less oversight than a junior engineer. Why? They simply have saved more trust in the bank. Trust that their code, however scantily reviewed, is still ironclad. Likewise, a senior can simply say “hehe oops my bad,” when they screw up, because their history of not screwing up often has earned them that trust. A junior saying “oops my bad” will land them in heaps of trouble.
A positive correlation forms. The more trust you have in the bank, the more senior you are. And vice versa. I don’t need to draw a graph to prove this point.
From a personal standpoint, I believe that earning trust at a vociferous pace is what afforded me additional responsibility fast, and performing adequately on those opportunities is what helped me move up the ladder. Now, I can’t help but smile when I see a new engineer announce that they’ve identified a problem and written a doc on potential solutions. I know what’s happening — they are saving up on currency worth its weight in gold.
