Done, and Gets Things Smart (2008)

I'm definitely no expert, but what I'm shooting for is:

- Set minimum effective goals in a well-dialed manner (somewhere in the sweet spot between big enough to make an impact and small enough to do on a reasonable cycle)

- Get the goal done. Quickly if at all possible.

- Figure out what isn't optimal from there and iterate

Honestly my intuition for #1 is... among the non-optimal things, and I may well have some shortcomings on #2.

(I'm really good at part of #3, though.)

I don't believe it is possible to cultivate. You've either got the right mentality, or you don't. This comment [0] from an earlier discussion always sticks in my head during these conversations, though its context is somewhat different.

I also believe that self-improvement should focus on being the best possible version of yourself, not striving to be something you are not and cannot be. We are not angels (okay, I'm not -- I'll let you speak for yourself) and so we cannot expect to hold ourselves to the ideals of angels and get a worthwhile result.

And, even further, I believe that the worst sin in hiring is to hire someone toxic. Almost any other deficiency can be tolerated. Toxic people drag down everyone around them, and that's not acceptable. There are surprisingly many toxic people out there, they interview surprisingly well, and they're always in the interview pool, because they keep losing their jobs. Don't be toxic and don't hire toxic... or the team/company is completely doomed. Compared to that, choosing between "very good" and "outstandingly excellent" starts to look a bit less critical!

[0]: https://news.ycombinator.com/item?id=19579047

I wonder what we've lost ever since Adam Smith started bemoaning the practice of apprenticeships. 7 years under a master could give a person a very solid understand of the topography of their field, where their weak points are, and how to get better. Most of the incompetence in the Dunning-Kruger Effect comes from unknown unknowns, because without a list of things to improve, it's easy to believe 1) there's little left to improve, 2) the gap between oneself and anyone else is small or zero.

I have a few hypotheses to contribute, for those with appetite for unvalidated speculation.

================Tie in with Circles of Competence=============

I believe this to be a hint that was left in the comments by the original author: > do they know who they are? > Alex: good question! The answer is, I think, "not really." The Dunning-Kruger Effect has a fourth principle that I didn't mention, which is that as your competence increases, your self-evaluation diminishes. The most competent people apparently tend to rate themselves below their skill level.

Another hint from Munger/Buffett wisdom: https://fs.blog/2013/12/circle-of-competence/

Taken together, if one feels like there's an area where one has a ton to learn and a good understanding of how to begin filling those gaps, that's probably the start of a circle of competence.

A couple of attitudes to avoid at work would be: "it can't be that hard to figure out" and "use the right tool for the job", because that will just lead to using skills that one hasn't developed before. Perhaps the better thing to do would be to finish the task in a way you know will work, rather than ramping up on another way that might be more elegant or general. Use your circle of competence. Make time for filling in the parts of the map where you know you need to improve, but don't be eager to combine learning with getting things done. If you're lucky, you'll know someone who can code review and show you the better way to do it.

It means the stuff you end up doing won't seem special to you because there was nothing to figure out. It probably feels weird and strange to call that your "mastery".

================A Potential Strategy for those in school or early in their career=============

The importance of picking good schools, good classes, and good places to work early in one's career is hard to overstate. (You don't necessarily need to go to the most competitive school, as long as there are good professors to serve as your DGTS role models.) Once you have the opportunity of working with DGTS role models, do these two hard things: - stop making up reasons for why you aren't incredibly impressed by their ability to deliver solid results consistently - realize that "if I could just focus, I could crank that out in a weekend" is probably not true, and start to map out the skills you'd have to master from those who actually can and do work at that pace. Realize that pulling all-nighters to make more time doesn't count as mastery, and won't be something you can do later in life.

================Imposter Syndrome=============

I wonder if imposter syndrome hides one's circles of competence, as anything one does well will get downplayed in significance, and papered over by insecurities.

You have received two types of answer so far:

1. You don't, and

2. Here are some practises used by effective engineers.

I think (hope?) the true answer to your question lies somewhere between the two answers you already have.

I hope it can be learned (it's the thing I'm gunning for, anyway) but I don't think effective engineering practises alone will get me there. They can make me a great engineer, for sure, but at this point we're talking beyond great.

I think (again, hope, anyway) that the key is learning things from outside your discipline, and integrating those things into a general framework that informs your decision making and design in your profession.

There are a lot of smart people writing books where they share their insights in their own niche (examples of niches include manufacturing, financial risk management, gambling, product development, network engineering, behavioural economics, negotiation, applied statistics, psychology, system safety, forecasting, and so on). These works tend to be about very specific things, but after a while you start to see underlying concepts that pop up time and time again and support the most important principles in each field.

It might sound like those things have nothing to do with engineering (and I'm sure a lot of people would hope for more technical subjects) but from my experience, the actual coding bit is surprisingly small compared to the one where you would like omniscience but will have to settle for a proxy.

Sometimes these principles are stated outright, other times it's not so obvious when they apply. For example, one recurring idea is hypothesis testing: view the world not through the lens of your knowledge, but through a set of hypotheses you need to test. I'm currently validating the more general applicability of this idea by, among other things, trying to think of poker bets as hypotheses -- did the other players respond as I had expected? If not, what consequences does that have for my idea of the table? -- similar to how traders on Wall Street might pull their trades if they lose faith in their backing hypothesis, and a project should be pulled if the MVP falsified the hypothesis about the market.

However, there are at least five problems with this method of mine.

1. Critically, I have no idea if it works. Only my perception of it working.

2. Research indicates human learning is incredibly contextual and there might not be such a thing as meaningful cross-disciplinary learning at all. This indeed seems like a fatal problem I have yet to address. (In the mean time, I'll keep doing what I'm doing because of the implied odds: if the research doesn't apply to what I'm doing (small chance) the compounding from having started early and not pausing makes it worth it. Also, it's fun to learn things.)

3. It takes a lot of time. I spend many hours a day reading, and then even more finding ways to put my learning into practise.

4. It relies on being able to sniff out good books. These are not necessarily the popular books, but ones that contain plenty of information that generalises. Sometimes these works even contradict general wisdom or consensus, which is particularly dangerous. It's easy to become a crackpot. Key is probably to give priority to scientific rigour -- or even better, a proven track record (beyond statistically plausible fluke.)

5. Once armed with the right reading, one needs also to be good at generalizing from specific ideas across disciplines to a more broadly applicable framework. I don't think this is a special skill, but again, I don't know.

And a lot of society revolves around that. We seek compatibility.

Urs Hölzle or Paul Buchheit, maybe?

My guess is Craig Silverstein, as he mentioned that Larry and Sergey might have worked with him at Stanford.

Possibly Craig Silverstein, but my guess is Urs Hölzle. He was Google's first VP of engineering and a huge advocate for everything mentioned in the article: "design docs, audited code reviews, early design reviews, readability reviews, resisting introduction of new languages, unit testing and code coverage, profiling and performance testing".

Early Google had more than its fair share of genius engineers with giant egos. Urs was brilliant and tough - a perfect combination for keeping everybody in check and shaping the engineering culture.