Daniel Miessler's Blog, page 79

Unsupervised Learning: No. 192 (Member Edition)

This is a Member-only episode. Members get the newsletter every week, and have access to the Member Portal with all existing Member content.

Non-members get every other episode.

Sign in

or…

—

Become a direct supporter of my content for less than a latte a month ($50/year) and get the Unsupervised Learning podcast and newsletter every week instead of just twice a month, plus access to the member portal that includes all member content.

Day-1 Skills That Cybersecurity Hiring Managers Are Looking For

I’ve written before about the paradox of hiring managers not being able to find entry-level cybersecurity candidates, while many people with decent training or even degrees in the field cannot get hired.

As it turns out, it’s not really that hard to explain.

The Military takes you from zero to hero.

In extremely large and long-term-focused organizations—like the Military—this gap is understood, so they spend time building extensive, standardized programs that can take anyone off the street and turn them into professionals over time.

Most startups are just happy to be alive, and aren’t anywhere close to thinking about how to systematically grow security talent.

Some large companies do actually grow talent, but not enough.

In most companies—and especially startups—they don’t have programs that spin people up from nothing because they simply don’t have the time. They’re dealing with their own pressing problems, like trying to convince partners that they aren’t a complete dumpster fire (which they often are).

The result is that they need to hire people that already know how to do things.

The security engineer skills that managers need right now

This is a perfect example of when a hack is needed.

So here’s the secret that nobody’s talking about. It’s absolutely possible to hack your way into an entry-level position in security.

The trick is being able to convince the hiring manager—and their team—that you can do the tasks that they need most. Luckily, many of those tasks are somewhat standardized, and this article will take you through them.

If you’re on any security team at a junior to mid-level, these are exactly the types of things you’re likely to spend your first few years working on.

Technical skills

So many of these are a combination of soft and hard skills.

Product Selection:


Scenario: Your manager tells you that the CISO read about endpoint protection on the wall of an airport, so now we need to do that immediately, and it’s your job to find the best one.
Tasks:


Learn About The Space: Figure out who the main players are in the space, so you can understand what the capabilities are.
Determine Your Requirements: Untangle exactly what we need from an endpoint solution.
Create a Scorecard: Create a system for rating all selected products based on your criteria, with as little bias as possible.
Meet With Vendors: Get with vendors and learn about their products to see who you can eliminate quickly and who will be in your testing group.
Eliminate All But Your Top N Products: Using what you learn combined with your criteria, get your candidates down to 2-5 vendors.
Product Testing: Do the best testing you can on these products, in a fair way that represents how your company will use them.
Write Your Analysis: Create an artifact describing the selection and testing process, and which product was selected.
Present Your Findings: Depending on the company and the size of the project, you might have to present your artifact/analysis to various managers to move the project forward and get support.

More junior members of the team often do only one of these tasks.

This is really a full-stack kind of job because you have to make big decisions, organize your thoughts, come up with fair criteria, make sure you don’t miss things in your testing, and then make a compelling argument in your analysis and recommendation.

This is a great place for bug bounty folks to slide into a team’s DMs.

Ad-hoc Security Assessment:


Scenario: Your team has just learned that some website—which we just found out about—is about to go live tomorrow morning at 9AM. And it has not had a security review. Your manager calls you and tells you to take a look real quick to see if we need to spend political capital to have the site launch delayed.
Tasks:


Perform a Quick Web Security Assessment: Fire up Burp and/or any other commercial tools you might have and start manually testing the site for vulnerabilities. While you run some automated scanners using a set of test credentials, you also run through your manual testing methodology to look for P1 – P3 vulnerabilities.
Write Your Analysis: You found out that the site allows enumeration of usernames and passwords, and once logged in there’s an IDOR vulnerability that allows one customer to pivot to see other customers’ data. So you have to write this up in a 1-3 page report, with screenshots. And you have to do it in a clear-headed, matter-of-fact way that doesn’t aim to embarrass the team that built it.
Present Your Findings: After midnight there’s a call with the product team who built the app, and your manager asks you to explain why these things are bad, and why we can’t just launch the site and fix these later.

There are many types of security assessment, but the most common are tiny little risk assessments where you ask very simple questions like: Where’s the data, how does it travel, how is it stored, who has access to it, how is logging handled, is the system connected all the way through to incident response, etc.

You’ll basically be doing these assessments constantly, often multiple times per week—with each taking just a few minutes. Before long you’ll barely even know you’re doing it.

This one is one of the hardest to prepare for, since it’s strongly based on experience.

Preparing for and Handling an Audit:


Scenario: It’s Friday afternoon, and you just got told that Sarah, who normally handles all technical audit work, is out of the office next week unexpectedly for a death in the family. The auditors are onsite Monday morning at 8AM, and you need to 1) make sure all of our technical controls are in place, 2) be completely honest with them, and 3) they better not find anything—we’re depending on you.
Tasks:


Learn the Audit Standard: Very quickly spin up on what a SOC2 audit is.
Find Out Our Current State: Now that you know what they’ll be looking for (that took a bunch of Friday night and Saturday morning), now you have to figure out where they’ll be looking at our stuff, and what state it’s in.
Answer Questions About Our Controls: Be able to respond sensibly about how we are (or aren’t) meeting a particular standard that’s being asked about. The amount of wiggle room here is remarkably (and sadly) very large, and the more technical and smart you are the better shape you’ll be in. Honesty is rewarded by good auditors, and they often give time to make quick fixes before the audit is completed.
Create a List of Follow-ups: Take a list of findings from the auditor and go do all the relationship-straining leg-work to go get those things fixed throughout the entire company.
Follow-up with the Auditor: Come back to the auditor and show them (days or weeks later) that all the outstanding items have been addressed.

Dealing with auditors is a great example of the breadth of skills required to be a security engineer. When you’re handling an auditor you need to be extremely versed in many types of security, the controls that are involved, the reasons they’re asking their questions, and what exactly can be done to come to an arrangement regarding remediation.

Tech skills can really help here, but the best teacher is experience on this one as well.

Integrating a New Security Product:


Scenario: Your company just implemented a new NextGen CloudChainAI Firewall (Barracuda’s latest product), and your manager tells you to get it integrated with your (tee hee hee) centralized logging solution.
Tasks:


Talk to Your Logging People: Just kidding, that person is you also. But pretend it isn’t. Find out how they take in logs, over what protocol, how that delivery will be monitored, how to get an alert if logging stops, etc.
Determine What Events Should Be Alerts: Knowing what you know about the device, and the types of functions it performs, determine what types of issues we care about knowing immediately, that that must be monitored 24/7.
Find out How the Appliance Does Logging: Get credentials and go into the new device’s administrative interface, figure out where logging happens, and send the logs there. Configure or arrange those integrations with the appropriate folks in Incident Response.
Write Some Code To Integrate with The Appliance’s API: There’s also an API for pulling more detailed data, and you need to add that to the centralized metrics dashboard. So you write some Python and JavaScript, using its documentation, to use your keys, pull the API, and write to an internal web page.

The steps required to do this integration could be as simple as pointing logs, all the way to integrating with SOAR systems, talking to multiple teams for their touchpoints, etc.

This is where previous developers can prove their worth as junior team members.

Create a New Tool:


Scenario: Your group just got access to a new domain blacklist, and it has a pretty well-documented API. But now that makes 5 total blacklists your team is subscribed to. Your team lead asks you to create a single internal API that queries all of them, with extremely fast performance.
Tasks:


Create a New API: Create a new API using whatever language is used internally to aggregate all the existing APIs, search against them, and provide a YES/NO answer in less than 200 ms.
Create Documentation and Examples: Create documentation that includes how to call your new service in Go and in Python.

Note: Programming isn’t strictly required for all security positions, but for situations like we see above, it’s highly beneficial and preferred by managers.

Soft Skills

I’ve mentioned them multiple times already in the technical sections above, but being able to communicate is invaluable. There are many technical people who can implement or break their butts off, but they’re not desired on teams because they can’t interact with others.

You want to have both.

Here are the main soft skills you want to make sure you have.

Excellent Writing: I believe strong writing is the Uber-skill because clear writing requires clear thinking. The focus should be on being concise, and doing so with as little bias as possible.
Fast Learning: The best thing you can possibly say to a manager who asks you to do something you don’t know how to do yet is, “I can’t do that yet, but I should be able to within a day or two.” Those are true skills. Nobody can do everything. The question is how quickly you can jump into something new and become proficient.
Mentorship: In addition to being a great communicator and being quick to learn new skills, you’re also likely to be considered a better member of the team if you’re someone who lifts others and shares your knowledge. Don’t be the person who tries to make others depend on you so you’ll be more needed. It works in the short-term, but people eventually see it as selfishness and insecurity. Help others, and the Karma will return to you.


Summary

This summary has solidified for me why the skills gap exists. These tasks are not easy—even for someone who’s been in the field for 1-3 years. And that’s precisely why hiring managers keep passing up on lots of applicants.

You’re either able to do these kinds of tasks on your first Monday, or the team is likely to see you as a detractor rather than an asset. Because now they not only don’t have someone who can do the work, but you’re taking cycles away from someone else on the team to spin you up.

The key is to try to get as good at these things as possible before your interview.

Know the various product spaces, and the main players in those spaces. And be able to talk about how you might run a comparison between them.
Know how to quickly assess any type of system, whether it’s some financial system you’ve not yet seen the tech for, or a new security product that someone is deploying, or a website that’s about to go live. Know how to come up with a smart assessment methodology very quickly, and how to present findings in a concise and compelling way.
Know how to handle auditors—from being able to talk the tech with them, talk about the controls, and negotiate and follow through on negotiated remediations.
Get your programming skills to the point that you can hack together a quick client in Go or Python for accessing APIs, pulling data from a website, interacting with products, processing lots of text, and producing basic output. Few things (other than writing) will help you more in your career.
Sharpen your writing. Crisp and clear.
Be adaptable. Be the one who can take almost any task and learn it and execute.
Be the one with positive energy that is willing to help others.


The one thing to focus on

The one thing to focus on is convincing the hiring manager that you can be useful on day one. That’s it.

And learning to be good at the skills above, along with the ability to convey those through your LinkedIn, your projects, and your interview, is what’s going to make you stand out.

TL;DR: If you can convince the hiring manager that you can take projects within a week of starting, you’ve got a really high chance of getting an offer.

Notes


Top image from Crowdstrike.
There are other entry-level security positions, such as SOC analysts, that many companies definitely need. But those positions tend to be at larger organizations that have the infrastructure to take junior people and grow them, whereas this article is focused on what you can do to become a versatile member of a general security team in a smaller company where people are asked to do lots of things.
Michael Coates made the excellent point that a key reason for the skills gap is that not enough companies are doing what the Military is doing in growing talent. But in the startup world that’s completely understandable. Most startups are lucky to even have security people at all in a world where the entire company is still an experiment.

—

Become a direct supporter of my content for less than a latte a month ($50/year) and get the Unsupervised Learning podcast and newsletter every week instead of just twice a month, plus access to the member portal that includes all member content.

The Definition of a Green Team

As I talk about in my article on Red, Blue, and Purple Teams, there are many advocating for other team types beyond just those colors.

See my article on the different Security Assessment Types.

In April Wright’s work—who appears to have started the idea of these alternative team colors—the new ones look like this.

Yellow: Builder
Green: Builder learns from defender
Orange: Builder learns from attacker

Other groups have proposed a White team as being compliance and audit related.

The Green Team

The earlier in a term’s life the more drift you’re likely to have in its definition.

Here we’ll talk a bit about the concept of a Green Team, which according to my experience has a bit of a different meaning than the definition above. My best definition of a Green Team based on numerous conversations and a good amount of research is the following:

Green Team, infosec
An offensively-trained and defensively-focused security team dedicated to working with development and infrastructure groups to address issues discovered using offensive security techniques systemically and at scale across an organization.

See all my Information Security Articles

Note that this is not a baked definition, as the term is very new and has still yet to receive wide adoption. But taking that as a starting point, here’s how I break down the most important components:

The team has an adversarial/offensive security focus, meaning their discovery techniques come from Red Team and/or Pentesting mindsets.
Their mission is fixing things as efficiently as possible, across as much of the organization as possible.


Differences between Green and Red

Using this definition, the primary difference between Green and Red is that Red is focused on improving the Blue Team, meaning the company’s ability to detect and respond to the Red Team and real adversaries.

The Green Team, on the other hand, is focused on removing as many of the vulnerabilities and misconfigurations used by the Red Team as possible, and doing so as efficiently as possible across the entire organization. So they’re thinking about where the mistakes are being made at an organizational level, and they’re going to the source to work to change behavior.

Where the Red Team helps Blue to detect and respond, the Green Team uses those same skills to remove footholds for attackers across the company.

Examples of this would include things like working with the people who build new Linux images, or with cloud admins, or with app developers to make sure all these groups are doing things like using secure defaults, disabling older protocols, enabling logging, and doing anything else that reduces attack surface and removes footholds for attackers.

Team structures

If you think about it, Red and Green are quite similar in some ways. Both use the attacker mindset and highly manual techniques to do things that automated scanners miss when looking for vulnerabilities.

Additionally, both could potentially be broken into two phases of discovery and follow-up. In the case of Red, you first find issues by running your campaigns, and then you share that information with the Blue Team. With Green, you first find issues and you then go to the various organizations and work to address them at the most fundamental (build and configure) levels within the organization.

This potentially makes it possible to unify offensive discovery to some degree—or in some situations—and then break off into the separate learnings phases.

Summary


Red uses the offensive security mindset to discover issues that improve Blue.
Green uses the same techniques to fundamentally address the issues that allow Red to succeed.
Both have discovery and follow-up phases, which could potentially be combined in some ways in some organizations.
The Green moniker is still quite young and could either not survive or could evolve into a meaning not captured here.

—

Become a direct supporter of my content for less than a latte a month ($50/year) and get the Unsupervised Learning podcast and newsletter every week instead of just twice a month, plus access to the member portal that includes all member content.

Unsupervised Learning: No. 191

.errordiv { padding:10px; margin:10px; border: 1px solid #555555;color: #000000;background-color: #f8f8f8; width:500px; }#advanced_iframe {visibility:visible;opacity:1;}#ai-layer-div-advanced_iframe p {height:100%;margin:0;padding:0}

—

Become a direct supporter of my content for less than a latte a month ($50/year) and get the Unsupervised Learning podcast and newsletter every week instead of just twice a month, plus access to the member portal that includes all member content.

Do Upper-middle Class Crime Victims Need to Check Their Privilege?

I was thinking the other day that complaining about being a crime victim in San Francisco is an act of privilege.

I’m not talking about crime against other people that are struggling here.

I don’t say that to complain about it, but rather to marvel at it. It’s not that I think it shouldn’t be true—it’s just that I’m so surprised that it is.

Think about this: if you’re doing well in San Francisco, working in tech or finance or whatever, and someone grabs your wife’s iPhone while she’s walking down Market street, or busts out your car’s windows so they can sleep (and urinate) in it, how does your complaint not include a classist element to it?

If you’ve been stolen from, it means you have something to steal. And if someone is desperate enough to break into a car to sleep or urinate, then the amount they improved their life should have massively outweighed the amount it inconvenienced yours.

Speaking of that, San Francisco just adopted new language guidelines that require convicted felons to be referred to as “returning residents”, and other euphemisms, because calling them felons is damaging to their character.

This got me thinking more about this violent conflict of intuitions.

Let’s say someone is sleeping at home and gets woken up in the middle of the night. Someone barges into their bedroom, hits them in the head with a baseball bat, knocks them out, and when they wake up their cash, their jewelry, and their video game console has been stolen from their house.

In one world, the person who broke in and assaulted someone would be a criminal, and worthy of scorn from the community.

But in another world—which I do not deny is real—that person is what San Francisco might call, a “Recipient of Negative Privilege”. In short, bad things happen to them due to other peoples’ privilege.

Why are they homeless? Because our government won’t educate and house people.
Why are they on drugs? Because our government won’t provide good jobs and mental health care facilities.
Why are they violent? Because we would rather build jails than schools.

These are all true things. The victim in this case is actually the attacker, because he’s the one with such a shit life that he has to break into peoples’ houses to get enough money to survive.

But at the same exact time—and equally true—we have the fact that personal responsibility (as illusory as it is at the level of biology and physics) must exist as a backstop for human civilization.

You can’t build a just society, where people treat each other well, if everyone believes that their choice to be a bad person can ultimately be blamed on someone else. It’s untenable.

This is the paradox that San Francisco—and the entire West—is stuck in today.

The world is unfair. Both advantages and disadvantages compound over time. And without extreme pressures (Piketty) such as war or disease, the results of those disparities will represent as growing education and wealth privileges over time.

Our challenge is to find a way to hold two opposing ideas in our collective minds simultaneously:

The world is unfairly scripted by nature and nurture, and becomes more unequal over time
For society to work, people must behave as if they have full moral responsibility for their actions

In the first case, we must be the external force that equalizes things—so that war and famine doesn’t have to. And in the second case, we have to maintain law and order so that the powerful, rich, and lucky don’t just build a wall between themselves and the Unfortunates.

As it turns out, it’s not just life that’s Absurd. It’s everything about our lives.

Our society is Absurd because Free Will is absurd.

The person who broke into your BMW to defecate could not—based on the laws of physics—have done otherwise—unless the universe were different at that exact moment. He had a bad set of variables, and you had a good set. Congratulations on picking your genes and your upbringing. And yet we must behave as if this guy had full control over the state of the universe.

The illusion is necessary.

Anyway, I think the approach by San Francisco is a mistake. For one, it’ll get Trump re-elected because it’ll force left-leaning people with cars full of poop to vote defensively. And second, the illusion of control is actual extremely empowering for people trying to improve themselves.

Because while it’s true that a given struggling person will either succeed at pulling out of their tailspin or not, we don’t know which it is. So we have to teach the illusion that it’s up to them to decide—that it’s all about personal responsibility and hard work—and then see if they can reach escape velocity.

That’s the only way out of any of this—for individuals, for cities, for countries, and for humanity in general.

We have to act as if it’s up to us to be better, and hold ourselves accountable.

—

Become a direct supporter of my content for less than a latte a month ($50/year) and get the Unsupervised Learning podcast and newsletter every week instead of just twice a month, plus access to the member portal that includes all member content.

Vim Config Update: 2019 Edition

I like to update my Vim configuration every 2-5 years just to make sure I am as ninja and efficient as possible.

My full Vim Tutorial

But the last few times I’ve been focused on one main thing: simplicity. In my previous cycle that meant moving from Vim 7.x to Vim 8, which included a completely different way to manage plugins.

This time the impetus is a book—specifically Modern Vim, by Drew Neil—and I’m using it to not just update with some new tricks, but also to simplify my Plugin management.

So what you’ll find below are all the changes I’m making to my config for 2019, with many of them coming directly from Modern Vim.

1. I moved to Neovim

The Modern Vim book—so basically Drew Neil—was heavily pushing Neovim so I decided to take a couple hours to explore it. Short version is that it’s a cleaner, trimmed-down, more performant version of Vim with a better development community. Check, check, and check.

It feels so great to just start over.

So I migrated. But I didn’t use the training wheels (importing your previous .vimrc)—no, I started from scratch. It felt so good.

2. .vimrc pruning

The first thing I do when I start an update/cleaning session is go into my .vimrc file and pull out stuff I don’t understand or remember. Usually this is from some random thing I heard of somewhere and wanted to try, or from some previous hack regarding plugins. Ideally I’d like to not have a single setting in there that I don’t understand, but over time these grow so as to make that a high standard.

This year, though, I really did it. Because I moved to Neovim I just completely started over (see above).

3. Updated Plugin management with vimpack

Ok, so this is the craziest thing. This is perfection. Valhalla.

In previous versions of Vim you had to sacrifice all sorts of animals to be able to manage plugins. You could do things manually, you could use Pathogen, you could do custom stuff—etc. But it was all kind of gross.

Even with the latest upgrades in Version 8, you still had management problems with plugins that you had in plugins/bundle/something/something/ because if they were git repositories (why wouldn’t they be) then they threw errors when you tried to update them.

Well, now there’s a new system altogether, called Minpac. It’s so sweet. Check this.

Vim plugin management using Neovim/Minpac

So, all you do is add those lines of code to your Neovim install, and it will—get this—automatically install them and keep them updated!

In fact, you don’t even have to start with plugins installed (other than maybe Minpac itself) since Minpac installs them all into its own folder structure and handles everything.

I’m very happy right now.

4. A few new tricks

And here are a few changes/efficiencies I’ve picked up in the last few days of studying.

# Copying and pasting from the system clipboard

It’s always been annoying to have two separate clipboards—one in Vim and one in macOS (or whatever OS you’re on). Well now you can deal with them both independently or copy and paste between them.

vnoremap y "+y

# Changed my leader key to "'>" (single quote)

I’m a huge fan of using leader shortcuts, but for some reason the SPACEBAR wasn’t working for me. So I changed it to “‘” a single quote, which is one key to the right of my right hand’s pinky finger. Super efficient.

# I remapped the ":" shortcut (which normally requires Shift-;), to ";"

This just makes it easier to enter commands from within Vim; my right pinky is already sitting on the “;”, and now it’s just one stroke instead of a SHIFT chord.

# Added a few key leader shortcuts


Save file (leader-w)
Save and exit (leader-e)
Exit without saving (leader-q)


Summary

So here’s what I now have:

Neovim instead of Legacy Vim.
A completely new vimrc.
A completely new way of managing plugins that is completely built-in and automatic.
A few new tricks.

Here’s my $vimrc for anyone interested.

Solid upgrade.

Notes


There is some wrangling that needs to be done to get Neovim installed and configured, but it’s outside the scope of this article. It’s not too terribly difficult really; it’s mostly just realizing that Neovim works off of a init.vim file instead of .vimrc, and that it uses a different directory structure. Other than that most stuff is pretty close to identical.
My $VIMRC.

—

Become a direct supporter of my content for less than a latte a month ($50/year) and get the Unsupervised Learning podcast and newsletter every week instead of just twice a month, plus access to the member portal that includes all member content.

The ŌURA Sleep Tracker Ring

I’ve been looking for a sleep-tracking solution for several years, but hadn’t been able to find anything.

I was thinking about getting a sensor that goes under the sheet on the bed, but those seemed kludgy. And the wearables I’d seen thus far didn’t feel ready. But after hanging out with my buddy Mike Dahn recently I saw he was wearing a ring that looked pretty nice, and I asked him about it.

It turned out to be an ŌURA Ring, which is a full-featured activity tracker focused mostly on sleep. Perfect.

I’ve only had it for a couple of days, but it’s gone well so far. It charges quickly and the battery is supposed to last for several days, and the sleep data is available in both the standalone app (which is quite nice) and the iOS Health app as well.

To me this closes the loop on activity monitoring for the near future (assuming I stick with this device). I feel like sleep tracking was the one piece that wasn’t present in my current life measurement stack.

The battery is supposedly decent
I have the matte Titanium one, and it looks decent
You can wash your hands with no issues
It doesn’t seem overly prone to scratches
The integration with iOS appears to be seamless

Those are pretty much all my checkboxes, and despite never having worn a ring in my life—here I am.

If you’ve been looking for a sleep tracker that doesn’t involve putting something on the bed, this might be your move.

—

Become a direct supporter of my content for less than a latte a month ($50/year) and get the Unsupervised Learning podcast and newsletter every week instead of just twice a month, plus access to the member portal that includes all member content.

Summary: Never Split the Difference

10/10

My One-Sentence Summary
Content Extraction
Takeaways

My book summaries are designed as captures for what I’ve read, and aren’t necessarily great standalone resources for those who have not read the book.

Their purpose is to ensure that I capture what I learn from any given text, so as to avoid realizing years later that I have no idea what it was about or how I benefited from it.

My One-Sentence Summary

This book gives you negotiating skills so good that I feel guilty telling you about them—because they can be used to seriously manipulate people.

Content Extraction

The key to negotiation is deep listening
Tactical empathy is listening specifically for the real obstacles that are stopping progress
Mirrors are used to let people know you’re empathizing with them, and to keep talking so you learn more about the situation
Labeling is when you call out the obstacles you’ve heard while listening, like saying, “It sounds like you think I’m here just for myself.”, or “What I’m hearing is that you care more about the quality then making a dollar.”
Hearing “no” is often far better than yes because it gives you information about boundaries and sensitivities
There are three kinds of yes: counterfeit, confirmation, and commitment
What you really want to hear is, “that’s right”, and you can get there partially by labeling their emotions
Pivot to non-monetary terms
Ask calibrated questions like, “How am I supposed to do that?” to get them to talk more and to learn more about the situation
Only 7 percent of a message is based on the words while 38 percent comes from the tone of voice and 55 percent from the speaker’s body language and face
When calculating final amounts, use precise non-round numbers
At the end also add in a non-financial request to show you’re finished
Find the black swan information that can help you avoid disaster and get what you’re after

You don’t rise to the occasion in negotiations; you fall to the least level of preparation.

Takeaways

Read this book once every two years
Don’t share this book with evil people; it’ll introduce harm into the world
Use these techniques for mutual benefit, not to screw people over

You can find my other book summaries here.

Notes


Seriously, this is the closest thing to magic spells I’ve ever seen in a book.
One of my only 10/10 reviews.

—

Become a direct supporter of my content for less than a latte a month ($50/year) and get the Unsupervised Learning podcast and newsletter every week instead of just twice a month, plus access to the member portal that includes all member content.

Unsupervised Learning: No. 190 (Member Edition)

This is a Member-only episode. Members get the newsletter every week, and have access to the Member Portal with all existing Member content.

Non-members get every other episode.

Sign in

or…

—

Become a direct supporter of my content for less than a latte a month ($50/year) and get the Unsupervised Learning podcast and newsletter every week instead of just twice a month, plus access to the member portal that includes all member content.

How Weaponized Grit Can Lead to Unhappiness

I’m reading an extraordinary book right now, called Range: Why Generalists Triumph in a Specialized World. As you may infer, it’s about the advantages that generalists have over specialists, and how those advantages are increasing.

I think one of the most interesting things the book has done for me is show me how grit can have a downside.

Since learning about it several years ago, I’ve always seen grit as the ultimate superpower—the one attribute (along with creativity) that enables someone to win.

But the book does a great job of showing how it can actually be twisted into a negative. The mechanism for that is fairly straightforward: you have an overly goal-driven family (often immigrants to the West) who imbues their kids with massive amounts of grit and self-discipline, which in turn forces them to choose their forever life when they’re very young.

The book argues a few really interesting things about this. First, it argues that people who pick early and specialize are often not the best in that thing, especially if it benefits from a breadth of knowledge. Second, it argues that people in that situation are not likely to be happy, since it’s often nearly impossible to know what you really want until later in life. Perhaps late 20’s or even into your thirties or 40’s.

The book gives multiple examples of great people who butterflied around multiple things, and failed at most of them, before finally falling (often by luck) into the thing that they were great at and that made them famous. One should be cautious of such examples, since you don’t know the percentage of the dataset they represent, but the examples of Van Gogh and Darwin were quite compelling regardless.

I also loved how they mentioned numerous examples of where cross-domain knowledge, and integrators, win the day. The author also talked about Superforecasting, which is one of my favorite books ever about thinking.

Specifically, it talked about how cross-domain thinkers were far better at predictions than people who were deep—and especially famous—experts in their fields. A big lesson there for me was to always watch for blindness caused by ego, i.e., the more you think you’re an expert in prediction in a complex field that you’re known in, the less likely you’re good at it. That’s a mistake I hope to always remain aware of.

Anyway, I highly recommend this book.

It provided ideas for what an ultimate curriculum should look like, which is one of my long-term life projects. In short, that a perfect education should involve lots of dabbling and exploration, and a final path should be eased into rather than forcefully selected. This is for a better type of society, by the way, not necessarily your current 17-year-old.

Most importantly, it taught me that grit should be applied in a more broad sense, to overall goals, and not to artificially acquired targets given by others.

It’s not heroic to sit and grind for hours or years on an instrument or a career that you don’t care about, when you could be much better at—and successful in—something else entirely.

It seems that grit, like emotion or technology, is a tool that you must use carefully.

—

Become a direct supporter of my content for less than a latte a month ($50/year) and get the Unsupervised Learning podcast and newsletter every week instead of just twice a month, plus access to the member portal that includes all member content.