When a senior software engineer joins a new company, there’s often an unspoken expectation, sometimes even a belief, that they will hit the ground running, level up the team, and become an influential voice from day one.
But in reality, many senior engineers end up torpedoing their own success within the first few months.
Despite having deep experience and strong resumes, some struggle to adapt to their new environment. They unintentionally alienate their teammates, push ideas that don’t land, or adopt a work style that doesn’t fit the culture. And by the time the damage becomes visible, their long-term trajectory may already be off course.
After watching this play out a few too many times, I’ve started recognizing a few common missteps that tend to sink reputations before they’ve had a chance to rise.
There’s a lot of advice out there about how to make a great first impression. But not enough people talk about the last impression. How you leave a team or a company can often define how you’re remembered, far more than you think.
When engineers are on their way out, whether it's for a better opportunity or just time for a change, there's a temptation to mentally check out. “I’m done here” they think. But your reputation doesn’t stop the day you resign. In fact, the way you handle those last few days or weeks can either seal the good reputation you’ve built, or destroy it in a flash.
Today, I want to talk about a silent killer of software engineer reputations — bad coding hygiene.
I’ve seen it happen over and over again. A new engineer joins the team, eager to start strong. They dive into the code, push a few commits, open their first pull request… and then it hits. Reviewers look at the code and find a mess: test cases that don’t follow naming conventions, i and j used as variable names, dead code hanging around like forgotten leftovers, unformatted blocks of logic, and the classic — TODOs that scream “I didn’t finish this but please merge anyway.”
When I take on managing a new engineering team, whether by inheriting an existing one or hiring from scratch, one of the first things I do is create a Team Knowledge Density document. This document helps me understand how knowledge is distributed across the team, identify areas where expertise is siloed, and take action to mitigate risks. Over the years, it has proven to be one of my most effective tools for setting up teams for success.
In my engineering team, we hold daily standups, and to keep things engaging, we wanted to randomize the order of speakers each day. However, we quickly realized that while randomizing keeps things fresh, it also catches people off guard if they don't know when they will be called upon. To solve this, I built an automation using Google Apps Script that:
Randomizes the standup order while grouping people from the same workstream together.
Sends a Slack message every weekday morning at 9 AM with the order.
Pulls the attendee list from a Google Spreadsheet, allowing easy updates.
This post walks through the entire setup, including code snippets, Slack integration, and lessons learned.
From time to time, your direct report or colleague will take extended time away from work. It could be a parental leave or a sabbatical or an extended time off to take care of personal things. Whatever the reason, when they come back, they are going to be overwhelmed by the thousands of Slack and email notifications that they have missed while they were away.
