A staff engineer ships the last migration script, hands the client a clean handoff doc, and closes her laptop. Six months later, the same client emails her lead: "Is she free? We have another one." Down the hall, another engineer wrapped a similar project the same week.
Same title, same rate, similar Git history. Nobody emails him about the next one. The difference between those two outcomes rarely shows up in a performance review. It shows up in a set of small signals the client's team has been tracking, mostly without saying so.
The engineers who get rehired have made a series of decisions the merely competent ones haven't. Not louder decisions. Better ones. For a deeper read, see this guide to the habits that make a developer worth keeping — the pattern repeats across every list worth reading.
Decide Whether You're Solving the Ticket or the Problem
The ticket says "add a filter to the reports page." The real problem is that the finance lead has been exporting to a spreadsheet every Monday for two years because the filter she needs hasn't existed. An engineer who ships the ticket exactly as written hasn't done anything wrong. An engineer who spends fifteen minutes asking why the ticket exists, then proposes a filter that also covers the Monday export, has done something the client is likely to remember when the next budget cycle opens.
This is the first fork in the road, and it's easy to miss. Solving the ticket is safe and fast. Solving the problem takes a conversation, sometimes a small negotiation on scope, and the willingness to say "the thing you asked for won't get you what you actually want."
The trade-off is real: over-scoping every task turns you into the engineer who can't finish anything. Under-scoping every task turns you into the engineer who finishes a lot of things that don't matter. The rehired ones learn to tell the difference case by case, and they earn the room to make that call by being right more often than not.
Decide What a Code Review Comment Is For
Every review comment is a choice about what kind of teammate you want to be. You can flag a naming inconsistency. You can flag a subtle race condition. You can flag both, and bury the second one under the first.
Careful engineers catch a lot. Senior engineers catch what will hurt in production and say so plainly, in a tone that doesn't make the author defensive. That is the habit that shows up in reviewers people want to work with again.
Spend Your Jargon Carefully in a Room of Non-Engineers
The meeting has a product manager, two people from operations, someone from legal, and you. Somebody asks why the migration is going to take three weeks instead of one. You have about ninety seconds before their attention drifts. Every technical term you use is a small withdrawal from a limited account: spend it on the two ideas that matter, and translate the rest.
Communication isn't a soft skill layered on top of the engineering — it's part of the engineering itself. A design nobody outside the team can defend is a design that gets cut in the next round of prioritization.
The engineers who get rehired write short update notes a non-technical sponsor can forward without editing. They flag risk early, in language a finance director can act on. They resist the temptation to sound smart at the expense of being understood.
Decide Which Metrics You'll Let Define You
Someone, somewhere, is measuring your output. Lines of code, tickets closed, PR throughput, story points. Most of these numbers are worse than useless when applied to individuals: they reward the engineer who writes more code over the one who deletes the right code, and they punish the engineer who spent Tuesday helping a teammate debug a nasty concurrency bug.
A widely shared response to McKinsey by Gergely Orosz and Kent Beck laid out the case in detail: individual developer productivity metrics distort behavior long before they produce insight.
You can't stop teams from measuring. You can decide which numbers you take seriously. Team-level outcomes, the ones covered in the DORA and SPACE frameworks, hold up better than any personal scoreboard: deployment frequency, change failure rate, time to recover, and the sociotechnical factors that make good work possible.
Talk about your work in those terms and you shift the conversation from "was I busy?" to "did the system get better?" The second question is the one that gets you invited back.