Fast forward 15 years, I'm now full of experiences. I deployed apps with billions of transactions per day, led teams big and small, learned that there's more than one side to everything and that "The True Solution" is nothing but lack of experience in disguise. Most importantly, I discovered I don't know anything.

I'm still shocked, sometimes, when I see arrogant 19-year-olds bending reality to convince people they're right - and getting paid more than us, dinosaurs... :)

Freudian slip? I think you mean the opposite going by the rest of your story. ;)

STRONGLY disagree.

I've worked on projects where:

- Getting a stable build might take four hours (minimum) to several weeks (depending on churn);

- Processes for adding components were undocumented magic, and very nearly undebuggable;

- Components might take days or weeks to propagate, once you were finally able to make changes to them.

Debugging is a similar story. Some bugs are nasty, horrible, complex things that take a lot of time. I've seen showstopper-class kernel level bugs take months to find. The nature of interactions at the hardware / software interface is unbelievably complicated.

So what does a "senior" engineer do?

- Communicate the nature of the problems in a non-whiny way.

- Give responsible estimates. "Three days or a month" is honest, if you say why.

- DON'T promise results that you can't actually deliver.

- Be prepared to have features cut, and to have conversations about things that you consider less than optimal ("sucky") for the customer.

Naturally, your senior engineer is also trying to improve the sucky situation the whole team finds itself in (with better tools, build processes, whatever), but some situations are intractable.

I do see this a lot in less experienced engineers. "I can't tell you when X will be done." On the other side, I see people promise stuff they can't possibly deliver (due to pressure from management, or simple optimism, or plain cluelessness about the difficulty of a problem).

So part of a senior engineer's job is to notice when someone is making bad estimates and correcting the issue. This can range from simple conversation with the engineer, to diving in and helping out, to getting someone transferred or terminated for unfixable cluelessness.

Some good tools:

- Socratic method. "What don't you know? Can you figure it out?" Repeat. Also, deep examination of base assumptions ("Are you /sure/ you know XXX? Let's dig into that for a bit.")

- Crap shield. "Look, leave Figby alone for a few days until he works this out. It'll give him confidence and make him a better engineer."

- Crap generator (use this sparingly). "What that guy is doing just isn't very hard, and he's not doing a good job. Have one of ours do it instead, and have your guy do something else." Bring ironclad evidence to the table on this one, because this conversation usually precipitates a firing.

The old saw of "Good. Fast. Cheap. Pick two." is so over-used, but it is /so/ damned true.

We've been engineering bridges for thousands of years, and we have a pretty good handle on what makes a good bridge. In software, I've come to think of the engineers /as/ the bridges, and we can't engineer a better engineer yet.

Junior engineers don't know that an estimate like that is possible to give and provides value. They're often brow-beaten by lots of project managers who don't get the value of an estimate like that, who'll just press you for a single number that you'll commit to, the closer to the low end the better. But actual business managers can hear that estimate and make a business decision:

    a) I need the build in 15 minutes for a demo... sounds like that's not possible, so skip it.
    b) I going to need the build to be stable in two months. You'd better get started now, and I should be ok.
    c) Hmm... I need it next week. Seems we have a business risk here. How can we mitigate that?

I've worked with some assholes that could easily be referred to as mature engineers. Being assholes or not wanting to work alongside them didn't really detract all that much as they could get the job done and there was a lot to learn from them. I'm not sure the author is correct about personality being a part of a senior engineer - or a senior executive - as far too many of those seem to be assholes by definition!

"It’s a junior engineer mistake to toss insults about a piece of complex technology in 140 characters."

Does everyone agree with that? I have seen many senior engineers, specially in open source world, who aren't afraid to use the 'F word' publicly to insult a technology, or even an organisation (Linus vs. Nvidia?).

Does an engineer really have to be super formal in how he talks online? Isn't it fun to be a bit more open at times than what 'maturity' requires?

That said, I'm just as terrible as the next guy.

I have a feeling such a candidate would be deemed "too technical to manage, too senior to be managed".

"Too senior to be managed" has at least as much to do with the insecurities of the manager than it does the engineer. If you need to be the smartest guy in the room, then you'll surround yourself with lesser talent. If you understand your role of manager is to remove obstacles for those who do their specific roles then you'll be more likely to search out experienced people that GSD.

I've always thought that "earlier intellectual experience" was a necessary but not sufficient condition to extraordinary work. Each of us gets there in our own time frame.

Is there a bookmarklet that will get rid of Quora's annoying "you must login with FB or Twitter" page blocker?

- mature engineeer :P