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.
Your IDE thing probably only applies to a 3 person startup where one or two of them are coding.
I agree with you: fix what needs to be fixed. But that can be human things too, not just code.
And not using Kubernetes…
lolwut?
Do people actually believe these kinds of things? Like what comprehensive leadership happens solely in an IDE?
> there's no such thing as grunt work
It sounds like this messaging for people who are on a career track that will never not be grunt work. And even if the goal was to lead someone into being the best code grunt possible, how do you lead them to that point through only the code?
Most don't, no. But you'll definitely find a higher percentage of people who do at places like FB.
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.
Providing technical leadership is weird and makes people hard to rely on?
The tricky part is making all that code add up to something meaningful, though, right?
A thousand developers diligently and efficiently working away in their IDEs building completely the wrong thing is a terrible waste, and not something that can be solved by just having a staff+ ‘fixer’ come along behind and clean up.
Specifically the problem with me is I don't have deep expertise in any area. This is fine in most cases but there are areas where expertise is important. And more often than not titles and levels are a reasonably proxy for expertise in a large organization. Turns out asking "who's the expert in X" really, really doesn't work once you disregard titles and levels. Disregarding titles and levels is a good way to turn engineering into a popularity contest so "who's the expert in X" becomes "who do I know best who recently said something like X to me"
Tell that to the person writing my paychecks.
Coding ability only affects the leveling guideline between junior and mid. Everything else is about “scope”, “impact”, “managing ambiguity” and in the case of Google “writing a messenger app”
Of course these are the official guidelines.
What do people complain about at FB that they can't seem to get done there that seems really obvious that you should? You'll find similar issues. Maybe not like google, but unique to FB.
Code is just an implementation detail that solves a business problem. I can't disagree more with this take.
Unless the arguments are about "how to do the code correctly" for some value of correct that's imagined to be beneficial in the future.
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.