Number one:
Do things in the most straightforward way possible. It’s easy to fall into the trap of clever solutions, or clever applications of technology, or overbuilding something because you’re anticipating the future. Don’t do it. You will hate yourself for it later when you have to maintain it.
Here’s a nifty demo of popover but it’s not for what we’d traditionally consider a modal dialog.
The paradigm shift that web development is entering hinges on the fact that while React was a key enabler of the Single-Page-App and Component era of the web, in practice it normally tends to result in extremely poor products. Built-in browser APIs are now much more capable than they were when React was first invented.
People act like writing code is the hard part of software. It is not. It never has been, it never will be. Writing code is the easiest part of software engineering, and it’s getting easier by the day. The hard parts are what you do with that code—operating it, understanding it, extending it, and governing it over its entire lifecycle.
The present wave of generative AI tools has done a lot to help us generate lots of code, very fast. The easy parts are becoming even easier, at a truly remarkable pace. But it has not done a thing to aid in the work of managing, understanding, or operating that code. If anything, it has only made the hard jobs harder.
A very thought-provoking presentation from Maggie on how software development might be democratised.
There’s a big difference between the interface to a thing being one line of code, and the cost of a thing being one line of code.
A more acute rendering of this sales pitch is probaly: “It’s just one line of code to add many more lines of code.”
And as Chris puts it:
Every dependency is a potential vulnerability
We’re all tired of: write some code, come back to it in six months, try to make it do more, and find the whole project is broken until you upgrade everything.
Progressive enhancement allows you to do the opposite: write some code, come back to it in six months, and it’s doing more than the day you wrote it!
When I was in Amsterdam I was really impressed with the code that Rose was writing and I encouraged her to share it. Here it is: drop this script into a web page with a form to have its values automatically saved into local storage (and automatically loaded into the form if something goes wrong before the form is submitted).
I’ve always maintained that prototyping and production require different mindsets. Trys suggests it’s not as simple as that.
I agree with much of what he says about back-end decisions (make it manual ‘till it hurts—avoid premature optimisation), but as soon as you’re delivering HTML, CSS, and JavaScript to real people, I think you need to meet certain standards when it comes to accessibility, performance, etc.
Products of all kinds are required to ensure misuse is discouraged, at a minimum, if not difficult or impossible. I don’t see why LLMs should be any different.
I often wonder if the future of my job is just cleaning up all the robo-barf on the ship.
Dave ponders the pros and cons of large language models.
Eliminating tedious work seems worthwhile. Humans getting to do more of the fun stuff. That famous “augmented work” everyone talks about.
But what is considered tedious? Email? Writing documentation? Blogging? Design? Making music? Hiring? Working with junior developers? How come management never comes up in these conversations?
What strikes me about my personal experience with LLMs is that I have learned precisely when to use them and when their use would only slow me down. I have also learned that LLMs are a bit like Wikipedia and all the video courses scattered on YouTube: they help those with the will, ability, and discipline, but they are of marginal benefit to those who have fallen behind. I fear that at least initially, they will only benefit those who already have an advantage.
I love the analogies Matt uses to describe the vibes of different kinds of coding:
When I’m deep in multiple nested parentheses in a C-like language, even Python, I feel precarious, like I’m walking a high wire or balancing things in my hands and picking my way down steep stairs.
I haven’t done much Haskell but what I did felt like crawling underground through caves and tunnels.
Opening a terminal window to a distant server is like reaching through a hatch with my arm, but a long way; ssh tunnel is well named.
Writing code with GitHub Copilot and Typescript in full flight feels like, well, flying, or at least great bounding leaps like being on the Moon.
Such a clever minimalist use of CSS!
The hard part of programming is building and maintaining a useful mental model of a complex system. The easy part is writing code. They’re positioning this tool as a universal solution, but it’s only capable of doing the easy part. And even then, it’s not able to do that part reliably. Human engineers will still have to evaluate and review the code that an AI writes. But they’ll now have to do it without the benefit of having anyone who understands it. No one can explain it. No one can explain what they were thinking when they wrote it. No one can explain what they expect it to do. Every choice made in writing software is a choice not to do things in a different way. And there will be no one who can explain why they made this choice, and not those others. In part because it wasn’t even a decision that was made. It was a probability that was realized.
This post also has a really good explanation of how large language models work.
There may be real, productive uses for these kinds of tools. There may be ways to build and deploy them ethically and sustainably. But that’s not the situation with the instances we have. AI, as it’s been built today, is a tool to sell out our collective futures in order to enrich already wealthy people. They like to frame it as being akin to nuclear science. But we should really see it as being more like fossil fuels.
GPT-4 is impressive, but a layperson can’t wield it the way a programmer can. I still feel secure in my profession. In fact, I feel somewhat more secure than before. As software gets easier to make, it’ll proliferate; programmers will be tasked with its design, its configuration, and its maintenance. And though I’ve always found the fiddly parts of programming the most calming, and the most essential, I’m not especially good at them. I’ve failed many classic coding interview tests of the kind you find at Big Tech companies. The thing I’m relatively good at is knowing what’s worth building, what users like, how to communicate both technically and humanely. A friend of mine has called this A.I. moment “the revenge of the so-so programmer.” As coding per se begins to matter less, maybe softer skills will shine.
On the one hand I still really enjoy writing code and making something work and look good (ish) and put it online where anyone in the world can see it. It’s still like magic. And is still some kind of personal affirmation, a way of saying “here I am!”, of enjoying that it’s noticed by someone, somewhere.
True.
On the other hand, the maintenance. It’s not like this is new to me, keeping things going for years, decades. And I try to make things as easy as possible – keep things up to date, make things in similar ways, stick to reliable and boring technologies, don’t start too many things, etc. But, especially when several things aren’t quite working right, it’s such a weight.
Also true.
It looks like it will be a great tool for prototyping. A tool to help developers that don’t have experience with CSS and layout to have a starting point. As someone who spent some time building smoke and mirrors prototypes for UX research, I welcome tools like this.
What concerns me is the assertion that this is production-grade code when it simply is not.
Another great talk from Simon that explains large language models in a hype-free way.
Time capsules on the moon, using NanoFiche as the storage medium.