In my experience, it's not technical knowledge that makes me view someone as a "go to" engineer: it's reliability. I don't like surprises from anybody when it c

In my experience, it's not technical knowledge that makes me view someone as a "go to" engineer: it's reliability. I don't like surprises from anybody when it comes to work, and I really respect engineers who can deliver thoroughly and on time without surprises in code quality. Getting something done on time can be tricky, but the hallmark of a "go to" engineer is that, if something's going to slip, they speak early about it. Going down a rabbit hole is a bad thing, but going down a rabbit hole without telling people and checking back to see if you still need to be down there is worse. Getting something done thoroughly means, to me, that you've written code that is tested and is reasonably robust given the nature of what you're doing. Code that lacks null checks (if you're in a language where that's a concern) is not robust. Code that doesn't handle obvious errors is not robust. Code that doesn't have any tests with it is not robust. Code quality is a matter of taste, but what it boils down to is how well code follows the established patterns in the codebase or, if those patterns need to be changed, how well the new solution solves problems the old pattern exposed. Most development does not take place in a vacuum, and if someone goes off and does a lot of extraneous refactoring, everyone else has to pay the price of merging their work together and acclimating themselves to whatever's changed. Frequently, large refactors aren't worth that cost, and a "go-to" engineer is going to understand that balance and err on the side of getting things done versus getting things perfect.