DEV Community: Ned Twigg

Incremental progress feels futile...

Ned Twigg — Wed, 22 May 2024 04:42:20 +0000

I spent a lot of my career building a git client - I was laser focused on enabling and accelerating incremental progress. But in the age of LLMs that approach feels inadequate. In this piece I tried to figure out why "business-as-usual" feels so broken right now, and also tried to work through my hangups getting fully on board with the new stuff.

https://dev.to/thecontextwindow/the-new-stuff-is-always-simple-5epk

The new stuff is always simple

Ned Twigg — Wed, 22 May 2024 04:40:12 +0000

A simple system may or may not work. A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

This assertion is known as Gall’s law. It implicitly defines “simple system” to mean “a system that may or may not work”. A good example of such a system is a biological cell that senses light. Can the cells on your fingernails detect light? Nope. Broken, doesn’t work. How about the cells at the back of your eyes? Yes! …hopefully. If they work at all, then we can stack complexity on top - sink the cells below a pinhole for angular resolution, make the pinhole diameter adjustable for dynamic range, cover the pinhole with a flexible membrane for near or far focus, wrap that in a cover for protection, put glass and polycarbonate over that for more protection and more focus.

Gall’s law implies that time operates only on complex systems. If you have a system that works, then you can apply some time to it, and if you ensure that it still works at every step along the way, then you have followed the only recipe that can produce a complex system that works. If it ever stops working, there’s no amount of time you can use to get it working again unless you revert back to the last working checkpoint.

But of course, time operates on simple systems too - because the complex systems that originate novel systems are evolving. A good example here is the Wright Flyer - people had tried to make flying machines far more complex than the Wrights’ for a long time, but they hadn’t had high-precision machine shops for very long, and no one had ever had a high-precision machine shop and a wind tunnel before.

And so, as we refine and accumulate the capacities of our existing complex systems, we find that the space of "simple” working systems - those that simply, magically work - is growing.

The problem with novel simple systems is that they almost never happen. All our heuristics are tuned for coevolving with other relatively ancient and complex systems that we have already adapted to. So we apply the classic heuristic “it’s like a stochas-” WRONG. STOP STOP STOP. NOTHING IS LIKE ANYTHING ELSE.

You have to take a novel system on its own terms, not in terms of some other thing. But Gall’s Law brings good news! If it’s novel and it works, it’s probably still simple! It hasn’t had enough time to become complex, so it’s not too late to draw it out on a single sheet of paper! For yourself — looking at a blogpost of someone else’s sheet of paper doesn’t count. Yours is the hand that must draw the boxes. What pieces does the system have? How are they connected?

Once you’ve stopped trying to pretend that the necessarily simple novel system isn’t actually simple enough for you to draw, you have a chance to see what it does. Again, on its own terms. Does it perform better or worse than - STOP! STOP STOP STOP! Don’t try to find out if it does better or worse. Just see what it does. If you contemplated the system well enough to draw it, then you already noticed some places where you wanted to poke it. Poke! Empty yourself of all concern for utility, soak yourself in the jiggles of the poke, and let the jiggles evaporate slowly enough for their residue to crystallize undeformed by your preconceptions.

In general, we developers get old and crusty. If you spend thirty years analogizing to what it was like when you were twenty, your world model seizes up. John Carmack was inventing new programming techniques before you were born, and he can still touch his elbows to his toes without bending his knees. I don’t know the exact cause of your rigor mortis or of his flexibility, but it’s notable how frequently he checks-in on even the simplest aspects of reality.

Oh but you’re too busy making cutting edge webpages to burn time on frivolities like weighing things with a postage scale? THAT IS WHY you ended up in the position of frantically updating derelict webpages. Because you don’t know what anything is! John Carmack keeps inventing the future because he keeps finding out what’s here in the present.

And more than ever, I think what’s going to be here in the present are brand new, simple systems. Thinkpieces and explainers keep trying to tell us what ChatGPT is like, while Andrej Karpathy is on YouTube begging us to just take a couple hours and literally make one. If you’re not gonna do that, at least let Nishant Aklecha show you the actual concrete steps that the LLM is taking.

The problem for our heuristics is that this wave of generative AI systems is so powerful, we assume it must also be complex. The most powerful web browser in the world is an evolution of the last browser. Chrome’s version number has passed a hundred because it has a lineage measured in decades, not years. Its power came from tackling complexity, and complex systems always have some antecedent we can analogize from.

A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

That law still holds, but the sweet aftertaste of the bitter lesson is that it has never been easier to start over and discover something simple that works. If you enjoyed obsessing over semantic versioning and git branching conventions, I hope you got that all out of your system. It’s true that a 10-year-old SaaS website that works is inevitably found to have evolved from a 9-year-old SaaS website that also worked. But pretty soon you might find that every category leader is inevitably found to be a novel arrangement of novel categories of intelligence. The good news is that they’ll be simple. The bad news is that the process which creates them is going to involve way more abject, unsalvageable failure than most “engineers” signed up for.

Working with junior programmers

Ned Twigg — Thu, 09 May 2024 22:45:25 +0000

I just had an opportunity to work with some junior programmers for the first time in a while. One of the things I noticed was that they often wrote code that they did not want to run, but they thought they had to write to get some warning to be quiet.

It's so obviously silly to write code that you don't want to run, and yet it still happens. A lot! So I wrote a fun little piece about it. Here's an excerpt:

And all of the good programming languages... have at least one construct entirely devoted to “if the bad thing happens, then what?” In the best languages, you say “I will tie my shoelace”, and the language says “But what if you scrape your forehead?” And nothing else can happen until you have an answer.

“I won’t scrape my forehead while I -” UNNNNNHANDLED CASE ScrapeForeheadException WHAT IF YOU SCRAPE YOUR FOREHEAD ON LllllLLLine TWELVE THIRTY THIRTY TWO then what? …

One option is to run away to live with Python, who lets you drink Coke for breakfast and shit in the refrigerator. But it would be better to be a goodie two shoes and say “dear mommy I will get a bandaid from the cupboard and put on neosporin”. That might work, or maybe she’ll hit you with a nested DrankTheNeosporinException but then you can say “dear mommy I’ll call poison control” and eventually she’ll be satisfied and your shoes will be tied.

As you age and better grasp the desperate scarcity of time, you will correctly say “I don’t have time for this”...

The whole thing is on my new Substack at https://thecontextwindow.ai, but I'll be crossposting to a mirror account here on dev.to.

Never write code you don't want to run, part 1

Ned Twigg — Thu, 09 May 2024 22:29:28 +0000

When I was a kid, I wanted to go FAST. And my mom, she didn’t care about fast, she only cared about SAFE. And it sucked, and anytime she’s not around I go FAST, and I have a modest basket of broken bones that wouldn’t be so crooked if she could have had any say, but eventually she didn’t have any say and it was worth it. Fast is worth it.

And all of the good programming languages are like my mom. They have at least one construct entirely devoted to “if the bad thing happens, then what?” In the best languages, you say “I will tie my shoelace”, and the language says “But what if you scrape your forehead?” And nothing else can happen until you have an answer.

“I won’t scrape my forehead while I -” UNNNNNHANDLED CASE ScrapeForeheadException WHAT IF YOU SCRAPE YOUR FOREHEAD ON LllllLLLine TWELVE THIRTY THIRTY TWO then what? …

One option is to run away to live with Python, who lets you drink Coke for breakfast and shit in the refrigerator.1 But it would be better to be a goodie two shoes and say “dear mommy I will get a bandaid from the cupboard and put on neosporin”. That might work, or maybe she’ll hit you with a nested DrankTheNeosporinException but then you can say “dear mommy I’ll call poison control” and eventually she’ll be satisfied and your shoes will be tied.2

As you age and better grasp the desperate scarcity of time, you will correctly say “I don’t have time for this” and incorrectly you’ll say “just do nothing”. The thing she’s worried about? It won’t happen. So if it does happen, do nothing. (because it won’t happen)

Fast is worth it. But you would be better off proudly eating your boogers at Python’s house than to “do nothing” if you scrape your forehead. Because while your mom may or may not respect you, your computer absolutely does. If you say “do nothing”, then nothing will be done. Shoelace by shoelace, your foreskull will be ground flat like the lucky red crayon that never got lost, and as you commanded, nothing will be done.

If you scrape your forehead while tying your shoes, you should scream. You should panic, and you should thank the wise mommy who gave you a chance to do so.

Names in java, maven, and gradle

Ned Twigg — Thu, 23 Jan 2020 22:11:25 +0000

A central aspect of Java's philosophy is that names matter.

Brian Goetz, Java Language Architect and author of Java Concurrency in Practice

Packages

If you work for "acme.com" and you're working on a project called "foo" then the convention is for your root package to be com.acme.foo.

Being a forward-looking bunch, we tend to add lots of "grouping" packages. Our foo project is a utility library, and we might make other ones, so we put it into com.acme.util.foo, to make sure there is space for other utility projects. If we're really forward-looking, we'll take into account that foo is a utility library for manipulating text, so we better put it into com.acme.util.text.foo. On the other hand, YAGNI.

In the javascript world, there are no packages, you just get one name - foo - and that's it. I'm glad that I do most of my work on the JVM rather than a runtime which was designed and built in 10 days, but whenever I start nesting my root package deeper than com.acme.foo, I try to remember that all those gobs of software being written in Node.js are getting by without any nesting at all, so maybe I can get by with 3 or 4 levels of nesting for my root package, rather than 5 or 6.

Maven groupId:artifactId

One nice thing about .class files is that you don't have to pick names for them - they get their name automatically from a 1:1 mapping on the .java file they came from. Unfortunately, maven asks you to pick two names, so it can't be that simple. Luckily, maven also provides not only one, but two slightly different conventions for how to pick these names! Accordingly, if you ask StackOverflow, you'll see two popular answers. And when a major library like RxJava ships a new version, you'll need a 12-screen-long debate to figure out what the names ought to be.

Luckily, there is a mechanistic answer out there! JitPack turns any git commit into a maven artifact at https://jitpack.io , which I've found to be huge improvement over -SNAPSHOT for integration testing. The naming convention that it uses is:

com.github.{user}:{repo} (also com.gitlab, org.bitbucket, and com.gitee)
com.github.{user}.{repo}:{subproject} for multi-module builds.

If you use JitPack's custom domain integration, then you can replace com.github.{user} with com.acme for a professional touch. Even if you don't use JitPack, using this convention will mean that you could, and it lays down a simple rule that works well enough for all these people.

Gradle plugin id

In Gradle-land, you can apply a plugin like this: plugins { id 'any.plugin.id.you.want' }. Gradle provides an excellent guideline:

As a convention, we recommend you use an ID based on the reverse-domain pattern used for Java packages, for example org.example.greeting.

The trouble is, a huge number of the plugins which have been published so far are named... gradle-plugin. It seems reasonable while you're writing the plugin, and you don't realize how silly it is until you use it from a distance:

plugins {
    id 'com.acme.gradle.foo'
    id 'org.nonprofit.bar.bar-gradle-plugin'
    id 'beetlejuice.beetlejuice.gradle'
}

What kind of car is that? That's the Chevy Corvette Car. What kind of phone is that? It's an iPhone XS Phone. Wouldn't this be better?

plugins {
    id 'com.acme.foo'
    id 'org.nonprofit.bar'
    id 'beetlejuice'
}

It's interesting, because the guidelines that Gradle gives are very good - no excessive nesting, no unnecessary gradle.gradle, just the bare minimum. And yet, a lot of the people who use it feel like they should add a gradle or two, just in case. Probably the only way to save us from ourselves would be for the gradle tooling to search for gradle in the id and throw a warning, to help us think about it a little before we publish.

Lessons

Designing namespaces is a rare opportunity. Most of us never do it even once in our entire career. And since nobody has experience in it, we're still making lots of beginner mistakes, even in the quarter-century-old world of java. It's hard! Typosquatting, IDN homograph attacks, there are so many pitfalls. If I ever end up defining a namespace, I'm gonna try to remember these lessons:

namespaces are helpful for identifying the author/maintainer: com.acme.foo 👍
namespaces are overkill for fine-grained categories: com.acme.util.text.foo 👎
defining the name to be a tuple of two other names is 👎
if the names are all plugins to foobar, people are just gonna name them my-foobar-plugin, and it might be good to warn them that it's probably not the best choice ¯\_(ツ)_/¯