3 ms·

Tell me you've never functioned as a Staff Engineer without telling me... More seriously, please listen to what every other prominent staff+ engineer here, in

Tell me you've never functioned as a Staff Engineer without telling me... More seriously, please listen to what every other prominent staff+ engineer here, in blogs, on Twitter, even within FB, etc. has to say about the job. There are a great many takes, but by far the most common thread is that the most important part of the role is almost never about code. Many complain about not having time/energy to code any more. The whole point of having this as a role/title is to give leverage to those who have proven they can use it for the good of the organization. That means maximizing the ratio of effect to code written, by themselves or anyone else, and there are a great many ways to do that. "Code is all" is the hallmark of the very junior engineer who hasn't finished climbing that first rung yet - a very important rung, yes, but still only one of many. TBH it comes across as something between sour grapes and Tall Poppy Syndrome.

icedchai 4y ago
In my last staff engineer role I spent more time writing "design specs" (which were rarely looked at) and doing code reviews than I did doing actual coding. Also way too many meetings. I found it pretty draining mentally.
gautamdivgi 4y ago
To be fair you won’t have time to do a lot of code. I would even doubt code reviews. If you’re setting up initiatives that cross several organizations - the most critical aspect is getting down features, interfaces and guarantees down. Define ways to measure these and get out of the way. If you’re too deep in the weeds you could end up causing more damage and delays. See if you can get out of day to day meetings and find an interesting project to work on, hopefully as open source if your company powers that be agree. But with your title you will have an easier time getting that through.
lmm 4y ago
Code is a liability, but it's very often the least-bad option. In particular it's severely underrated as a communication mechanism; all too often people go through weeks of planning and discussion to save hours of prototyping.

icedchai 4y ago

In my last staff engineer role I spent more time writing "design specs" (which were rarely looked at) and doing code reviews than I did doing actual coding. Also way too many meetings. I found it pretty draining mentally.

gautamdivgi 4y ago

To be fair you won’t have time to do a lot of code. I would even doubt code reviews. If you’re setting up initiatives that cross several organizations - the most critical aspect is getting down features, interfaces and guarantees down. Define ways to measure these and get out of the way. If you’re too deep in the weeds you could end up causing more damage and delays. See if you can get out of day to day meetings and find an interesting project to work on, hopefully as open source if your company powers that be agree. But with your title you will have an easier time getting that through.

lmm 4y ago

Code is a liability, but it's very often the least-bad option. In particular it's severely underrated as a communication mechanism; all too often people go through weeks of planning and discussion to save hours of prototyping.