4 ms·

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 t

by msoad 5y ago

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!

elnygren 5y ago
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?
- msoad 5y ago
  “The committee”. Directors sit on it. I have lots of good relationships with most directors in my org.
twblalock 5y ago
> 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.
- H8crilA 5y ago
  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.
  - msoad 5y ago
    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
    - ignoramous 5y ago
      > ...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.
    - lifeisstillgood 5y ago
      >>> They are written to make a case for not prompting people. They are not guideline Insightful - thank you
rootusrootus 5y ago
> 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.
- colmvp 5y ago
  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.
  - msoad 5y ago
    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.
  - rootusrootus 5y ago
    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.

by msoad 5y ago

elnygren 5y ago

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?

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

twblalock 5y ago

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

H8crilA 5y ago
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.
- msoad 5y ago
  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
  - ignoramous 5y ago
    > ...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.
  - lifeisstillgood 5y ago
    >>> They are written to make a case for not prompting people. They are not guideline Insightful - thank you

rootusrootus 5y ago

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

colmvp 5y ago
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.
- msoad 5y ago
  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.
- rootusrootus 5y ago
  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.