alt Hacker NewsI like the post but I’d add senior is also the instinct to take risks. I was once at a client in NY with an ASP.NET code base that used the compile at runtime capability (like Java used to). The C# source was being pushed to the web server.
I ran a compile and the code was riddled with errors. So I went to the PM and explained the code needed to compile and I needed a day to clean it up.
I refactored the entire project to compile and deploy that way. After that the development went very fast.
The hilarious part was the three devs who’d gone on vacation came back and thought what I’d done was “wrong”.
But the client said we (consultants) had done in two weeks what they couldn’t do in six months.
That’s what a senior engineer does.
Replies
I would like to propose a counter perspective.
You mentioned receiving approval after providing a persuasive justification - to me it implies that you were not in the position of making the decision, rather it was up to someone else and under their supervision?
Should Senior then more correlate to the value of curating ideas, mining for conflict, gathering consensus, and execution; while operating tactfully and methodically within certain bounds of composure/temperament?
I'm not familiar with C# compile at runtime. Are you saying your change was to do an AOT compile locally?
> But the client said we (consultants) had done in two weeks what they couldn’t do in six months.
I think this is more of a consultant vs employee thing than it is senior vs not-senior. There's this weird dynamic that happens where BizOps defaults to trusting and spending more on consultants, granting them more autonomy, such that they're wildly more empowered to take any risk. Employees are to be delegated to by BizOps, and BizOps doesn't like taking risks. It's paradoxical, because unless you come in with that authority or you were there extremely early, you're unlikely to acquire it, much more-so after the company's been around a few years.
This seems to me where the term "hired gun" comes from. You pay someone who's incentivized to solve a discrete important problem with their expertise quickly, whereas all of your employees are incentivized to do things for amounts of time reliably over however long, answering to product managers, implementing whatever crap to get the sale, answering to useless managers every two weeks, planning, reviewing, retrospectiving, blah blah. The consultant isn't about to go doing a broad-scale refactor if they're not paid to, and there's no reason an employee should either.