I think this is true for engineers as well! I enjoy getting to know the "theme" of my favorite coworkers over the years. There was:
* The fellow who always looked for the simplest hack possible. Give him the most annoying problem, he'd pause, go Wait a minute! and redefine it to have a very easy solution. He typed very slowly, but it didn't really matter.
* The one who truly loved code itself. He would climb mountains to find the most elegant, idiomatic way to express any program. Used the very best practices for testing, libraries, all that. He typed very fast.
* The former physicist who spent all his time reading obscure mailing lists on his favorite topics. His level of understanding of problems in his domains of interest was incredible.
I could go on and on! It's such a fun taxonomy to collect. All of these friends were marvelous at solving their particular flavor of problem.
As for myself, I like to think that my "trick" is to spend a long time poking at the structure of a problem. Eventually the solution I was looking for doesn't matter anymore, but the tools I developed along the way are pretty useful to everyone!
* The (brilliant) infrastructure engineer who described his modus operandi as 'I read stuff on Reddit and then try it out.' This engineer is now worth, as a conservative estimate, in the neighborhood of $50 million. So maybe more of us should be doing that.
* Another infrastructure engineer, also very effective, who made a habit of booking an external training session (sometimes a series, weekly) for how to set up and integrate every piece of technology we used.
* An engineer (this one is quite famous, and we have only interacted professionally a few times) who simply wrote the best comments in the world. Every method was adorned with a miniature essay exploring the problem to be solved, the tradeoffs, the performance, the bits left undone. I think about those comments quite often.
As an addendum, though, I will say that the best engineers overall all shared a trait - they kept trying things until they got something working. That alone will take you pretty far.
Success is relative. If the goal is to never fail, never try is the best strategy.
Also the most sure path to finish in the 1% wealthiest is to start in its network.
When the game is set to make 99% of players considered as losers in its own terms, the best strategy to have fun at scale is to not care about the highlighted goal. Keep awareness of how rules actually apply, take shortcuts if it feels safe and preferable, always respect human dignity even when nasty players try to make a dirty move agaisnt you, don't let the lowering bare of hate infect one more player.
I am having trouble thinking of situations where the only good outcome is being the top 1%. There are, to be sure, often power-law benefits to being exceptionally good, but to use your own example, being in the top 5% or 10% of wealth is nothing to sneeze at. It's all a spectrum.
With that said, I think you make some good points about the perspective people should have about competitive goals. Most contests are not strict meritocracies, and you are in for a lot of frustration if you assume that only effort matters when other slide by on their structural advantages. I would prefer to reframe the goal as 'work hard on what you have control over, as long as it provides some amount of benefit, and as long as you still care about the outcome.'
This wasn't to mean that ending up in the top percentile of whatever metric is a good outcome, simply that those who advocate the game and its rules will generally tell what is supposed to be valuable and praised as part of the game framing. My point wasn't to tell that taking blindly this or that outcome as a desirable one is advisable.
For the second paragraph, we seem really aligned on the developed points.
Yes. An interesting corollary is that we should pay close attention to what games we have an inherent advantage in, and double down. Much higher chances of reaping those power-law benefits. I speak, frankly, mostly to myself here: I am naturally pretty bad at almost all human skills (although I’ve of course worked hard to build up at the competencies required to be a functioning adult and partner.) But for the one or two things I am naturally good at, it all comes so very easily, it’s effortless and free and I have built my life around them.
>Success is relative. If the goal is to never fail, never try is the best strategy.
This is dangerously not true, if you never try, then you are guaranteed to fail to live up to your potential, which is one of the greatest failures of all.
Sorry if it wasn't clear and explicit enough, but this wasn't meant to be an advise to not try anything. Just an extrem example of what it might be logically concluded when starting from unsound grounds. Never fail is not a sound goal.
That said living up to our potential is not very much better per se. Or at least it seems far too vague to be aptly considered. What forces are going to define what it is to tap relevantly in our potential?
Yes. I like to think that all of the people above could have solved most of the same problems, albeit in wonderfully different styles, but what really guaranteed success was a commitment to just keep at it.
Edit to add: Still, the styles matter a lot! For one thing, they greatly influence which problems each person is interested in. Also, the style you solve problems with colors what your final output looks like, which is perhaps more obvious in engineering than in mathematics.
For me, it's tracing code/pipelines to figure out how a result was produced, typically in the context of that result being wrong somehow. Go To Definition is the most useful function in any editor.
I'm always surprised by how frequently colleagues don't think to do this and are left helpless.
This reminds me of my further theory that everyone needs one 'heavy' and one 'light' technique. The 'light' technique is something that often works well as a heuristic and can be an effective unit of iteration. The 'heavy' technique is something that you can fall back on in difficult cases, something that can reliably solve hard problems, even if it's slow.
Sometimes the heavy technique is: just ask someone else. ;)
You jest, but that's how my sister gets through life, and it's always fascinated me.
She's incredibly intelligent, but more importantly she's a phenomenal social networker. She always has someone to call to ask about any question or solve any problem that comes up in life, and she's great at connecting these people with each other when they have problems of their own - so they all want to help her with whatever she needs, just to gain access to a pool of people they themselves can talk to.
What do you do with a skillset like that? I honestly don't know - something in leadership, probably, something where finding the right people and setting them to work is the most important skill of the job.
That wasn't in jest. I worked in a place where this was a norm. Nothing was properly documented, instead everyone would just ask and answer questions on chats; somehow, this actually kept velocity high.
Found it really hard to adjust to that. I'm the kind of person that prefers to research things on my own, find hard references and understand context. But there, this was the wrong approach.
I have both felt and seen this at work and I would add to this the meta-technique of binary search. Once it is added to your light and heavy technique you can solve what seems intractable at first glance faster than many people can even orient to the problem.
Likewise. I don't always do this, but for problems that cost me much time or effort, I like to try to make sure that, if I wanted to reproduce a bug or problem, I'd know exactly how to write it.
Writing and understanding working correct software is, it turns out, a rather different skill from that of writing and understanding broken (or confusing) software. I'd also wager good money that the latter skill directly builds the former.
It's amazing that a lot of new developers don't know how to use them at all! I'm not even talking about using the command line gdb, but just the basic "Set Breakpoint" feature and attaching to processes.
* The fellow who always looked for the simplest hack possible. Give him the most annoying problem, he'd pause, go Wait a minute! and redefine it to have a very easy solution. He typed very slowly, but it didn't really matter.
* The one who truly loved code itself. He would climb mountains to find the most elegant, idiomatic way to express any program. Used the very best practices for testing, libraries, all that. He typed very fast.
* The former physicist who spent all his time reading obscure mailing lists on his favorite topics. His level of understanding of problems in his domains of interest was incredible.
I could go on and on! It's such a fun taxonomy to collect. All of these friends were marvelous at solving their particular flavor of problem.
As for myself, I like to think that my "trick" is to spend a long time poking at the structure of a problem. Eventually the solution I was looking for doesn't matter anymore, but the tools I developed along the way are pretty useful to everyone!