Live data from Hacker News

On Being A Senior Engineer

kitchensoap.com

21–29 of 29 posts

Re: On Being A Senior Engineer

#21
post #11

Still reading, but before I forget to ask: "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 t…

Linus is a special case. When your work powers most of the computers out there, I guess you can say fuck all you want. Plus its not like he goes around saying fuck to everybody. Its to the people that piss him off. He is a target for assholes because insecure little bitches will always try and prove him wrong. Its part of the culture around computers. But hey, if it wasnt for him I would be using Windows. So fuck anyone who doesnt like the way Linus talks.

Re: On Being A Senior Engineer

#22
post #3

"At the peak of your game" after 5-10 years might be true. How would be the market for a "senior" software engineer of 20+ years experience? I have a feeling such a candidate would be deemed "too technical to manage, too senior to be managed".

"Too technical to manage" would depend on the skillset of the engineer. If they're one-dimensional in passion or ability (code is ALL!) then I'd say that's true, but it's no less true for a guy with 5 years in chair.

"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.

Re: On Being A Senior Engineer

#23
post #2

When I was 19 (at which age I obviously knew everything about everything), I always looked down at the "senior" guys, they looked outdated, conservative, full of useless knowledge on things such as Cobol, or C. I eventually got to make friends with several of the "dinosaurs", and got shocked to discover that I was paid more than they were. Fast forward 15 years, I'm now full of experiences. I deployed apps with billi…

"I eventually...[was] shocked to discover that I was paid more than [the dinosaurs] were." Freudian slip? I think you mean the opposite going by the rest of your story. ;)

no, I actually mean I was overpaid (or the dinosaurs were overpaid - I'm not sure) - and so are a lot of 19-year-olds I keep working on from time to time...

Re: On Being A Senior Engineer

#24
post #20

> No one should be allowed to avoid the issue by the old formula, “I can’t give a promise because it depends upon so many uncertain factors.” 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 pr…

I'll add a little.

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.

Re: On Being A Senior Engineer

#25
post #20

> No one should be allowed to avoid the issue by the old formula, “I can’t give a promise because it depends upon so many uncertain factors.” 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 pr…

The difference the article is talking about is a junior engineer saying "I don't know and I don't know how to know, so I'm not going to answer your question" and the senior engineer giving estimates just like the ones you gave: "a build is at least four hours, but if I'm churning it can take several weeks".

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?
Part of a senior engineer's value is being able to see the business need to address business risks that are inherent in the question "How long will this task take", and to respond accordingly. The article touches on this too, where it discusses holistic contextual awareness.

Re: On Being A Senior Engineer

#26
post #20

> No one should be allowed to avoid the issue by the old formula, “I can’t give a promise because it depends upon so many uncertain factors.” 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 pr…

The difference the article is talking about is a junior engineer saying "I don't know and I don't know how to know, so I'm not going to answer your question" and the senior engineer giving estimates just like the ones you gave: "a build is at least four hours, but if I'm churning it can take several weeks". Junior engineers don't know that an estimate like that is possible to give and provides value. They're often br…

[deleted]

Re: On Being A Senior Engineer

#27
post #4

Apologies if it's off-topic, but it matters for for anyone who wants to read the link in the article from locations where FB/Twitter are blocked. Is there a bookmarklet that will get rid of Quora's annoying "you must login with FB or Twitter" page blocker?

I manually edit and remove elements. There's the RIP (remove it permanently) plug-in for Firefox. Styleish for Chrome can do similar things.

Re: On Being A Senior Engineer

#28
post #23

Earlier quoted context omitted.

"I eventually...[was] shocked to discover that I was paid more than [the dinosaurs] were." Freudian slip? I think you mean the opposite going by the rest of your story. ;)

no, I actually mean I was overpaid (or the dinosaurs were overpaid - I'm not sure) - and so are a lot of 19-year-olds I keep working on from time to time...

* I meant "or the dinosaurs were underpaid. Ouch.

Re: On Being A Senior Engineer

#29
post #23

Earlier quoted context omitted.

"I eventually...[was] shocked to discover that I was paid more than [the dinosaurs] were." Freudian slip? I think you mean the opposite going by the rest of your story. ;)

no, I actually mean I was overpaid (or the dinosaurs were overpaid - I'm not sure) - and so are a lot of 19-year-olds I keep working on from time to time...

Yeah, I misread that part when I wrote the comment...
Post reply on HN