14 ms·

Profound Beliefs

112 points by sblank 3y ago

lisper 3y ago
I can give you a counterexample anecdote from my own career: I have spent my entire career writing code mainly in Common Lisp. I have a long list of successfully executed projects, some of which were done in the face of directly competing efforts written in other languages which failed spectacularly. I have a "profound belief" in Lisp, and I can justify that belief with a litany of empirical data and theoretical explanations. Nonetheless, every single time I have ever expressed that belief it has led to my career advancement being cut off and ultimately to the loss of my position and having to start over. So no, it's not enough to have "profound beliefs". You have to have the right kind of profound beliefs (unless you are extremely lucky -- see below). They have to not conflict too much with the profound beliefs of your management and co-workers because if they do you're sunk no matter how much data you have to back them up. That just turns out to be how the world works. I learned this lesson the hard way, and far too late in life for it to do me much good, but I thought I'd pass it along. There is one exception to this rule, and that is if you just happen to get have iconoclastic beliefs that are also correct and you somehow manage to acquire the resources to act on those beliefs and the results you produce happen to find a large market. Steve Jobs is the poster child for this, and even he is a cautionary tale because his career very nearly ended when he was first fired from Apple. It was only the good fortune of Apple management being utterly incompetent that gave him a second chance, which he seized on to spectacularly good effect. But Jobs was literally one in a billion.
- psyklic 3y ago
  I think Steve is approaching this from much more of a business angle. Looking at the Business Model Template slide in the article, programming language choice may not affect the business model much, except perhaps in rare cases where the language/tech achieves a business moat. Founders can definitely hold random theories about the business market/strategy, as long as they are willing to invalidate them (profound beliefs that are loosely held).
  - lisper 3y ago
    Lisp has a profound effect on the business model because it can give you a dramatic productivity boost (like an order of magnitude or more) but it makes staffing more difficult because there aren't many experienced Lisp programmers because very few organizations use it, which makes for a vicious cycle. But this is precisely the sort of situation that if enough people simply changed their minds that by itself could change the underlying reality. It's not just Lisp. There's a similar thing happening today with Rust, which is clearly superior to C from a technical point of view, but which very few people use simply because there are very few people using it. But Rust might be one of the rare exceptions where the technical superiority is enough to allow it to break this cycle.
    - mlyle 3y ago
      An order of magnitude "or more" is an extraordinary claim. The evidence just isn't there. > but which very few people use simply because there are very few people using it. Ecosystems matter: they're one of the ways you get productivity.
      - lisper 3y ago
        > An order of magnitude "or more" is an extraordinary claim. The evidence just isn't there. Let me clear: I am claiming that these kinds of productivity gains are possible, not that using Lisp will automatically give you a 10x improvement under all circumstances. And yes, I can give you concrete examples of demonstrable >10x productivity improvements which resulted in products succeeding where they otherwise would undoubtedly have failed. These are generally found in niche applications where there is a lot of domain knowledge that needs to be brought to bear. So you're not going to see big wins in, say, commodity consumer products, which is the reason that the wins don't get much press. But the evidence is definitely there if you look in the right places.
        marginalia_nu 3y ago
        If it gives such a productivity boost, why aren't LISP shops outcompeting other languages?
- jimbob45 3y ago
  Steve for Objective C or just his design principles in general?
  - lisper 3y ago
    Steve (Jobs, not Blank) was an unparalleled visionary. I give him credit for the Apple II [1], the Mac, Objective C, NeXTOS/OSX/MacOS, and the whole i-series from his second stint at Apple (iMac, iPod, iPhone, iPad). To call him an overachiever would be quite the understatement. He is truly in a class by himself. I can't offhand think of anyone else in his league. (Elon Muck comes closest, but I'd rate him a very distant second.) --- [1] Yes, I know Woz actually designed and built it, but Burrell Smith designed the original Mac, and neither of those things would have been possible without Jobs.
    - growingkittens 3y ago
      Steve Jobs was a visionary authoritarian with the resources, opportunities, and connections to make Apple happen. Visionary authoritarians are dangerous to glorify.
      - lisper 3y ago
        I didn't intend to glorify him, only to defend my claim that he was an extreme outlier.
        growingkittens 3y ago
        Glorification doesn't have to be intentional. Steve Jobs left a trail of havoc in the lives of the people he used to build Apple. He did objectively bad things to achieve objectively good things, so to speak. The good result is tightly coupled to a bad technique. Omitting the bad technique is tantamount to glorification. The language in your posts is also very...enthusiastic? Speaking of hard workers, have you read about Niklas Luhmann?
        3y ago
- wmf 3y ago
  Steve Blank's lessons are mostly for founders and executives. Of course employees don't get to just choose different beliefs than management! Management sets the direction and you either agree, disagree and commit, or disagree and quit.
  - SoftTalker 3y ago
    Yes, but I'd extend that to really anyone who is responsible for making decisions about something. If it's your job to chose the development tools, you should have some profound beliefs about that. If it's your job to use the chosen tools to implement things, you really don't need to have any profound beliefs about the tools, and though it is helpful to understand the beliefs/motivations of those who are making the decisions, having your own (especially if contrary) is a recipe for "how to be frustrated at work."
  - neotrope 3y ago
    It applies to anyone in a leadership position. Staff/principle engineers fit that role. Though you're right, the parent comment suggests they're not in leadership.
  - Ancapistani 3y ago
    > Management sets the direction and you either agree, disagree and commit, or disagree and quit. In my experience, you missed the most common alternative: disagree and undermine.
    - don_neufeld 3y ago
      Yup, that’s the one that gets you fired.
  - CMCDragonkai 3y ago
    If you are hired to follow, then you are supposed to follow. You can give advice and suggestions but you have to fall in line when an executive decision is made. That's how a team works, otherwise you aren't doing your job. If you're hired to lead. Then you need to make decisions and you're responsible for the success and failure of those decisions. You should have profound beliefs about why you make your decisions but also be able to take advice and suggestions, but at the end of the day, the success or failure is on your responsibility, not the advice givers - thus you always have the right to not act on others advice and suggestions. It's important to know what your role is in any organisation. I actually like this 1995 movie Crimson Tide that illustrates these principles while exploring moral ambiguities and procedural issues while under huge amount of stress where the lives of not only men in the sub is at stake, but the lives of whole nations when it comes to making decisions and when it is a good time to challenge those decisions.
- heresie-dabord 3y ago
  > You have to have the right kind of profound beliefs We need not to be enormously blind to the existence of an entire transactional structure around us. One that antedated our arrival and will likely still be there to offer a sentiments card and flowers upon our departure.
- jjtheblunt 3y ago
  > It was only the good fortune of Apple management being utterly incompetent that gave him a second chance Not only: before that second chance, he set up its sensibility, as he had the willingness to test the idea that there was a growing market for widespread unix 'workstations'. his hardware was too expensive for a huge hobbyist audience, which I know as I had one, but NeXTstep and its tooling and resulting apps placed a solid foothold in a somewhat grotesque early 90s (from 1988 or so to even get that foothold). I had one, had been using Suns before, and very early microsoft before that, and apple ][ and atari 800. I think his getting fired is something his brazen young self sublimed into a determination to prove an idea's viability such that an evolution of his NeXTstep effort not only brought him back to a hardware company better able to execute on the hardware portion, but such that his post-firing gamble is evolved into things ubiquitous now.
- paulcole 3y ago
  > Steve Jobs is the poster child for this, and even he is a cautionary tale because his career very nearly ended when he was first fired from Apple A very bright and persuasive person being fired at age 30 isn’t even in the ballpark of “career very nearly ended.”
- YZF 3y ago
  How do you define a well executed project? I can think of some criteria that might be relevant: - Are the projects still supported? How easy is it to find/hire people to maintain them? Is it easy to add new features? What is the quality like? - Are they small/stand-alone or have they evolved into large systems with large teams working on them and many new features? - How would you characterize their performance and scalability? Can they expand to run larger workloads? Do they make good use of the underlying hardware? - Is there a good ecosystem, libraries, packages, drivers, etc. for the domain you're targeting? I don't think you necessarily need to avoid conflict completely but you need to decide what hill you are willing to die on. If your co-workers, team, management, disagree with you then you can either try to convince them or you need to find consensus somehow. They could be right and you could be wrong. I can think of many examples where a single person introduced new technologies or languages or methodologies to an organization (including myself) ... Most good organizations welcome this sort of contribution. Ofcourse big decisions require compelling arguments. I've also had what I think were really good/compelling proposals for change end up being rejected, that's tough, but life goes on. EDIT: This is mostly unrelated to the article but I think the principles in the article do apply more broadly. Having a belief is good, it is what helps us drive in the right direction, but we should constantly be open to new information that challenges our belief and adjust it if needed. The initial "belief" also has context, it's given some circumstances, what do we think is the right approach. Then as we move on and circumstances change, and we get more data, we adjust our belief. This is different than what I'd call religion. Religion never changes, pretty much by definition it can not change. You're not going to start working on Shabbat if you're Jewish, regardless of what new information comes up or the situation. If you have no belief however you're at the other extreme, you're doing random things without any strategy or plan for the future (which is sort of where the author was when he was scolded by his CEO in the story).
- ren_engineer 3y ago
  if your belief is that strong you should found your own company and build your software with Lisp and beat competitors by being able to launch features faster and with fewer engineers. Ruby got popular for a while because several successful startups used it, Python for similar reasons
  - lisper 3y ago
    Yep. I tried that. Turns out that not getting a product out the door is not the only way a company can fail.
- iseletsk 3y ago
  Re-read the article, it is truly great. It is not about "profound beliefs", but about "profound beliefs, loosely held". It is not about sticking with your believes, but about validating them, and changing them based on data. Now, talking as a technical CEO of midsize company, who coded in Lisp, and still codes: You are missing following pieces of data to justify your belief that List would be a good language for any projects for most companies: 1. Long list of successful companies with large Lisp codebases (are there examples of successful projects/companies based on such codebases) 2. Long list of examples of long term successful projects written in Lisp (how maintainable the code base will be if written in such language) 3. Long list of job positions for Lisp developers (ability to find more talent to expand the project when needed) 4. List of people in the company who can join the project (bus factor) Management does care about how long it takes to write the code. Yet, it is only one of many aspects. So, while your beliefs might be profound, they are ... short sighted.
  - lisper 3y ago
    > your belief that List would be a good language for any projects for most companies That's a straw man. I have never made that claim. I think Lisp could be effective in a lot more areas than those in which it is currently deployed, but I have never said that it would be good for "any" project or "most" companies. What I said was that 1) in the past I have advocated for my "profound belief" that Lisp would be effective for particular projects on which I happened to be working, 2) in those circumstances in which I was able to persuade the decision-makers to actually use it, it worked spectacularly well and 3) despite 1 and 2, the net result was a net negative impact on my career. This is not sour grapes, just a cautionary tale. Holding and advocating for profound beliefs is not always a good idea.
CyberDildonics 3y ago
I really wish vague no context titles like this wouldn't be allowed. I don't know who votes for two words with no other information, but it seems silly.
- deleted 3y ago
  [deleted]
- pvg 3y ago
  People click and read the thing and upvote it if they like it. https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=by%3Adang%20work%20a%20little&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
  - CyberDildonics 3y ago
    Why have titles at all if they aren't supposed to have any information in them?
    - pvg 3y ago
      Obviously, they have information in them, perhaps not information that's to your taste. "Why are titles that are not to my taste allowed" is at least a question that's relatively simple to figure out.
    - sixstringtheory 3y ago
      First you complain that the title doesn’t have enough information–more information please! Then you imply there should be no titles at all–less information please! Do you see the impossible double standard?
      - pvg 3y ago
        They're saying 'what's the point of titles if they don't tell me what's inside the tin.' There's no double standard there at all. It's an impossible one (unless promoted to Mystic Master of All Titles in The Universe or At Least on HN) but there's nothing double about it.
gumby 3y ago
> "I was executing a lot of ... “things” but why was I doing them?" This is a general problem, not just a marketing one: people who mistake frenzy for action and action for progress.
neotrope 3y ago
Love this article. 1. Developing beliefs and acting on them is a key part of leadership. 2. Without it, you limit career advancement. 3. It's a skill that can be learned.
wwarner 3y ago
I really like Blank's idea of a profound belief -- a vision of the future tempered with constant checks against evidence. With that picture, the word "bet" in the business context makes a lot more sense to me. Companies operate in the present, but they spend for tomorrow, laying track for where the company will be in the future.
j7ake 3y ago
Nice article, can be applied to the scientific enterprise. A scientist should have a strong enough about a paradigm so they can work with it, but loosely held enough to see the cracks in the theory and find the right problem that will change the field.

112 points by sblank 3y ago

I can give you a counterexample anecdote from my own career: I have spent my entire career writing code mainly in Common Lisp. I have a long list of successfully executed projects, some of which were done in the face of directly competing efforts written in other languages which failed spectacularly. I have a "profound belief" in Lisp, and I can justify that belief with a litany of empirical data and theoretical explanations. Nonetheless, every single time I have ever expressed that belief it has led to my career advancement being cut off and ultimately to the loss of my position and having to start over. So no, it's not enough to have "profound beliefs". You have to have the right kind of profound beliefs (unless you are extremely lucky -- see below). They have to not conflict too much with the profound beliefs of your management and co-workers because if they do you're sunk no matter how much data you have to back them up. That just turns out to be how the world works. I learned this lesson the hard way, and far too late in life for it to do me much good, but I thought I'd pass it along. There is one exception to this rule, and that is if you just happen to get have iconoclastic beliefs that are also correct and you somehow manage to acquire the resources to act on those beliefs and the results you produce happen to find a large market. Steve Jobs is the poster child for this, and even he is a cautionary tale because his career very nearly ended when he was first fired from Apple. It was only the good fortune of Apple management being utterly incompetent that gave him a second chance, which he seized on to spectacularly good effect. But Jobs was literally one in a billion.

psyklic 3y ago
I think Steve is approaching this from much more of a business angle. Looking at the Business Model Template slide in the article, programming language choice may not affect the business model much, except perhaps in rare cases where the language/tech achieves a business moat. Founders can definitely hold random theories about the business market/strategy, as long as they are willing to invalidate them (profound beliefs that are loosely held).
- lisper 3y ago
  Lisp has a profound effect on the business model because it can give you a dramatic productivity boost (like an order of magnitude or more) but it makes staffing more difficult because there aren't many experienced Lisp programmers because very few organizations use it, which makes for a vicious cycle. But this is precisely the sort of situation that if enough people simply changed their minds that by itself could change the underlying reality. It's not just Lisp. There's a similar thing happening today with Rust, which is clearly superior to C from a technical point of view, but which very few people use simply because there are very few people using it. But Rust might be one of the rare exceptions where the technical superiority is enough to allow it to break this cycle.
  - mlyle 3y ago
    An order of magnitude "or more" is an extraordinary claim. The evidence just isn't there. > but which very few people use simply because there are very few people using it. Ecosystems matter: they're one of the ways you get productivity.
    - lisper 3y ago
      > An order of magnitude "or more" is an extraordinary claim. The evidence just isn't there. Let me clear: I am claiming that these kinds of productivity gains are possible, not that using Lisp will automatically give you a 10x improvement under all circumstances. And yes, I can give you concrete examples of demonstrable >10x productivity improvements which resulted in products succeeding where they otherwise would undoubtedly have failed. These are generally found in niche applications where there is a lot of domain knowledge that needs to be brought to bear. So you're not going to see big wins in, say, commodity consumer products, which is the reason that the wins don't get much press. But the evidence is definitely there if you look in the right places.
      - marginalia_nu 3y ago
        If it gives such a productivity boost, why aren't LISP shops outcompeting other languages?
jimbob45 3y ago
Steve for Objective C or just his design principles in general?
- lisper 3y ago
  Steve (Jobs, not Blank) was an unparalleled visionary. I give him credit for the Apple II [1], the Mac, Objective C, NeXTOS/OSX/MacOS, and the whole i-series from his second stint at Apple (iMac, iPod, iPhone, iPad). To call him an overachiever would be quite the understatement. He is truly in a class by himself. I can't offhand think of anyone else in his league. (Elon Muck comes closest, but I'd rate him a very distant second.) --- [1] Yes, I know Woz actually designed and built it, but Burrell Smith designed the original Mac, and neither of those things would have been possible without Jobs.
  - growingkittens 3y ago
    Steve Jobs was a visionary authoritarian with the resources, opportunities, and connections to make Apple happen. Visionary authoritarians are dangerous to glorify.
    - lisper 3y ago
      I didn't intend to glorify him, only to defend my claim that he was an extreme outlier.
      - growingkittens 3y ago
        Glorification doesn't have to be intentional. Steve Jobs left a trail of havoc in the lives of the people he used to build Apple. He did objectively bad things to achieve objectively good things, so to speak. The good result is tightly coupled to a bad technique. Omitting the bad technique is tantamount to glorification. The language in your posts is also very...enthusiastic? Speaking of hard workers, have you read about Niklas Luhmann?
        3y ago
wmf 3y ago
Steve Blank's lessons are mostly for founders and executives. Of course employees don't get to just choose different beliefs than management! Management sets the direction and you either agree, disagree and commit, or disagree and quit.
- SoftTalker 3y ago
  Yes, but I'd extend that to really anyone who is responsible for making decisions about something. If it's your job to chose the development tools, you should have some profound beliefs about that. If it's your job to use the chosen tools to implement things, you really don't need to have any profound beliefs about the tools, and though it is helpful to understand the beliefs/motivations of those who are making the decisions, having your own (especially if contrary) is a recipe for "how to be frustrated at work."
- neotrope 3y ago
  It applies to anyone in a leadership position. Staff/principle engineers fit that role. Though you're right, the parent comment suggests they're not in leadership.
- Ancapistani 3y ago
  > Management sets the direction and you either agree, disagree and commit, or disagree and quit. In my experience, you missed the most common alternative: disagree and undermine.
  - don_neufeld 3y ago
    Yup, that’s the one that gets you fired.
- CMCDragonkai 3y ago
  If you are hired to follow, then you are supposed to follow. You can give advice and suggestions but you have to fall in line when an executive decision is made. That's how a team works, otherwise you aren't doing your job. If you're hired to lead. Then you need to make decisions and you're responsible for the success and failure of those decisions. You should have profound beliefs about why you make your decisions but also be able to take advice and suggestions, but at the end of the day, the success or failure is on your responsibility, not the advice givers - thus you always have the right to not act on others advice and suggestions. It's important to know what your role is in any organisation. I actually like this 1995 movie Crimson Tide that illustrates these principles while exploring moral ambiguities and procedural issues while under huge amount of stress where the lives of not only men in the sub is at stake, but the lives of whole nations when it comes to making decisions and when it is a good time to challenge those decisions.
heresie-dabord 3y ago
> You have to have the right kind of profound beliefs We need not to be enormously blind to the existence of an entire transactional structure around us. One that antedated our arrival and will likely still be there to offer a sentiments card and flowers upon our departure.
jjtheblunt 3y ago
> It was only the good fortune of Apple management being utterly incompetent that gave him a second chance Not only: before that second chance, he set up its sensibility, as he had the willingness to test the idea that there was a growing market for widespread unix 'workstations'. his hardware was too expensive for a huge hobbyist audience, which I know as I had one, but NeXTstep and its tooling and resulting apps placed a solid foothold in a somewhat grotesque early 90s (from 1988 or so to even get that foothold). I had one, had been using Suns before, and very early microsoft before that, and apple ][ and atari 800. I think his getting fired is something his brazen young self sublimed into a determination to prove an idea's viability such that an evolution of his NeXTstep effort not only brought him back to a hardware company better able to execute on the hardware portion, but such that his post-firing gamble is evolved into things ubiquitous now.
paulcole 3y ago
> Steve Jobs is the poster child for this, and even he is a cautionary tale because his career very nearly ended when he was first fired from Apple A very bright and persuasive person being fired at age 30 isn’t even in the ballpark of “career very nearly ended.”
YZF 3y ago
How do you define a well executed project? I can think of some criteria that might be relevant: - Are the projects still supported? How easy is it to find/hire people to maintain them? Is it easy to add new features? What is the quality like? - Are they small/stand-alone or have they evolved into large systems with large teams working on them and many new features? - How would you characterize their performance and scalability? Can they expand to run larger workloads? Do they make good use of the underlying hardware? - Is there a good ecosystem, libraries, packages, drivers, etc. for the domain you're targeting? I don't think you necessarily need to avoid conflict completely but you need to decide what hill you are willing to die on. If your co-workers, team, management, disagree with you then you can either try to convince them or you need to find consensus somehow. They could be right and you could be wrong. I can think of many examples where a single person introduced new technologies or languages or methodologies to an organization (including myself) ... Most good organizations welcome this sort of contribution. Ofcourse big decisions require compelling arguments. I've also had what I think were really good/compelling proposals for change end up being rejected, that's tough, but life goes on. EDIT: This is mostly unrelated to the article but I think the principles in the article do apply more broadly. Having a belief is good, it is what helps us drive in the right direction, but we should constantly be open to new information that challenges our belief and adjust it if needed. The initial "belief" also has context, it's given some circumstances, what do we think is the right approach. Then as we move on and circumstances change, and we get more data, we adjust our belief. This is different than what I'd call religion. Religion never changes, pretty much by definition it can not change. You're not going to start working on Shabbat if you're Jewish, regardless of what new information comes up or the situation. If you have no belief however you're at the other extreme, you're doing random things without any strategy or plan for the future (which is sort of where the author was when he was scolded by his CEO in the story).
ren_engineer 3y ago
if your belief is that strong you should found your own company and build your software with Lisp and beat competitors by being able to launch features faster and with fewer engineers. Ruby got popular for a while because several successful startups used it, Python for similar reasons
- lisper 3y ago
  Yep. I tried that. Turns out that not getting a product out the door is not the only way a company can fail.
iseletsk 3y ago
Re-read the article, it is truly great. It is not about "profound beliefs", but about "profound beliefs, loosely held". It is not about sticking with your believes, but about validating them, and changing them based on data. Now, talking as a technical CEO of midsize company, who coded in Lisp, and still codes: You are missing following pieces of data to justify your belief that List would be a good language for any projects for most companies: 1. Long list of successful companies with large Lisp codebases (are there examples of successful projects/companies based on such codebases) 2. Long list of examples of long term successful projects written in Lisp (how maintainable the code base will be if written in such language) 3. Long list of job positions for Lisp developers (ability to find more talent to expand the project when needed) 4. List of people in the company who can join the project (bus factor) Management does care about how long it takes to write the code. Yet, it is only one of many aspects. So, while your beliefs might be profound, they are ... short sighted.
- lisper 3y ago
  > your belief that List would be a good language for any projects for most companies That's a straw man. I have never made that claim. I think Lisp could be effective in a lot more areas than those in which it is currently deployed, but I have never said that it would be good for "any" project or "most" companies. What I said was that 1) in the past I have advocated for my "profound belief" that Lisp would be effective for particular projects on which I happened to be working, 2) in those circumstances in which I was able to persuade the decision-makers to actually use it, it worked spectacularly well and 3) despite 1 and 2, the net result was a net negative impact on my career. This is not sour grapes, just a cautionary tale. Holding and advocating for profound beliefs is not always a good idea.

CyberDildonics 3y ago

I really wish vague no context titles like this wouldn't be allowed. I don't know who votes for two words with no other information, but it seems silly.

deleted 3y ago
[deleted]
pvg 3y ago
People click and read the thing and upvote it if they like it. https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=by%3Adang%20work%20a%20little&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
- CyberDildonics 3y ago
  Why have titles at all if they aren't supposed to have any information in them?
  - pvg 3y ago
    Obviously, they have information in them, perhaps not information that's to your taste. "Why are titles that are not to my taste allowed" is at least a question that's relatively simple to figure out.
  - sixstringtheory 3y ago
    First you complain that the title doesn’t have enough information–more information please! Then you imply there should be no titles at all–less information please! Do you see the impossible double standard?
    - pvg 3y ago
      They're saying 'what's the point of titles if they don't tell me what's inside the tin.' There's no double standard there at all. It's an impossible one (unless promoted to Mystic Master of All Titles in The Universe or At Least on HN) but there's nothing double about it.

gumby 3y ago

> "I was executing a lot of ... “things” but why was I doing them?" This is a general problem, not just a marketing one: people who mistake frenzy for action and action for progress.

neotrope 3y ago

Love this article. 1. Developing beliefs and acting on them is a key part of leadership. 2. Without it, you limit career advancement. 3. It's a skill that can be learned.

wwarner 3y ago

I really like Blank's idea of a profound belief -- a vision of the future tempered with constant checks against evidence. With that picture, the word "bet" in the business context makes a lot more sense to me. Companies operate in the present, but they spend for tomorrow, laying track for where the company will be in the future.

j7ake 3y ago

Nice article, can be applied to the scientific enterprise. A scientist should have a strong enough about a paradigm so they can work with it, but loosely held enough to see the cracks in the theory and find the right problem that will change the field.