Board

The reason that Rails and Django have been so broadly adopted isn’t because it made writing web apps so much easier for people who were already writing them, it’s because they opened the door for so many new people to add writing web apps to their arsenal of skills. Users are attracted to frameworks that enable a wide swath of new technology at once. This is how frameworks gain wide adoption.

While the Architect framework and the Begin applications themselves are written in a modular, extendable way that will make adopting other clouds an option in the future, the fact remains that as of 2018, only AWS has the combined capabilities necessary to currently deploy performance intensive complex serverless applications.

If I had to guess why Rails and Django got so popular, and what made it possible for these kinds of frameworks to enable so many people to make applications that they weren’t making before, I’d say that it’s because of all of the decisions they don’t force you to make.

This became known as being “opinionated” back in the early days of Rails, which has philosophical roots in Martin Fowler and co’s Patterns of Enterprise Application Architecture book.

While the opportunity presented by serverless applications is huge, the complexity of writing, deploying, and scaling applications on AWS from scratch is unapproachable for beginners, and still far too complex for the tastes of seasoned veterans. Begin aims to help a generation of programmers bridge the gap to serverless applications.

In this view, Copilot is not automating you out of a job, it’s doing something much more demoralizing: it’s automating you into a job, a strange and scary new job made up of prompt engineering and model-stirring that doesn’t feel much like slinging code at all.

Hey, that’s automation for you. It Frees Us Up To Focus On More Important Things. We said the same thing about the cloud and about high-level programming languages and probably about abacuses.

My friend Ben, in his own takedown of the “End of Programming” article, suggests that they might be something like product managers, translating user needs and business requirements for an AI dev team. (You know, wordcel stuff!)

But programming - well, programming is a different story. We still have mechanical engineers, but they don’t employ roomfuls of draftspeople drawing straight lines anymore; they use AutoCAD. Is programming—or, if you like, “hacking” in the hackers and painters sense—headed the way of draftsmanship, an outdated craft replaced by AI assistance?

That profound satisfaction when the bug is dead and logic triumphs again. The pride of creation. The joy of self-expression in the medium you love.

Because here come the business bois cranking out AI-assisted apps by the thousands. Breaking that fundamental link between input and output: if you don’t like what the five-quintillion parameter model spit out, write another prompt and hope you held your tongue the right way this time. Of course it’s mediocre and buggy and unreliable, of course it’s worse than your handcrafted code. How could it not be? But it’s cheap. And it’s fast. So it’s winning.

People being willing to both dream the dream AND criticize the dreamers represent a much healthier ecosystem than unchecked dreamers or lazy pessimists.

The reality? Technological progress has been a net positive for the entire world. People often point to the idea that most businesses revolve around one of the 7 deadly sins. But social media didn't create pride, or envy, or even loneliness or wrath. The worst things about the internet, social media, and technology, are largely things based, not in technology itself, but in human nature.

To put the world in order, we must first put the nation in order; to put the nation in order, we must first put the family in order; to put the family in order; we must first cultivate our personal life; we must first set our hearts right.

Patrick Collison in 2023: "At Stripe, we want to be micro pessimists and macro optimists."

Believing that anything is changeable is, by nature, optimistic. Just like "the arc of the moral universe is long, but it bends toward justice," so too is the arc of human development long, but it bends towards progress.

The idea that pessimism always sounds smarter than optimism, and that it's so much easier to say no, than yes.

But I think the key takeaway for me came from another conversation with a friend of mine. In it, I found myself asking this question: "Would you rather build towards something you're proud of, even if you knew you wouldn't make a lot of money doing it? Or would you rather build towards something you may not be proud of, but you're sure to make a lot of money?" In my opinion, the world of building and investing in tech companies could use more folks who don't believe the ends justify the means

Juice is about the tiny details. It's about squeezing more out of everything. It's about serving the user's emotional needs, not just the functional. It originated in games but can be used in other types of software.

It's about maximum output for minimum input.”

For non-game software, using a lot of Juice could be a bad thing. Games often flood the user with Juice because the intented UX (User Experience) is immersion. For a non-game app, the intent may be to allow a task to be done quickly. A small amount of Juice may enhance the UX. A lot may make the task take longer, degrading it. Before juicing, understand the intended UX. Juice should make it better, not worse.

We play with toys, but we play games. A ball is a toy, but baseball is a game. The best games are made with toys.

To create software with soul, ask yourself how do you want the user to feel? Look outside the software industry for inspiration. Find what makes you feel, ask why & use that to shape your work. The greatest crafters in our world across art, design & media do this. They base their work on feelings, opinions, experience, taste, subjectivity & ideas. Nothing averaged out or neutral. Their works built by people for people. They contain hand-crafted touches. They feel like the world around them. I

Call of Duty is a first-person shooter video game. Involving complex mechanics that can be hard to learn. Introducing them upfront in an onboarding process could overwhelm the user. Instead, the developers use non-intrusive ways to teach. For example, every time you join a multiplayer game, the user see a loading screen for 10 - 20 seconds. The developers juice the screen by displaying a tip about how to play the game. Teaching the user gradually, at a manageable pace. The user can better absorb the information because it's at a time when cognitive load is low.

A final theory was that the players should always blame themselves for failure. If the game kills them off with no warning, then players blame the game & start to dislike it. But if the game hints that danger is imminent, show players a way out & they die anyway, then they'll consider it a failure on their part; they've let the game down & they need to try a little harder. When they succeed, & the game rewards them with a little treat — scripted sequence, special effect, & so on — they'll feel good about themselves & about the game.”

Perhaps one of the widget companies changes their ad copy, plays around with pricing a bit, and discovers that they can earn $2.50. As soon as they start routinely ranking #1, though, the other widget companies will look at what they're doing. And, if it's a commodity business, they'll all promptly copy it. So, not only do the structural profits of the business flow to the ad company, but so do improvements in the business.

It's also a way to shorten supply chains in terms of both distance and time, and since every supply chain operates at the pace of its slowest or least predictable component, that has many downstream effects.

I guess the simplest way to think about it would be a sort of “real-time in-IDE Stack Overflow” coupled with a really powerful new set of boilerplate automation tasks.

The punchline, and it’s honestly one of the hardest things to explain, so I’m going the faith-based route today, is that all the winners in the AI space will have data moats.

Nobody can differentiate on the LLM; they’re all about the same. And the IDE and your code base are the same. All they can try to differentiate on is their UI and workflows, which they’re all going to copy off each other. Good for you, bad for them.

You need a data moat to differentiate yourself in the LLM world. Why? Because the data moat is how you populate the context window (“cheat sheet”).

If you can’t feed the LLM your whole code base, and you can only show it 100k characters at a time, then you’d better be really goddamn good at fetching the right data to stuff into that 100k-char window. Because that’s the only way to affect the quality of the LLM’s output!

Other coding assistants, which do not have Sourcegraph for Step 2 (populating the context), are stuck using whatever context they can get from the IDE. But sadly for them, IDEs weren’t really designed with this use case in mind, and they make it difficult. And more damningly, no IDE scales up to industrial-sized code bases.

They will feel gloriously like cheating, just like when IDEs came out, back in the days of yore. And for a time-constrained developer like me–and I say this as someone who has written over a million lines of production code… Cheating is all you need.

I am always doing that which I can not do, in order that I may learn how to do it. —Vincent van Gogh

The converse of this is a business that has extra “and” clauses — even more than usual. Marketplaces, for example, almost never succeed. When they do succeed, they are often durable and profitable, which makes them a smart bet for a Venture Capitalist that can maintain a diversified portfolio of attempts, but for the individual business it’s a tough road. For example, a marketplace has to thrive both with the sellers and the buyers — if either one is disinterested, or is too expensive to corral, or doesn’t find value, or prefers to transact outside the marketplace, then the marketplace fails. Those are “ands!” Also, many marketplaces often only deliver value at scale; so another “and” is that they have to also “scale down” so the first 100 buyers and sellers also see value.

Even so, there will be plenty of challenges, so we need a second technique for boosting probability: Leverage “or” instead of “and.”

The general rule is optionality is strength.

By accumulating “and” requirements, you are lowering the probability of success. By stringing together possible solutions with “or,” you are increasing the number of ways that luck could smile upon you.