6 ms·
It seems like the industry would get a lot more 10x behavior if it was recognized and rewarded more often than it currently does. Too often, management will foc
by didgetmaster 3y ago
It seems like the industry would get a lot more 10x behavior if it was recognized and rewarded more often than it currently does. Too often, management will focus more on the guy who works 12 hour days to accomplish 8 hours of real work than the guy who gets the same thing accomplished in an 8 hour day.
Also, deviations from 'normal' are frowned upon. Taking time to improve the process isn't built into the schedule; so taking time to build a wheelbarrow is discouraged when they think you could be hauling buckets faster instead.
- Terretta 3y agoIt's almost impossible to get executives to think in return on equity (“RoE”) for the future instead of “costs” measured in dollars and cents last quarter. Which is weird, since so many executives are working in a VC-funded environment, and internal work should be “venture funded” as well.
- deleted 3y ago[deleted]
- happytiger 3y agoThat’s because most executives can’t understand technology deeply enough to know the difference.
- didgetmaster 3y agoEven when they are smart enough to know, they seem to have very short memories. While I don't consider myself to be a 10x engineer; I have certainly done a number of 10x things over my career. I worked for a company where I almost single handedly built a product that resulted in tens of millions of dollars in sales. I got a nice 'atta boy' for it, but my future ideas were often overridden by someone in management who 'knew better'. After the management changed, I found myself in a downsizing event once I started criticizing them for a lack of innovation.
- KuriousCat 3y agoThis is the sad part of it, many people without core competence end up in "leadership" positions and remove any "perceived" threats to their authority. I believe part of it is due to the absence of leadership training in the engineering curriculum. Colleges should encourage engineers to take up few leadership courses and get them trained on things like Influence and Power.
- 6510 3y agoKnowing the difference between an overly ambitious or technically wrong proposal and when to listen to the engineer seems impossible at times. Perhaps it requires a consultant.
- KuriousCat 3y agoIn my experience working for several companies, people who know and are not merely acting out of fear can call things out and explain why something is wrong or ambitious. And more often than not sensible engineers get it. Consultants are usually called in by the leadership when they can't deal with the backlash or have no core competence in the first place.
- umvi 3y agoReminds me of the inventer of the blue LED (see recent veritasium video)
- happytiger 3y agoDid you go build your own company? You totally should with a story like that.
- didgetmaster 3y agoAs a matter of fact, I did. https://www.didgets.com https://www.didgets.com
- jimbokun 3y ago
- sangnoir 3y ago>It seems like the industry would get a lot more 10x behavior if it was recognized and rewarded more often than it currently does I'd be happier if industry cares more for team productivity - I have witnessed how rewarding "10x" individuals may lead to perverse results on a wider scale, a la Cobra Effect. In one insidious case, our management-enabled, long-tenured "10x" rockstar fixed all the big customer-facing bugs quickly, but would create multiple smaller bugs and regressions for the 1x developers to fix while he moved to the next big problem worthy of his attention. Everyone else ended up being 0.7x - which made the curse of an engineer look even more productive comparatively! Because he was allowed to break the rules, there was a growing portion of the codebase that only he could work on - while it wasn't Rust, imagine an org has a "No Unsafe Rust" rule that is optional to 1 guy. Organizations ought to be very careful how they measure productivity, and should certainly look beyond first-order metrics.
- lifeisstillgood 3y agoI try to look at these things through the lens of “software literacy” - software is a form of literacy and this story might be better viewed as “a bunch of illiterate managers are impressed with one good writer at the encyclopdia publishers, now it turns out this guy makes mistakes, but hey, what do you expect when the management cannot read or write !”
- JohnMakin 3y ago> In one insidious case, our management-enabled, long-tenured "10x" rockstar fixed all the big customer-facing bugs quickly, but would create multiple smaller bugs and regressions for the 1x developers to fix while he moved to the next big problem worthy of his attention. Everyone else ended up being 0.7x - which made the curse of an engineer look even more productive comparatively! Because he was allowed to break the rules, bingo, well said. Worked on a team like this with a “principal” engineer who’d work very fast with bug-ridden work like this simply because he had the automatic blessing from on high to do whatever he wanted. My unfortunate task was to run along behind him and clean up, which to my credit I think I did a pretty good job at, but of course these types can only very rarely acknowledge/appreciate that. Eventually he got super insecure/threatened and attempted to push me out along with whoever else he felt was a threat to his fiefdom.
- SomeCallMeTim 3y agoThis reminds me of the "Parable of the Two Programmers." [1] A story about what happens to a brilliant developer given an identical task to a mediocre developer. [1] I preserved a copy of it on my (no-advertising or monetization) blog here: https://realmensch.org/2017/08/25/the-parable-of-the-two-programmers/ https://realmensch.org/2017/08/25/the-parable-of-the-two-pro...
- mjevans 3y agoI can't seem to find it in a google search, maybe I'm just recalling entirely the wrong terms. In the early computing era there was a competition. Something like take some input and produce an output. One programmer made a large program in (IIRC) Fortran with complex specifications documentation etc. The other used shell pipes, sort, and a small handful or two of other programs in a pipeline to accomplish the same task in like 10 developer min.
- ianmcgowan 3y agoSounds like "Knuth vs McIlroy", which has been discussed on hn and elsewhere before, and the general take is that it was somewhat unfair to Knuth. [1] https://homepages.cwi.nl/~storm/teaching/reader/BentleyEtAl86.pdf https://homepages.cwi.nl/~storm/teaching/reader/BentleyEtAl8... [2] https://www.google.com/search?q=knuth+vs+mcilroy https://www.google.com/search?q=knuth+vs+mcilroy
- mjevans 3y agoThis is the competition I was thinking of. I must have read it in a dead-image PDF version some other time on HN. This paper isn't the one I recall but the solution is exactly the sort I vaguely recalled. I'm trying to copy-in the program as it might have existed, with some obvious updates to work in today's shells ... #!/bin/sh tr -cs A-Za-z ' ' "${2:-/dev/stdin}" |\ tr A-Z a-z |\ sort |\ uniq -c |\ sort -rn |\ sed ${1:-100}q Alternately (escapes not yet tested) $ tr -cs A-Za-z \012 "${INPUTFILEHERE:-/dev/stdin}" | tr A-Z a-z | sort | uniq -c | sort -rn | sed ${MAXWORDSHERE:-100}q Edited: Removed some errors likely induced by OCR / me not catching that in the initial transcription from the browser view of the file.
- ransom1538 3y agoHonestly? You work at a place a manager hasn't heard "impact" yet? I thought managers at this point just walk around the office saying "impact".
- PH95VuimJjqBqy 3y ago> It seems like the industry would get a lot more 10x behavior if it was recognized and rewarded more often than it currently does. I don't agree with that, there are a _lot_ of completely crap developers and they get put into positions where even the ones capable of doing so aren't allowed to because it's not on a ticket. I've seen some thing.
- michaelcampbell 3y ago"Don't confuse motion with action", in other words. I think a lot of people aren't good at it because they themselves are rewarded for the opposite. This seems rife in the "just above individual contributor" management layer, but that's a biased take.