Hacker News Reader

Comment by msoad | Hacker News Reader

Where I work almost all capable engineers are Staff Engineers. Based on the rubrics provided to make sense of our responsibilities we need to “initiate work that has org-wide impact”, “influence the company’s technological direction” and drive large scale multi-team projects.

Looking at my change lists from last year, I made a bunch of new models in our backend and wrote a few pages in React. Added monitoring, alerting and shipped the product pages. You know, your typical “software engineering” work.

What’s amazing is that I keep getting “exceeds expectations” ratings for this work because I ship things PMs want.

The hard part is self review time where I put my fantasy novel author hat on and spit out some bullshit on how my React components changed the technological direction of the company. Maybe this skill is what makes me a Staff Engineer!

View on HN

> What’s amazing is that I keep getting “exceeds expectations” ratings for this work because I ship things PMs want.

This is surprisingly underrated, I know a lot of senior engineers that struggle with it. The best thing I ever did for my career when I started professional software development was realize that my manager and my customers did not care about tech stack choices, or perfect software. All they cared about was that it shipped, and in a reasonable time. They could handle some bugs as long as I fixed them.

I still have to tell some engineers with 10-15 years experience to stop navel gazing over the tech choices, and get the damn software out the door already.

I left my past company in part because all they cared about was shipping by some ridiculous time frame.

While it certainly helped my ability to look good to PMs and other programmers, it made for un-scalable, un-readable, and un-maintainable code. My company lost tons of developers due to the constant punting of code debt. It might be easy to say push back on clients but the dev team rarely had that ability unless it was a nice client. Ugh, so glad I found a better company.

Change your team or company every 2 years. Always pick greenfield projects so you can feed your tech stack curiosity. Code usually starts to rot in 18 months mark.

Nobody cares about high quality code in a corporate environment neither should you. They're going to toss your code out of the window when some MBA from McKinsey & Co. comes and do "cost structuring" for your corporate.

Keep your craft for your open source projects if you _really_ want to do it. It's your code and it really matters to humanity if you make something good in th open.

I think there's an important distinction between ridiculous and reasonable time frames. If you're forced into releasing bad code because of an arbitrary deadline, then that is a problem. But I see plenty of the opposite, where programmers are so focused on perfecting their code that they fail to realize that software which never ships isn't software, it's just art.

It really isn't hard to ship perfectly good code relatively fast. I think most times when people have trouble getting code out the door without causing serious tech debt, it's because they've gone down the premature optimization rabbit hole and introduced a lot of unnecessary complications anticipating some future that doesn't yet exist.

> I still have to tell some engineers with 10-15 years experience to stop navel gazing over the tech choices, and get the damn software out the door already.

This may be an unpopular thing to say, but at most companies, you should have less senior engineers than that doing nearly all of the "get the damn software out the door already" work. The 10-15 years experience people should really be doing work with broader impact than that. And this isn't to downplay the importance of that just-get-things-done role at all! It's critically important. But it's a ratio thing; most companies should have a lot of earlier career folks implementing things and a few later career (or just very high achieving) folks setting technical direction, discovering and advocating for new projects, yada yada yada. I think the truth is that lots of places have this ratio out of whack with respect to the actual availability of impactful projects to work on. If there isn't enough work for folks at Staff level and above beyond just knocking out crud apps, you've got a mismatch.

We subscribe to this philosophy on paper and it works out pretty poorly. The best managers and teams are the ones that manage to subvert it.

There's a pretty wide variation in efficacy at doing the mainstream work. It's good to retain and reward the people who are good at it, so that they make up a higher proportion of the ones doing it. Otherwise you're constantly throwing away good people and replacing them with new hires of lower/unknown quality, just because you don't have enough "strategic direction" type work to promote them.

Yeah... I guess it depends on the person. I personally felt like "just get the work out the door" lost its novelty / interest for me after about five years doing it and that I spent the next five years becoming increasingly unsatisfied with my work after that. It is more satisfying for me to have more scope over larger projects. But not every place has that kind of work available. But "just crank out the bread and butter work instead" is not a solution either, because like I said, I find that unsatisfying. So if there isn't "strategic direction" type work, for some people the choice isn't between "throwing away good people" vs. keeping them doing the bread and butter work; they are going to seek greener pastures for the kind of work they prefer doing either way. There are other people who really enjoy just knocking things out no matter how long they do it, and I agree with you that many organizations would benefit more from having lots of that kind of person.

> You know, your typical “software engineering” work.

“Typical” work, done well and on time with good production reliability, is often hard to get.

Perhaps it’s a sign of your seniority that you think that’s all typical. I’ve seen people release buggy code with no tests, metrics, or monitoring and think they were finished with it. That gets fixed when the more senior engineers step in and demand higher standards.

It’s sad that the baseline for quality in the software industry is so low, but that’s how it is.

The thing is that:

Junior -> needs monitoring ~weekly

Senior -> does eng work reliably and on time, can lead a junior or maybe a few but doesn't have to

Staff -> leads Seniors (plus maybe some juniors directly)

Grandparent is mentioning that in their org there are plenty Staffs that do not lead anyone.

Yeah. As I said the rubric makes it look like every staff engineer must make Kubernetes run in a WebWorker or invent git in each quarter.

They are written to make a case for not prompting people. They are not guideline

> ...the rubric makes it look like every staff engineer must make Kubernetes run in a WebWorker

No words for an insight as incisive as this.

>>> They are written to make a case for not prompting people. They are not guideline

Insightful - thank you

Out of curiosity, where do these ratings come from? From the PMs? Or do you have EMs who just listen to the PMs in these things?

“The committee”. Directors sit on it. I have lots of good relationships with most directors in my org.

Reply on news.ycombinator.com