Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Staff Engineer's Path – Book Review

smyachenkov.com

Post reply on HN
Print view View original

191–200 of 251 posts

Re: The Staff Engineer's Path – Book Review

#191

Post by [deleted] »

sibeliuss wrote: post #109
timacles wrote: post #94

Earlier quoted context omitted.

The thing that separates those guys from everyone else is simple. Its stamina. No there isn't some higher level of understanding or deep perception. Every one of the all time great programmers had 1 exact thing in common with no exceptions. Stamina. You will not find a single outlier. They did their craft every day, for many hours, year after year. So sure, any of us could have taken the individual small steps. But w…

This is the answer. There's certainly ridiculous talent (especially with ideas), but in my experience it always comes down to stamina stretched through time. Cool things get built by people that stick it out, and recruit others to do the same. And also know _exactly_ when to exit to pursue something new (but that's a different subject).

[deleted]

Re: The Staff Engineer's Path – Book Review

#192

Post by hintymad »

My archetypal staff engineer is Wernher von Braun, father of Saturn V. The quality he demonstrated:

  - Breaking ground. He turned a seemingly impossible idea into reality. 
  - Getting substantial breakthrough in each iteration. 
  - In the trench. He was the designer of multiple rockets, and he was the person who solved tough engineering problems and pushed the boundary of rocket science. 
  - Leadership. He knew what he had to know deeply and what he could delegate, and he unblocked his teams whenever needed.
In contrast, the Staff Engineers I see in many companies are technical product managers, skilled coordinators, excellent box drawers, and masters of jargons. They do everything but engineering. You can probably identify them easily as their resumes are full of phrases like "uber technical leader" or "coordinated across 100 teams". Their careers depend on how lucky they are to find an effective team to execute. Mind you, this sounds like my blame, but it's really not. If anything, it's my lament. Those engineers were deeply technical before they got promoted. It's just that sooner or later, the leadership needed someone who could communicate up and down and around. The staff engineers would need to show up in more and more meetings, "align" more and more teams, conduct more and 1-on-1s to build relationships, draw more and more boxes to appease the "stakeholders". Sooner or later they are busy in meetings all day, they are no longer in the trench, and they get comfortable with throwing terms like BERT and Raft and what not without knowing the underpinning theory or implementation in a coherent way. Of course, there's nothing wrong with such roles and they will continue doing well in their positions. It's just that I'm not sure such job would give me much satisfaction.

Re: The Staff Engineer's Path – Book Review

#194

Post by michaelsalim »

proc0 wrote: post #116
coliveira wrote: post #102

Earlier quoted context omitted.

> Where do all the hardcore engineering jobs live There is NO such thing as hardcore engineer job position that doesn't involve a lot of management. All the good engineers that get jobs are the ones who do management work as well as coding. If you cannot do this, the industry will just close its doors for you.

In my opinion this is a big reason software is so brittle, needs to be constantly patched and updated, and overall innovation in software moves very slowly. Having engineers do management work is undermining how hard engineering is -OR- underestimating how powerful software is. In other words, the Idea is that engineers adds more value to a company if they also do all these management tasks, which implies that engine…

I see it in a completely different lens. Engineering is hard. Good engineering more so. What's even harder is to manage those projects well without having the technical skill to understand it. Whenever I find a technically challenging & innovative project, there's always a technical lead/manager that makes it all possible.

Re: The Staff Engineer's Path – Book Review

#195

Post by ww520 »

Xeoncross wrote: post #15

Where do all the hardcore engineering jobs live? I've been bothered by the fact that most advanced engineering roles like "staff" actually mean "manager who does system design as well" Where are the docker/redis/next.js/linux kernel/qt/roller-coaster tycoon creators? Where are the people creating amazing software and do they get a special "advanced developer" title? I guess, I'm curious if there are actual roles in c…

At staff and principle level, the job becomes mentoring and working with other senior people under you. There might be a business need/problem, and you have the vision to address it. You gather the requirements, do feasibility studies, evaluate the technologies, nail down the architecture, design the components, and work closely with other senior engineers on the prototype/design/implementation. You might code up the prototype and proof of concept during the exploratory phase. You might code up couple components you believe you're the expert in doing it.

At the end of the day, you're the voice and the advocate to ensure your end-to-end vision is implemented.

Re: The Staff Engineer's Path – Book Review

#196

Post by pkd »

0xbadcafebee wrote: post #135
charcircuit wrote: post #73

Earlier quoted context omitted.

Staff engineers aren't "rockstar 10x IC."

It's certainly how they market themselves. Look how great we are, we're leaders, we're mentors, we're leaders, we think bigger, we make a bigger impact, blah blah blah. And it's a crock of shit. It's not up to an IC to decide strategy, make executive decisions, or lead a team, unless Lead or Manager is in their title. Thinking big, prioritizing, choosing what to work on, etc, is something every engineer should learn…

I certainly agree that reading these books won't make you have the skills needed to be a Staff engineer but I think the rest of your point seems highly biased by your individual personal experience.

Btw, Will Larson was at Etsy in a very senior role for a while, so he definitely knows how engineering orgs work.

The reason I see for these books existing is because engineering orgs have evolved and grown to a scale where a new role came up: of an individual contributor that exercises cross team influence. This only makes sense in massive (1k+ engineers), highly organisationally flexible companies. It doesn't make sense in small ones and it doesn't make sense in inflexible ones. Those sorts of companies have not existed for too long.

BTW Will Larson's book is a synthesis based on the collection of anecdotes from people actually employed with such titles across companies, so you can read it and see if those things make sense.

Re: The Staff Engineer's Path – Book Review

#197

Post by rhtgrg »

0xbadcafebee wrote: post #43
JackMorgan wrote: post #12

Earlier quoted context omitted.

Titles are very much diluted. I've seen companies hire college sophomores who have never heard of the concept of a database and make them Sr Engineers on a analytics teams. I've seen Sr Engineers hired with one year of relevant experience. At this point, "Sr Engineer" is just the new "Jr Engineer". There's nothing wrong with this, but indeed, Staff Engineer tends to mean 8+ years of experience.

It's because we still have no standards as a profession. Whatever bullshit trends in silicon valley, suddenly everyone follows it, petrified that they might get left behind or are missing some important new thing. I remember when Systems Administrator was a noble and important profession full of smart, talented people. But a lot of people misunderstood it and made fun of it, so it became an unattractive title, and in…

Funnily enough, the author of this book started out as a systems admin.

Re: The Staff Engineer's Path – Book Review

#198

Post by _gabe_ »

nonethewiser wrote: post #90
onion2k wrote: post #74

Earlier quoted context omitted.

Where are the docker/redis/next.js/linux kernel/qt/roller-coaster tycoon creators? Something I learned relatively late in my career was that really impressive work is the result of iterations in tiny steps. When you see something that makes you go "WOW! I could never do that!" you're seeing the final result of a long journey, and you probably could have taken each small step with a bit of effort. There's no need for…

> Something I learned relatively late in my career was that really impressive work is the result of iterations in tiny steps. I think you are right. Really impressive work is generally the result of a longer journey than you realize. The time and effort put into it is probably underestimated. But my mind immediately tries to think of exceptions (which totally prove the rule). I'm curious if others would agree with th…

> Even still, the fact that the core game can be recreated without too much effort does suggest that that it was more about being a good idea than being difficult to implement

As someone that's "recreated the core game" a few different times using a few different techniques (Unity, then Unreal, then OpenGL twice) this just isn't true. Minecraft is very deceptive in the fact that it looks simple, but recreating the core of Minecraft alpha is incredibly time consuming and difficult. Most of the clones you see don't truly recreate the core either, they'll add very simple biome generation, chunking, and some player movement and lighting.

The core of Minecraft alpha consisted of: mobs, "smart" blocks (fences that join to other fences, interactable blocks, animatable blocks etc), water, lava, physics, pathfinding AI, inventory management, crafting system, Redstone (this is actually pretty huge because it's not trivial figuring out how to properly update chunks), multiplayer networking (also not trivial by a long shot), survival mode, biomes and the nether.

Just building the base game with all of that will take around a year of full time dev work, which it did take Notch around that much time. Additionally, making all of these systems good and fast is a whole 'nother story. There are so many optimizations that can be made that add a lot of extra dev time to the mix.

So, sure, creating a cool blocky chunk renderer where you can add and break blocks can be done in like a week. But Minecraft alpha is not a simple endeavor, and I don't think it would have taken off the way it did if Notch just left out all the actual game mechanics.

> I don't look at Minecraft and think "wow I could never do this." Instead I look at it and think, "Wow. That was a really great idea."

And again, I know what you mean by this because I thought the same thing, but this couldn't be further from the truth! It's funny how I wildly misjudge the amount of effort that making a thing takes until I try to make that thing.

And we also have to remember that before you can even begin to create Minecraft you need all the prerequisite knowledge of how the graphics pipeline works and how rendering in general works. But anyways, I just wanted to interject some personal experience here and mention that a lot of the "simple details" cough multiplayer are actually pretty tough to pull off :D

Re: The Staff Engineer's Path – Book Review

#199

Post by a_bonobo »

biscuits1 wrote: post #120
timacles wrote: post #94

Earlier quoted context omitted.

The thing that separates those guys from everyone else is simple. Its stamina. No there isn't some higher level of understanding or deep perception. Every one of the all time great programmers had 1 exact thing in common with no exceptions. Stamina. You will not find a single outlier. They did their craft every day, for many hours, year after year. So sure, any of us could have taken the individual small steps. But w…

Stamina isn't the word I would go for. It would be commitment. For those that have loads of stamina, it's the commitment to continuous creative encounters that leads to the perceived magic. From "Courage to Create" by Rollo May: "It is said that the novelist Thomas Wolfe, who was one of the highly creative figures of the American scene, that he was a "genius without talent." But he was so creative because he threw hi…

Commitment from the individual, and commitment from your organisation!

I work in a relatively 'flat hierarchy' so there are few organisational structures and proceedings that keep projects on track. It's only me that keeps the marble on the track, there are no organisational tracks. Once I lose interest or stamina the marble is gone.

Other organisations with regular check-ins, project tracking etc. have a system that at least keeps the marble in place.

Re: The Staff Engineer's Path – Book Review

#200

Post by am44jnsf »

biscuits1 wrote: post #120
timacles wrote: post #94

Earlier quoted context omitted.

The thing that separates those guys from everyone else is simple. Its stamina. No there isn't some higher level of understanding or deep perception. Every one of the all time great programmers had 1 exact thing in common with no exceptions. Stamina. You will not find a single outlier. They did their craft every day, for many hours, year after year. So sure, any of us could have taken the individual small steps. But w…

Stamina isn't the word I would go for. It would be commitment. For those that have loads of stamina, it's the commitment to continuous creative encounters that leads to the perceived magic. From "Courage to Create" by Rollo May: "It is said that the novelist Thomas Wolfe, who was one of the highly creative figures of the American scene, that he was a "genius without talent." But he was so creative because he threw hi…

it's not even commitment. it's discipline. many of us know what we should be doing, and how to do each of these small steps. most of us (including me) don't have the daily discipline to pull it off.
Post reply on HN