When I first heard about programming bootcamps, my assumption is that they were scams — the slightly more modern version of ITT Tech (which has now been shut down). They had the same characteristics: for-profit, not well-regulated, targeting people who are eager to turn their career around, etc. I figured it had all the same pitfalls. Even if the founders had good intentions and weren’t trying to take advantage of people, that didn’t mean the results were any good. Plus, they were only three months long; how could the education even come close to a four-year program?

My point here is that if you’re looking down on programming bootcamps as stupid, then, hey, I was with you. Was.

Then I went and talked at a programming bootcamp about technical interview preparation. This isn’t a fluffy be-your-best-self talk. This is a technical talk going over Computer Science topics — data structures, algorithms, etc — and talking about specific, challenging problems. Having done this talk many times and interviewed people after it, I have a decent ability to match the reaction of an audience to their overall skill level.

Surprisingly — to me — the students at this bootcamp were basically on par with those at good universities. They had actually covered the basics of computer science and seemed to be reasonably bright. Interesting.

I learned more (and thought more) about the bootcamps, and it made a bit more sense.

How do the academics compare?

Computer Science programs require around 40 classes and four years. So how could you possibly do this in three months?

Well, those 40 classes are mostly not CS.

Let’s take University of Pennsylvania’s CS major. That’s 40 classes total, only 14 of which are actually CS classes.

• 4 are foundational computer science classes: programming, data structures and algorithms. This stuff is really important.
• 1 is a math-based computer science class. I know this class well. It’s nice to have, but not critical.
• 6 are electives. Electives help build experience, but clearly you can go without any specific one of those. After all, each specific elective is not taken by most students.
• 3 are low-level stuff (operating systems, computer architecture, etc). Nice to have, but not critical.

So can you learn that really critical 4 classes in 3 months? Absolutely. After all, students are taking 4–5 classes at any one time in college.

In practice, a bootcamp will probably skip some of the less essential topics within algorithms. That’s fair, since their goal is to create programmers, not academics. They’ll replace that “missing” stuff with a lot of more practical knowledge.

Are bootcamp grads as good as university grads?

No, but the issue isn’t the academics as much as it is time. University students got internships and four years to do projects (on their own time and for classes).

This doesn’t mean programming bootcamps are bad at all though. The comparison is just totally unfair.

You’re comparing a three month investment and asking if it’s comparable to a three-year-nine-month investment. And if it’s not, this means aspiring coders should go to college instead of a bootcamp? No!

A more fair comparison is this: take a bootcamp graduate, let them code for 3.5+ years after that, then compare them to a new university grad. Now who will be better? I’ll put my money on the bootcamp grad — all else being equal.

Bootcamp grads are junior — very junior. But time will fix that.

So you’re saying aspiring coders should go to bootcamps instead of college?

If you want to be a programmer, forever and always, then sure. Skip college.

Note: this is career advice, not life advice. College provides useful life experiences. It’s also really expensive though. It’s a tradeoff.

Yes, you’ll miss out on some Computer Science education. If you’re concerned about that, learn it on your own. You’ve just gotten an extra 3.5+ years of your career back.

Some companies will be biased against you because of your lack of college degree. That’s a downside. But your extra 3.5+ years of experience can compensate for that.

The bigger challenge comes from when you want to move outside of programming. Will you be given the same respect and credibility? I’m not so sure.

There’s such a lack of great programmers, and it’s relatively easy to assess skill here (or at least it’s believed to be), that companies will often look the other way with programmers who lack degrees. When you look at jobs which have lots of qualified people, companies can afford to — and often do — get more stringent. Experience can make up for this, but not quite as effectively.

But but but…

All of this is “in general.” You are not “in general.” You are a specific person with specific choices.

If you’re choosing between MIT and random-mediocre-bootcamp, MIT will probably get you farther. If you’re choosing between a poorly-ranked-university and a pretty strong bootcamp, the bootcamp will probably be better.

I do not think either path is the “obvious” choice for an aspiring programmer. It very much depends on your options and your goals.

Suffice it to say: bootcamps are not a scam. Some bootcamps might suck, but that’s true for colleges too.

So that whole coding bootcamp thing is a scam, right? was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is a graduation speech, and I’m what one might call a professional interviewer, so it’s fitting that I would ask you this quintessential interview question: Where do you see yourself in 10 years?

But I’m not going to ask you this question because, to be honest, I kind of hate it. I’ve never been a big fan of this question.

It’s not that I object to goals. It’s fine to set some vague goals that you might want to be doing X, Y or Z in 10 years.

But this idea that you can set some vision of being somewhere in 10 years and then detail the steps to get there? I just don’t think that’s realistic.

And to be honest, I’m not even sure it’s a good idea.

Anything But That

If I think back to where I was 10 years ago, I was (pretty much literally) in your seat.

Just about 10 years ago, I graduated from Penn with my masters in computer science. If you would have asked me what I want to do in 10 years, there are two things I would absolutely not have said and that was being a writer and being an entrepreneur.

I didn’t want to be a writer because I didn’t like it, I didn’t think I was particularly good at it and — frankly — it wasn’t exactly known as a lucrative profession. There’s got to be some reason to do something and you’ve pretty much nixed every single reason.

As for being an entrepreneur: that wasn’t something I wanted to do either. I come from a family of entrepreneurs, and from everything I’d seen, this was really, really hard — an incredible amount of pressure. This was not the lifestyle I wanted.

I figured I would probably wind up on the technology management track at some big company.

Naturally, 10 years later, here I am doing exactly what I said I wouldn’t do: entrepreneur and author. So much for life’s plans…

It Turns Out, I Do Like It

My company, CareerCup, does a bunch different things related to technical hiring, both on the candidate side and the hiring side. One of these things is book publishing. I’ve written three books, two of which are independently published by CareerCup and is among Amazon’s top few hundred best selling books.

It turns out I can write — at least for my kind of books.

As for founding a company, this also is not the lifestyle I imagined. It’s hard at times, of course — and scary and unpredictable.

But I’ve carved out my own version of the entrepreneur lifestyle. And my version comes with a degree of freedom, control and impact that I didn’t really get to see from the outside growing up. This thing that I thought I’d hated — that I had sworn off — actually turns out to be a pretty great fit for me.

I get to take all the things I love — solving hard problems, coding, teaching and explaining concepts, making an impact on people’s lives, building better processes for the future — and blend them into this strange little niche business.

So how did I get to be doing this thing that I absolutely didn’t want to do?

Well, to be honest, it just kind of happened. It found me, more so than I found it.

How I Got Here

It started actually when I was at Penn. Even while I was saying I didn’t want to start a company, I was actually doing exactly that.

I was a TA for Max Mintz — the infamous Max Mintz — and one of my students asked me to take notes on the different companies I was interviewing with and my reactions to that.

Of course, I said yes.

I started a Word document of the different interview questions I was asked and what I thought of all these different companies.

Still an engineer at heart, I thought it would scale better if I posted it on my personal webpage. After all, why create a simple document to email to her when I can spend far more time over-engineering a solution by building a website to do this?

Then, that little toy website grew and grew. And I started adding on this and that feature in my spare time. Two years later, I was running this kind of popular website around interview questions.

Despite all that, I was still saying I did not want to start a company. I didn’t realize I already had.

Becoming a Writer

I became a writer through a somewhat similar path. My users had been asking me for additional resources for interview help — something more specialized for technical interviews. There were a few things already out there, but on a whim I just went ahead and did it.

It wasn’t a real book, per se. It was just a little 20 page document.

But somehow that little document became really successful. People really liked it. Again, it grew and grew and eventually it really was what you could call a book.

Rules are Rules: Part 1

Consulting, too, just kind of happened.

I got an email a few years ago from a CEO of a local startup. He’d seen my book and wanted me to prepare his team for their upcoming acquisition interviews. This entailed basically a week of straight, back-to-back interviews.

I had done all day interviewing like this when I was at Google. It was tedious and exhausting.

I was about to say “no” and then I stopped myself.

See, I had developed this rule for myself. It’s very complicated, so try to pay attention.

The rule is called Say Yes. It goes like this: If I’m about to say no to something, say yes instead. Very complicated, I know.

There were exceptions, of course, for really good reasons. But “I don’t feel like it” doesn’t qualify as a really good reason.

I had realized by then that a lot of the best things that happen in life are not things that we can predict. They’re not things that we could’ve planned out and said, “Oh, to get to point D, I’ll do step A then step B then step C.” A lot of stuff just happens to us. There is so much luck and randomness in life.

Life’s Not Linear

Somewhat begrudgingly, I said yes. I figured I had to follow my own rule, even when I didn’t want to. Rules are rules.

It turned out that interview coaching was totally different from real interviews, where I had to write up lengthy feedback that the vast majority of the time results in a rejection. It was very different from what I had done at Google.

Doing real interviews all day was very tedious. Teaching interviewing all day was actually interesting.

Things went well — and continued to go well. The CEO told his friends and they told their friends. Pretty soon I was doing this weird funky thing that called acquisition interview consulting.

No one could have said that this is something I would be doing one day because no one would have known such a service should exist.

So a linear plan of life of where you going to be in 10 years? Please. That’s not realistic. Life isn’t graphed on some smooth, straight line. It’s worse than a step function; it’s not even two dimensional.

Rules are Rules: Part 2

A few months after this company got acquired, the CEO — now at this big company — approached me again. He said, hey, you seem to know interviewing well. Why don’t you come in and help train our interviewers?

I’d never done that before. All my work was on the candidate side, not on the hiring side. To be honest, I wasn’t totally sure I knew how to do that.

But, shoot. The pesky Say Yes rule. Fine.

And thus was created this new line of business for me. Who knew?

The crazy thing is that none of this could have happened without that one little a “yes” years ago — and dozens of other yesses along the way.

It’s So Easy to No

It’s so easy to say no. We say no because we don’t feel like it. Because it sounds boring. Because we’re busy. Because we don’t see what we will get out of it. Because the opportunity seems too small and not worth our time. Or because it seems too big, and we just don’t think we’re good enough.

But when we do that, we miss out on so much. The truth is that you don’t know where life is going to lead. You don’t know what you’re going to actually love doing until you’re doing it. You don’t know what you’ll really be good at until you’re there.

If you only say yes to the things that get you from point A to point B, you lose out on the luck and randomness in life. You may wind up chasing a dream that you don’t actually want and foreclosing yourself to the things you do.

Say Yes

Say yes to all the unknown and the unpredictable and even the no’s. Open yourself up to the opportunities this brings. And then run like crazy once you get there — wherever you are 10 years from now.

Thank you.

Candidates are routinely surprised when it does because they don’t quite understand the interview process and how they are evaluated.

Let’s start with just the part about the code being “correct.” Is this necessary? Is it sufficient?

It’s neither, in fact. Consider the real world (which, after all, is what interviews are attempting to be indicative of). Is it okay to have a bug in the real world?

You probably find it a little difficult to answer that question. Bugs are never “okay.” All else being equal, you’d prefer the bug-free code over the buggy code. But one bug doesn’t usually get you fired. If it did, then none of us would have jobs.

Likewise, in an interview, the ideal is obviously to not have bugs. Bugs are never “okay”. If you can avoid a bug, you should. And clearly your interviewer prefers to see fewer bugs. That doesn’t mean that you’ll get rejected just because you have a bug.

In fact, I rarely conduct an interview where the candidate doesn’t have at least one bug. What matters is what the bug indicates and how they fix it.

What the Bug Indicates

Here’s what you need to understand about evaluation: Your code is a code sample from which your interviewer extrapolates information about your coding skills. Correctness is not important, in and of itself.

Consider Java code like this:

LinkedList<String> list = new LinkedList<String>();
list.insert(“hello”);

This code has a “big” bug (or, rather, compilation error) that will 100% break if you were to compile it. In line 2, you should have written add, not insert. If you released this code, your product would be 100% dead (until, of course, you fix it).

But interviewers aren’t crazy and they won’t reject you for this. They probably won’t even notice.

Your whiteboard code is merely a code sample from which your interviewer will derive information. The information that I derive here is that you probably don’t use the built-in linked list class much. Do I care? Not even a little bit.

What about code like this?

int getMax(int[] array) {
   int max = array[0];
   for (int i = 0; i <= array.length; i++) {
      if (array[i] < max) {
         max = array[i];
      }
   }
   return max;
}

We have a few issues here.

1. This code will crash at line 2 if the array is null or empty.
2. The for loop starts at 0 when there’s no need for it to. It should start at 1.
3. The for loop goes through array.length. This will cause an exception every time.
4. The comparison on line 4 is backwards.

To have four bugs in such a simple piece of code worries me. I will conclude that you probably write buggy code. In fact, bug #3 will cause me to wonder how often you write code; it’s pretty strange to mess up a very basic for loop pattern like this.

Now, what about this? (Yes, this is real code that I saw an interview.)

int getMax(int[] array) {
   int max = array[0];
   for (int i = 0; i < array.length — 1; i++) {
      if (array[i] > array[i + 1]) {
         max = array[i];
      }
   }
   return max;
}

This isn’t just carelessness. The code doesn’t even make sense algorithmically. I’m very concerned about that.

If you find and fix these bugs easily, I’ll be slightly less concerned (but of course it’s still better if you didn’t even make them). This brings me to the second part.

How You Identify and Fix Your Bugs

Many candidates panic when they find a bug. A particular test case reveals a bug, and then they make a quick fix. The “fix” resolves it for that test case, but perhaps doesn’t fix the true issue.

For example, consider this code to locate all instances of a string s within a string b:

int countSubstrings(String s, String b) {
   int count = 0;
   for (int i = 0; i < b.length() — s.length(); i++) {
      String bSubstring = b.substring(i, i + s.length());
      if (bSubstring.equals(s)) {
         count++;
      }
   }
   return count;
}

At first glance, the code basically looks correct, but it’s not. (Did you notice the bug yet?)

Many candidates spot the bug when they throw in a test case like a = “xyz” and b = “xyz”. That’s when they notice that the for loop never gets executed at all.

The weaker candidates will jump immediately to a fix. They’ll think that there’s a special case when a and b are the same length, and they’ll throw in an if statement at the very beginning to handle this.

That’s not the bug though. There’s always an off-by-one error. The if statement comparison should have read b.length() — s.length() + 1.

I am less concerned by the existence of this bug than I am by a bad fix. Bad fixes don’t correct the issue and they add unnecessary code that might linger (even after the true bug is discovered) and they cause us to think we no longer have a bug and sometimes they even introduce new bugs.

When you find bugs, think before you fix!

But that’s not all…

Finally, understand that correctness is just one thing an interviewer is evaluating in your code. Depending on the interviewer and the problem, the interviewer might be looking at technical knowledge, code style, organization / modularization, compactness, and other attributes. The code you write is offering a data point about your coding skills, and it is evaluated as such.

In fact, the same can be said about the algorithm / problem solving portion. It too is not evaluated on a binary “did you get it correct” basis. Rather, it’s a data point about your analytical skills, computer science knowledge, and other attributes.

Some candidates are surprised to get rejected even though they got a problem “correct”. What they don’t realize is that correctness is usually not sufficient (and may not even be strictly necessary). You can get a problem “correct”, but still demonstrate weak analytical skills or weak coding skills. Everything that happens in the interview offers data points from which I extrapolate. It’s not about “correct” or “incorrect.”

You’d think I’d speak at Grace Hopper, right? It’s right up my alley — women, tech, etc.

So let’s cut to the chase. This is why you won’t see me there: Speakers must pay to speak [1].

I do lots of talks — over 100 per year — and I almost always charge something. Doing a talk isn’t free. It costs me time, and therefore money. This is my job, and therefore I’d like to be compensated for it.

Importantly, an organization paying something [2] also sends a signal that they value my presence. This isn’t vanity; it’s just good business. If they value my presence, then they’ll probably consider appropriate time slots and they’ll probably put some effort into advertising the talk. They’ll do their part to ensure there’s an audience. I am more likely to get something out of the talk if the organizer is willing to put something into it.

GHC (Grace Hopper Celebration) is indeed sending a signal, but the opposite one [2]. Not only do they not cover a speaker’s fee or travel, but they actually require speakers to purchase a (discounted) conference ticket. A speaker is charged to attend.

EDIT/UPDATE: Unlike in past years, where speakers had to purchase a ticket for the day of their talk, this year GHC is comping the day-of pass for speakers (although not for people presenting posters). Speakers still must purchase a ticket for the remaining days. This is a good start. It somewhat mitigates the issues described here, but it does not by any means eliminate the signaling or the financial burden.

To be very clear, this is not about the money (for me, anyway). It’s about the message that they’re sending. They don’t value my presence; I’m just another customer. I conclude from this that it will probably not be a good use of my time to speak. No thanks.

It also means they have an incentive to have lots of speakers, even if that brings down the quality somewhat. Speakers have dollar signs attached to them. Conference goers should be concerned about this.

Some speakers, especially those who are not tied to a big company, won’t able to afford to speak. This again brings down the quality of the conference, and creates a bias towards more privileged speakers. This is something attendees should be concerned about too.

The setting of a women’s conference makes GHC’s policy extra problematic. Women are already less likely to ask and advocate for themselves. This is the first speaking opportunity for many younger women, and GHC is sending them a message that they shouldn’t expect to be compensated for their work.

It is of course true (and I’m saying this in part to preempt the Internet haters) that GHC has the “right” to charge its speakers. Perhaps this is a simple business calculation that GHC has made around speakers and dollar signs. The armchair economist in me can somewhat appreciate that.

I also have the “right” to interpret the signal they’re sending, to not speak as a result, and to advocate for change. You can join me if you’d like. Maybe they’ll change their policy if enough people are upset by it, or if they realize the signal they’re sending.

Or, if you think this policy is fine [3] and decide to speak/attend, that’s cool. I’ve heard good things, so have fun if you go.

[1] How much I charge varies depending on the kind of exposure the talk offers, the mission of the organization, and other factors. Sometimes I will do talks where the organizer just covers travel. But at least that’s some form of sacrifice on their part. Their willingness to sacrifice increases the odds that this will be worthwhile for someone, ideally for both me and the audience. It sends a message — an important message.

[2] This applies to speakers who apply. Their super famous speakers might well be compensated.

[3] As for the GHC organizers, if they ever read this: I harbor no hard feelings or ill-will towards you. I’m not saying that I would *never* speak at GHC (only that I wouldn’t speak through the apply-to-speak path, as those speakers aren’t valued enough to make it a good use of my time). I’m not even saying you’re making the wrong decision. You know far more about your goals, audience, and financial situation than I do. The policy (the harsher past policy and the more moderate current one) did signal that these speakers aren’t particularly valued. It’s not necessarily bad to send this signal if the message is actually correct.

You know what that’s time for, right? It’s time for the Internet Hate Machine. Let the games begin!

Read through their Twitter. Go back years if you have to. Find everything that confirms our assumptions about them, derived from the obviously representative One Bad Thing They Did.

Now do the same for Instagram and Facebook.

Quick! Before they have the audacity to make their settings private.

Have lots and lots of people send tweets attacking them. Then write some articles, too. Some medium posts, for sure. If we’re lucky, maybe BuzzFeed or Gawker will repost one. That’ll ensure their content is preserved (perhaps without context, but whatever).

Don’t stop. Let’s all do our part. Each comment or article is justified, therefore the entirety is. The whole is equal to each individual part, right?

If you can find someone who knows the person, no matter how limited or biased their interaction is, check if they can corroborate our assumptions. That’ll be the nail in the coffin, lest anyone have any doubt about whether we’re being presumptuous. Then we can prove that, really, we were totally right about them. It’s not just that One Bad Thing They Did. They’ve done other bad things, too.

Oh, and we should definitely get them fired. Honestly, they don’t even deserve to have a job after the One Bad Thing They Did. Particularly not in that field, of all things — ha!

Finally, just for good measure, throw in the occasional rape or death threat and — if we’re so lucky to have a non-white target — some racial slurs too.

I’m joking, of course.

Of course, we shouldn’t post threats or slurs. No, no, that would be wrong. That’s where we’ll draw the line.

That other stuff is fair game though. If our attacks create an environment that engenders those “bad” attacks, then that’s hardly our fault. We couldn’t possibly see that coming.

And, besides, after that One Stupid Thing They Did, they deserve it. They should have seen it coming. What did they expect?

Or, we could just not act like jerks.

We could consider that, although they did something stupid or wrong or whatever, the entirety of their attacks exceeds the wrongness of the One Bad Thing They Did. We could realize that we don’t need to be another voice condemning them, another shove in a hateful crowd.

We don’t need to make their life worse — even though we think they screwed up. We can choose compassion and empathy, even with those who are at fault.

If we really want, we can even engage in a broader discussion about the points they raise (Is minimum wage livable and ethical? What do we do about behavior that makes people uncomfortable?). That’s not only kinder, but far more useful in the short and long run.

Wait, what am I saying? It’s a lot more fun to attack and laugh at them. They’re just another online name — more of a meme than a person, really — and it sure makes us feel better about ourselves to attack them.

After all, this won’t ever happen to me or you. We would never make that exact mistake. We won’t ever have the Internet Hate Machine judge us for that One Stupid Thing We Did last week, last month, last year. No one saw us that time, so we’re safe.

Or, we could just not act like jerks. was originally published in Be Yourself on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you want an A+ career in technology, you should move to the San Francisco Bay Area. The same argument can probably be made of finance and New York. It’s not that you can’t do it in another city, but your odds are just much better in your industry’s hub. So if you want an A+ career and your industry has a clear hub, go there.

I spent the first four years of my career in Seattle. I loved my time there, and built some fantastic friendships. Years ago, I probably would have advocated for Seattle being a fantastic tech city: enough tech companies, but way cheaper.

Now that I’ve moved to the Bay Area, I realize that Seattle just doesn’t compare. (Sorry.) You can argue about the advantages and disadvantages of the Bay Area’s culture, but the biggest thing is the numbers. The Bay Area has far more tech companies of all sizes and niches.

When your criteria are broad enough (e.g., {coder + cool startup}), these alternative tech hubs may be good enough. As people get more experience though, they start to refine their filters. Now it’s {short commute + security space + under 20 developers + consumer space + product management}. Your options have now dwindled down to zero — or one or two, but then you’re rejected from those. Oops.

So you relax some of your constraints. What choice do you have? You wind up at the company that’s a A- match, rather than the A+. It’s not growing as fast, or it doesn’t leverage your background, or it’s not really the right culture. You’re on the A- career path now.

Moreover, because you only have A- options, you’re more likely to maintain the status quo. You don’t get yanked out when the A+ opportunity comes along, because it doesn’t. Instead you stay at your current “good enough” job.

And that’s totally, absolutely fine. You don’t need an A+ career. You can easily build an A- career in these alternative hubs — and often live much more affordably, too.

A close friend made just that choice and is happier for it. He has a B+ career, but that’s good enough. He finds his career fulfilling, but he doesn’t work too hard. Seattle’s comparatively affordable, so he can actually afford a nice apartment (unlike his San Francisco peers). He spends lots of time with his family and friends. He knew what he wanted, and he got it. Good for him.

But, notably, most of my highly career-driven friends have left Seattle. Those in tech have moved to the Bay Area, those in finance have moved to New York, and others have scattered across the country. I of course moved to the Bay Area, and the difference in opportunities has been remarkable. I just couldn’t have achieved the same things in Seattle.

Not all in the industry hub will reach this A+ career, and some who stayed back in the “lesser” hubs will. But if an A+ career is truly important to you, come to the Bay Area or wherever your industry’s hub is. It’s just a matter of probabilities.

If you want an A+ career in technology, move to the Bay Area. was originally published in Be Yourself on Medium, where people are continuing the conversation by highlighting and responding to this story.

But, what I first launched wasn’t really a book. It was a 20 page PDF of interview questions — without solutions. It could charitably be called an MVP (minimal viable product).

Only it wasn’t even that because I never thought about it developing into a real book. I was not a “writer” and was absolutely not going to write a book. It was just one of many monetization ideas for CareerCup I was playing with. I threw stuff at the wall to see what would stick.

It stuck.

That stupid little PDF which was totally never going to be a “book” has since grown to become not just the best-selling programming interview book, but the best-selling interview book period — plus the best-selling computer science book and Amazon’s #145th best-selling book overall.

What.

There was no elaborate strategy to write a book by testing out the marketing, getting early feedback, and iterating from there. That happened, yes, but it was definitely not my plan. There was no plan.

That stupid PDF was just something I threw together on a whim — like I had lots of other ideas. I’d read about someone else making a bit of pocket change selling eBooks, so I figured I’d give it a shot too. Why not? It’s not like my other ideas were working.

In fact, almost all the major turning points in my career were times when I wanted to say no to something because I didn’t really feel like it or didn’t feel ready for it or didn’t really see the point.

And this is what many people miss. You see the successes of successful people and you assume they “strategized” and then followed the right path. You don’t see that there were a whole lot of failures along the way. You don’t see all the unpredictability. You don’t see that many of their successes were not plans but rather whims — things they just did because… why not?

If I could give one piece of career advice to people, it’s this: Just say yes. Just do it. Try it. See what happens.

Accept that invitation to do a talk that you don’t really think you’re qualified for. Go meet that person for coffee, even if you don’t really see the point. Throw together that website that will almost certainly never lead anywhere.

Opportunities start from saying yes.

Say yes.