Jason Crawford writes on technology, progress, engineering teams, and working with people, and previously wrote about startups.
HN commenters link his Gmail redesign tips and his essay on working with "stupid" people, and one disputes his take on the 10x engineer.
I appreciate the overall point of the article, but have a gripe. The author (and others) gets it wrong on the original meaning of 10x. A 10x engineer isn't someone who is 10x as productive as their peers, they are 10x as productive as their worst performing peer. The original study the author links to compares the difference of work between the fastest code and the slowest code. The fast debugger and the slow debugger.
When we talk about 10X, it should be about comparing it to the least productive team member - the 1X. There is always going to be a 1X person on the team. That's not bad if the team average is 1.5-2X, but if the average and discrepancy gets large enough, you're going to have the 10-100X team member who gets a lot done.
Also, not all work is equal. The 10X engineer who is only 10X in programming may be a 1X in collaboration or documentation. That's not a good dynamic, either. Again, appreciate the point of the article, "build great teams", but we need the 10X person in each task to do that. If the build pipeline is slow and costing us money, I need the best people on the team to go figure that out. And, I need our worst engineer who is still learning to be involved so that they can grow their skills. Become a 1.1x, 1.2x, etc.
Hat tip to these articles on 10x engineer studies: https://jasoncrawford.org/10x-engineers https://www.construx.com/blog/productivity-variations-among-software-developers-and-teams-the-origin-of-10x/
For anyone interested, seems like a good overview:
https://jasoncrawford.org/guide-to-scott-alexander-and-slate-star-codex
hn discussion:
https://news.ycombinator.com/item?id=26128579
(seriously, don't miss on reading some of Scott's posts -- you will be disappointed by almost every piece of nonfiction you read afterwards)
It's definitely one of those cases of "If everyone thought a little more like X, Earth would be a much better place.", (let X=Scott Alexander) -- and notably it becomes quite clear how to think like he does (he just tells you!).
I can't fault Google for experimenting, but the 'all or nothing' approach they took to the rollout was an example of false choice. The classic coloring could have been offered as a theme to lessen the impact of the UX changes.
In case you miss the old color scheme, try this Stylish theme:
http://userstyles.org/styles/64637/gmail-google-mail-classic-blue-theme
Follow Jason's post to fix icons and spacing:
http://jasoncrawford.org/2012/04/how-to-cope-with-the-gmail-redesign/
FYI, I found this article really helpful:
http://jasoncrawford.org/2012/04/how-to-cope-with-the-gmail-redesign/
It shows how to: get rid of "importance" markers, add some contrast back to the colors, remove superfluous whitespace, and most importantly, change the impenetrable icons back to text.
I've been able to get most of the old gmail interface back by following Jason Crawford's recommendations:
http://jasoncrawford.org/2012/04/how-to-cope-with-the-gmail-redesign/
The stuff I cared about anyway. I agree it is sad.
many of these issues can changed to be more old-gmail-like
http://jasoncrawford.org/2012/04/how-to-cope-with-the-gmail-redesign/
1) remove important markers 2) add labels to actions/buttons