Live data from Hacker News

Staff Engineer Archetypes (2020)

lethain.com

211–220 of 269 posts

Re: Staff Engineer Archetypes (2020)

#211
post #149

Earlier quoted context omitted.

> Many people have been skeptical of the idea of the 10X engineer. O Nah, of course 10x engineers exist. A 10X engineer saw that hundreds of engineers were writing MPI code to process data and struggled with error handling and therefore came up with a map-reduce framework and its underlying infra. The same infra also helped bootstrap a whole industry. In this case, we are talking about 10^6X engineer. Another 10X eng…

Were each of these really achievements by a single engineer, or a team? One guy wrote CUDA?

The initial version of MapReduce was conceptualized and implemented by two people (Jeff Dean and Sanjay Ghemawat). Those were the only names that appeared on the paper: https://static.googleusercontent.com/media/research.google.c...

Re: Staff Engineer Archetypes (2020)

#212
post #65

Earlier quoted context omitted.

I usually think of an at-work "politician" as somehow taking advantage of relationships or social forces. What you describe sounds more to me like the ""10X engineer"" (with extra scare quotes for good measure). Many people have been skeptical of the idea of the 10X engineer. One take is that if your normal engineers are less than 1/10th as productive as another engineer and all of them are merely human beings, there…

> Many people have been skeptical of the idea of the 10X engineer. Why is 10x anything such a skeptical concept? We see it everywhere. We see it in quality, impact, and effort. Linus wrote git in days, and it was way better SVN. Messi is probably 100x better in terms of stats and skills and 100000x better in terms of earning when comparing to an average soccer player Apple's iPod is 10x better than Zune and makes 100…

> Linus wrote git in days, and it was way better SVN.

Linus designed and coded some data structures, and some basic utilities to manipulate and store them, in just a few days - based on a fundamentally better model and as a replacement for an existing product they could no longer use. Designing and developing git into a usable product and system took a whole lot longer and involved thousands of people.

The examples you cite are all similarly flawed gross simplifications or mischaracterisations.

I urge you to reconsider your reasoning.

Re: Staff Engineer Archetypes (2020)

#214
post #126

This is jaded and angry, but I think there is another archetype called "the politician." They play the game extremely well, providing poorly thought out solutions quickly to problems they haven't dug into the complexity of. They lay operational traps everywhere in their quest to get things done fast (like directly embedding config data in code to avoid fixing the config format). Once they've picked the low hanging fr…

How does that work exactly? I can absolutely commit an unmaintainable mess directly to master, but I’d be very quickly called out by my team.

It works because management is bought into the politician's bullshit. So if another team member tries to call it out, then the manager labels the other team member as "hard to work with" (https://lethain.com/hard-to-work-with/) instead of holding the politician accountable.

Re: Staff Engineer Archetypes (2020)

#215

It's only the other month that I actually realised having these as distinct roles - team lead, architect - has completely fallen out of fashion.

Team lead seems pretty common still. But architect ya… kinda a bad word heh.

Which really does explain a lot about what's wrong with the current state of art :)

Re: Staff Engineer Archetypes (2020)

#216

I'd add "The Gardener". The gardener just wants to tend to things, taking thankless cleanup work and iterating away on it. Ops, metrics, tech debt, ACLs, pruning dead code, etc. Some people just like to organize and clean things up.

Most orgs would not consider this staff-level work. Doesn't mean you shouldn't get your hands dirty every once in a while and it could even be helpful for "dogfooding" purposes but if that's all you ever do that's not Staff.

Re: Staff Engineer Archetypes (2020)

#217
post #65

Earlier quoted context omitted.

I usually think of an at-work "politician" as somehow taking advantage of relationships or social forces. What you describe sounds more to me like the ""10X engineer"" (with extra scare quotes for good measure). Many people have been skeptical of the idea of the 10X engineer. One take is that if your normal engineers are less than 1/10th as productive as another engineer and all of them are merely human beings, there…

> Many people have been skeptical of the idea of the 10X engineer. O Nah, of course 10x engineers exist. A 10X engineer saw that hundreds of engineers were writing MPI code to process data and struggled with error handling and therefore came up with a map-reduce framework and its underlying infra. The same infra also helped bootstrap a whole industry. In this case, we are talking about 10^6X engineer. Another 10X eng…

Look up Jeff Dean:

https://research.google/people/jeff/

Re: Staff Engineer Archetypes (2020)

#218

It's only the other month that I actually realised having these as distinct roles - team lead, architect - has completely fallen out of fashion.

Team lead seems pretty common still. But architect ya… kinda a bad word heh.

Dedicated team lead is becoming more rare. Teams like to do per-project "leads" (where most of the time it's a single-person thread of work). This is commonly justified by "velocity" and bus-factor concerns. I am personally very skeptical of this fashion trend...

Re: Staff Engineer Archetypes (2020)

#219
post #10

Avoid all these other types except Solver (we call it Fixer at FB). Anyone who calls themselves these things is weird, and will be hard to rely on. Disregard levels. Disregard titles. Fix what needs to be fixed. Unit tests, CI, docs, there's no such thing as grunt work. Real leadership happens in the IDE and only code matters - everything else is overhead.

Code Wins Arguments

Given a choice between telling most of my former CTOs/Directors at smaller companies

a: we can write code to do $x undifferentiated heavy lifting

B: can we throw money at a third party to solve $x

The answer is almost always B:

The question is always will writing this code give us a competitive advantage/help us go to market faster/impress the VCs to give us more money.

Or

“Does it make the beer taste better?”

I’m just as proud of the code that I had sense enough not to write as I am the code that I did write.

Post reply on HN