> Teams that work well together can outperform groups of people who are collectively more talented because there is a multiplication factor for teamwork.
There's some great advice here about building a team culture that allows everyone to level-up and contribute their best. Some comments here have suggested that this isn't what 10x means but that's the point! What if we value the wrong kinds of people in our teams - the talented jerks? We should instead call out the value of those that help the whole team improve.
On top of the productivity gains, the value of building a culture like this is invaluable for a startup or team with a long-term vision. It builds a sense of camaraderie and environment for learning and growth that draws people in and keeps them around for a long time.
Jessica Livingston shares on the role she played in founding YC and building the culture. She points out some of the same kinds of ideas in one of her talks[1] showing that some of the soft skills and the social environment that founders build are way more important than they often realise.
> Invite discussion with your language by using words like “I think” and “maybe”. (I call this conversational style: "Maybe you should talk more like a woman?")
Aside from the fact that I did not understand that "talk like a woman" thing, is the author advising us to stop the long-running advice of "speak precisely" with "say anything, even if you are not sure' with the only caveat being to let people know when you aren't certain of something?
That's like a public speaker telling me to say "uuhh..." in between my phrases!
Here are some serious outstanding problems in software:
* Considering how fast modern computers are, software is so damn slow.
* Software frequently stops working. When it does, the process to diagnose the bug and fix it conclusively is not a straightforward one.
* Software is poorly understood. Most developers today work with other people’s abstractions. It’s rare to find a software system that someone can describe the inner workings of end to end.
* Software is excessively complex. To understand a codebase, you might have to crawl through ten layers of dependencies, imports, and scaffolding before finding code that actually does anything.
These are just some obvious ones off the top of my head. Does following the advice on this list make me any better at tackling any of these problems?
Could someone conceivably do none of the things on this list, and still be a very skilled developer who makes strong strides toward solving these problems?
Excerpts:
"1. Create an environment of psychological safety"
"6. Hold yourself and others accountable"
Now, not to get all lawyerly (I am not a lawyer) or anything, but...
How exactly do you do #1 if it conflicts with #6?
?
And...
How exactly do you do #6 if it conflicts with #1?
?
However overused, the phrase 10x developer does have a fairly specific meaning, and this isn't it.
Discussed at the time: https://news.ycombinator.com/item?id=17304619
Every developer should do all of these things, the behavior and norms described in this blog post seem like the absolute minimum to have a healthy work environment.
I know a >250x programmer. That is strictly objective: on a 500-engineer 6-month death-march project, fully half the code delivered was his. He knows somebody who he estimates at 10x his own rate, and who wears out 2 keyboards a year (or did, 20 years ago).
(You might object that this makes him a 500x programmer, but he doesn't agree: a fair bit of code was written that did not end up in the product, an unknown fraction of which was good.)
And I thought being a 10x developer meant cranking out high quality code..
Well like others said, this reads more like an opinionated piece on how to be a good teammate.
I think Antirez[1] has more practical advice on how to actually become a "10x programmer"
Key points:
* Experience: pattern matching
* Knowledge: some theory is going to help
* Low level: understanding the machine
* Debugging skills
* Perfectionism, or how to kill your productivity and bias your designs
* Design sacrifice: killing 5% to get 90%
* Simplicity
* Focus: actual time VS hypothetical time
[1] http://antirez.com/news/112