6 ms·

Avoid all these other types except Solver (we call it Fixer at FB). Anyone who calls themselves these things is weird, and will be hard to rely on. Disregard l

by voz_ 4y ago

Avoid all these other types except Solver (we call it Fixer at FB). Anyone who calls themselves these things is weird, and will be hard to rely on. 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.

mi_lk 4y ago
only code matters is a stretch but generally agree. If you can fix whatever shit is thrown at you, you have my ultimate respect
- edmundsauto 4y ago
  I think the FB slogan is “code wins arguments” which is slightly different.
throwaway1777 4y ago
That’s old school FB. Is it still like that?
skizm 4y ago
> Disregard levels. Disregard titles. Tell that to the person writing my paychecks.
gorgoiler 4y ago
Code Wins Arguments
- Supermancho 4y ago
  > Code Wins Arguments 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.
  - yamtaddle 4y ago
    Shit these days I consider writing code the failure-state that happens when I'm too dumb or inexperienced to figure out how to avoid writing code.
- scarface74 4y ago
  Given a choice between telling most of my former CTOs/Directors at smaller companies 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.
chrisseaton 4y ago
> Anyone who calls themselves these things is weird, and will be hard to rely on. Providing technical leadership is weird and makes people hard to rely on?
Thaxll 4y ago
Unit tests, CI, docs this overhead, I want move fast and break things.
vanjajaja1 4y ago
I agree that code is what matters, but whats your take on writing code vs influencing people who write code? Seems to be a trade off, but it seems to me that eventually you can't write code as fast as you can influence other people who write code...
- dasil003 4y ago
  Or worse, other programmers are destroying the value of your code faster than you can create it because the underlying vision and principles beyond your chosen abstractions is not clearly communicated.
summerlight 4y ago
Oh no, managers in technical teams are usually doing their jobs not because it's fun and exciting but there's no other people who is willing to do those "grunt works" around people. Real leadership happens in the team, not code; code is just a (rather inaccurate) reflection of organization and business. It's correct that it's important to keep it close to the reality, but that's done by people and teams.
Matthias247 4y ago
Only that pure code also doesn't matter if it's either not needed required at all due to different business/customers requirements or if problems could be solved easier with a different and easier to maintain set of code if system architecture and interaction between teams would change.
quickthrower2 4y ago
Only code matters is a weird take. Even excluding sales, marketing, strategy and other functions, just within Engineering, having people who unblock other people, deal with cross cutting concerns, make sure the new starter in them team doesn’t leave because everyone else was too busy to help them, etc. are critical. 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.
- mmmpop 4y ago
  Is it technically ironic how often that the "antisocial coder" who revels in their maladjustment wants to then give their opinions about how organizations of people ought to structure themselves??
- scarface74 4y ago
  It really doesn’t apply then. At that stage knowing what to write and finding product market fit is far more important. And not using Kubernetes…
deleted 4y ago
[deleted]
hideo 4y ago
I consider myself a 'Solver'/'Fixer', mainly because that's the title others gave me, and I mostly disagree with this. 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"
dogleash 4y ago
>Real leadership happens in the IDE 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?
- pc86 4y ago
  > Do people actually believe these kinds of things? Most don't, no. But you'll definitely find a higher percentage of people who do at places like FB.
novok 4y ago
They exist to point out that there isn't only one way to define someone as staff engineer. If you don't write them out, then companies degrade into only allowing one type of archetype to get promoted, which discounts other ways of doing things, leading to a less efficient company. You see it at google in 2018: https://mtlynch.io/why-i-quit-google/ https://mtlynch.io/why-i-quit-google/ and today with the LPA (Launch, Promote, Abandon) cycle : https://nextbigwhat.com/the-lpa-cycle-at-google-launch-promo-abandon/ https://nextbigwhat.com/the-lpa-cycle-at-google-launch-promo... 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.
notacoward 4y ago
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.
virissimo 4y ago
AFAICT, the author nowhere advises anyone to call themselves by the archetype names, nor do I have reason to think that it was their intent for the reader to do so.
scarface74 4y ago
You can’t disregard levels at large organizations if you care about your compensation. The behaviors you are referring to are “mid level behaviors” according to most guidelines. 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.
jameshart 4y ago
We’re talking about organizations where there are thousands of people all writing code. 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.
0x445442 4y ago
Yeah... http://programming-motherfucker.com/ http://programming-motherfucker.com/
jonnycoder 4y ago
I've always been a solver since I have a talent/curiosity for solving problems. I've learned that you can't always be that though especially if your organization/group values feature development. Therefore there is a balance between jumping on a problem and jumping right back to what you were doing in terms of sprint stories and development work. I've been in a group where solving high priority issues was valued at like 10% and feature work was 90% and that was a bad experience learning that hard fact late.
HenriTEL 4y ago
And that's how you end up with 10 teams competing to build 10 different platforms to solve the same problem.
mehphp 4y ago
> only code matters Code is just an implementation detail that solves a business problem. I can't disagree more with this take.

by voz_ 4y ago

mi_lk 4y ago

only code matters is a stretch but generally agree. If you can fix whatever shit is thrown at you, you have my ultimate respect

edmundsauto 4y ago
I think the FB slogan is “code wins arguments” which is slightly different.

throwaway1777 4y ago

That’s old school FB. Is it still like that?

skizm 4y ago

> Disregard levels. Disregard titles. Tell that to the person writing my paychecks.

gorgoiler 4y ago

Code Wins Arguments

Supermancho 4y ago
> Code Wins Arguments 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.
- yamtaddle 4y ago
  Shit these days I consider writing code the failure-state that happens when I'm too dumb or inexperienced to figure out how to avoid writing code.
scarface74 4y ago
Given a choice between telling most of my former CTOs/Directors at smaller companies 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.

chrisseaton 4y ago

> Anyone who calls themselves these things is weird, and will be hard to rely on. Providing technical leadership is weird and makes people hard to rely on?

Thaxll 4y ago

Unit tests, CI, docs this overhead, I want move fast and break things.

vanjajaja1 4y ago

I agree that code is what matters, but whats your take on writing code vs influencing people who write code? Seems to be a trade off, but it seems to me that eventually you can't write code as fast as you can influence other people who write code...

dasil003 4y ago
Or worse, other programmers are destroying the value of your code faster than you can create it because the underlying vision and principles beyond your chosen abstractions is not clearly communicated.

summerlight 4y ago

Oh no, managers in technical teams are usually doing their jobs not because it's fun and exciting but there's no other people who is willing to do those "grunt works" around people. Real leadership happens in the team, not code; code is just a (rather inaccurate) reflection of organization and business. It's correct that it's important to keep it close to the reality, but that's done by people and teams.

Matthias247 4y ago

Only that pure code also doesn't matter if it's either not needed required at all due to different business/customers requirements or if problems could be solved easier with a different and easier to maintain set of code if system architecture and interaction between teams would change.

quickthrower2 4y ago

Only code matters is a weird take. Even excluding sales, marketing, strategy and other functions, just within Engineering, having people who unblock other people, deal with cross cutting concerns, make sure the new starter in them team doesn’t leave because everyone else was too busy to help them, etc. are critical. 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.

mmmpop 4y ago
Is it technically ironic how often that the "antisocial coder" who revels in their maladjustment wants to then give their opinions about how organizations of people ought to structure themselves??
scarface74 4y ago
It really doesn’t apply then. At that stage knowing what to write and finding product market fit is far more important. And not using Kubernetes…

deleted 4y ago

[deleted]

hideo 4y ago

I consider myself a 'Solver'/'Fixer', mainly because that's the title others gave me, and I mostly disagree with this. 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"

dogleash 4y ago

>Real leadership happens in the IDE 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?

pc86 4y ago
> Do people actually believe these kinds of things? Most don't, no. But you'll definitely find a higher percentage of people who do at places like FB.

novok 4y ago

They exist to point out that there isn't only one way to define someone as staff engineer. If you don't write them out, then companies degrade into only allowing one type of archetype to get promoted, which discounts other ways of doing things, leading to a less efficient company. You see it at google in 2018: https://mtlynch.io/why-i-quit-google/ https://mtlynch.io/why-i-quit-google/ and today with the LPA (Launch, Promote, Abandon) cycle : https://nextbigwhat.com/the-lpa-cycle-at-google-launch-promo-abandon/ https://nextbigwhat.com/the-lpa-cycle-at-google-launch-promo... 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.

notacoward 4y ago

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.

virissimo 4y ago

AFAICT, the author nowhere advises anyone to call themselves by the archetype names, nor do I have reason to think that it was their intent for the reader to do so.

scarface74 4y ago

You can’t disregard levels at large organizations if you care about your compensation. The behaviors you are referring to are “mid level behaviors” according to most guidelines. 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.

jameshart 4y ago

We’re talking about organizations where there are thousands of people all writing code. 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.

0x445442 4y ago

Yeah... http://programming-motherfucker.com/ http://programming-motherfucker.com/

jonnycoder 4y ago

I've always been a solver since I have a talent/curiosity for solving problems. I've learned that you can't always be that though especially if your organization/group values feature development. Therefore there is a balance between jumping on a problem and jumping right back to what you were doing in terms of sprint stories and development work. I've been in a group where solving high priority issues was valued at like 10% and feature work was 90% and that was a bad experience learning that hard fact late.

HenriTEL 4y ago

And that's how you end up with 10 teams competing to build 10 different platforms to solve the same problem.

mehphp 4y ago

> only code matters Code is just an implementation detail that solves a business problem. I can't disagree more with this take.