This post has been generated by ChatGPT from an outline as part of an ongoing experiment. Outline is at the bottom. For this article i was not impressed with the first go so i has ChatGPT regenerate a single time.

"Move fast and break things" is a phrase that has gained a lot of notoriety in the software industry. While there is pretty universal disdain for this attitude, it's hard to argue with the results it has produced. Companies like Uber, Twitter, MongoDB, and Twilio have all had success with what might be considered shoddy practices, and it's worth asking ourselves why this approach succeeds, even when everyone agrees it is a bad idea.

One possible theory is that sometimes, being fast is more important than being right. There are a number of factors that can contribute to this, such as network effects, the need to enter a "blue ocean" market, a low cost of failure, and a low level of technical complexity. For example, while MongoDB might not have been the most technically sophisticated database out there, it was able to achieve success because it was able to move quickly and take advantage of these other factors.

Another theory is that sometimes, breaking things is the fastest way to do good work. This is especially true in situations where the path forward is unclear. For example, in 2007, it was not clear how to build a successful social network. By moving quickly and breaking things, Facebook was able to gather feedback and iterate on its product, eventually arriving at a successful formula. Similarly, building good infrastructure in 2007 required a high level of technical expertise, and it might not have been clear to a ragtag crew of college dropouts how to do it. By moving quickly and breaking things, however, these companies were able to learn and grow, eventually becoming some of the most successful in the world.

It's worth noting that most of the companies that have had success with this "break things" approach have eventually gone back and fixed the things they broke. And it's also worth noting that there are plenty of examples of companies that have had success without breaking things, so it's not a prerequisite for success. Google, Netflix, and Apple are just a few examples of companies that have been able to achieve great things without

Original outline:

- I guess at this point you might need to introduce the quote
- Pretty universal disdain for this attitude in software circles
- Whether you like it or not you can't argue with the result
    - A less clickbaity introduction to this blog would be try and illuminate the "move fast" vs "engineering rigor" tradeoff
- Plenty of other companies have had success with shoddy practices
    - Uber
    - Twitter
    - MongoDB
    - Twilio
    - Probably like half the gaming industry
- Why does this approach succeed, when everyone agrees it is a bad idea?
- Theory: Sometimes being fast is more important than being right
    - Network effects
    - Blue ocean
    - Low cost of failure
    - Low technical complexity (MongoDB says no, although for a database it was fairly simple and fairly broken)
- Theory: Sometimes breaking things is the fastest way to do good work
    - Pretty clear how to build a social network today, was not clear in 2007
        - Could sit around and think about it or deploy some code and get feedback
    - Pretty clear how to do good infrastructure today, was less clear in 2007
        - Required significant technical chops to build it. What do you do if you don't have it? Could spend 5 years learning how to create great infrastructure or you can just move fast and break things
    - Points is: Facebook could probably have been built better and faster by the worlds best engineers. Not so sure it could be built better by a ragtag crew of college dropouts.
        - Not a dig at the people who built facebook, its the opposite. I am pretty sure they found the only way those exact people could succeed as spectacularly as they did. Everyone starts out unexperienced. If you are unexperienced maybe you could learn something from them.
            - note: Dont start producing shitty work at your job. This is the situation where there noone around to ask for advide, what do you do? You ship code and learn.
- Comforting points
    - Most succesful breakers have fixed things after they got success
    - Lots of examples of companies that has success without breaking things -> Breaking things is not a prerequisite for success (but it might be for some people)
        - Google
        - Netflix
        - Apple