With that said it's a challenge and a chore on its own to curate what "AI" writes. So it's definitely not all roses.

Disclaimer: I'm still early in the experimentation phase. We'll see if i hold these opinions in a few months.

I needed to get an invoice out in a timely fashion. As much as I wanted to use my app, I found certain kinks I needed to work out (with styling, adding addresses, etc.) -- This was where I realized what you have articulated.

At some point, it becomes better to prioritize the "fun" in working on my bike, and the "usefulness" of the daily driver bike.

In doing so, perhaps the fun/usefulness of each converges over time.

Actually, I really like this analogy because

1) We can’t really work on non-trivial fixes for our cars because they are too complex

2) We’ve totally structured our living situations around these over-complex beasts

3) Sometimes they do just break down at random, and it becomes a mini-crisis for everyone involved, which can’t really be resolved without missing a day of work to go to a professional

4) The bike is in exactly the same situation, except you can actually fix most bike problems yourself with a little kit

And yet, it is seen as a serious adult thing to have a car, instead of a bicycle.

Some thoughts:

Outside of, like, customer service, most places are throughput-oriented and it doesn’t even really matter all that much if somebody misses a day.

If we really cared about “uptime” of employees, we’d all be living in bicycle range of our jobs, and able to fix our bikes. Maybe there’d be a bus route as well.

How about working on your bike that other people also work on daily? That's work.

I don’t like this either but every time I use LLMs it feels like we’re talking about completely different things. It moves waaay to fast and makes bad decisions at every turn, if I accepted them all it would be complexity deadlock within a week tops. Pooping out boilerplate sure but then you’re generally holding it wrong anyway (or there’s an opportunity to automate things). Plus even if you don’t have the time to automate it, sure, but then are you enjoying the act of shitting out your own boilerplate?

Out of the things I consider fun the LLM is at best a good rubber duck. It needs constant hand-holding, sometimes polluting the context window (and physical space) with a barrage of poorly written code. Code is bad, we’re trying to minimize it. No? At least that’s how I think: what’s the minimum* amount of code that can solve this problem?

*: minimum in a brain complexity sense, not char count. They correlate strongly though

I am primarily a backend engineer, though I am capable on the front end, just not particularly fast. I am especially slow at the voodoo that is CSS. In the past, I would have been turned off from doing some end-to-end personal projects because I know I would have been bogged down just battling CSS for hours and hours (it's particularly problematic that I'm slow at CSS but also a stickler for how I want things to look). With AI tools I can literally just say "make it pretty". It gets me about 85% of the way there, but importantly it gets me to the point where it puts in all the styling framework and then I just have to fix bugs/edit/tweak it, which goes very quickly.

So now I've found myself much more likely to build personal projects because I know I can get past things that in the past felt a bit like quicksand to me.

Deployment was... run update scripts, push ASP files via FTP.

Now I know there are newer ways to do things, and I'd love to set up CI/CD in my personal life, but every time I want to do a "toy project" I get hung up researching and thinking about my own personal software development life cycle.

What you choose for hosting and deployment for your toy projects?

I would love the opportunity to take ~6 months off, but I feel scared that if I just quit, it might take me a longer time to find a job again.

Bad onboarding docs, broken or bent SDLC, major performance issues. I spent all day yesterday fixing perf issues in a library that competes with one I loathe for trying to complect an entire problem domain.

You probably have the same thing I do. Teamwork is a very different motivation than working on something either never intended for others or with a long MVP cycle that makes it too easy to get bogged down with side quests. "It would be way less tedious to deal with X if I did Y first. But now Y is blocked so I do nothing."

Versus 'someone is waiting for this.'

http://mikehadlow.blogspot.com/2012/05/configuration-complex...

It took me a solid decade to accept these lessons. I cannot build a product that even remotely competes with things like Visual Studio and .NET tooling. How many hours would it take a solo developer to recreate a debugger experience that anyone else could be bothered to look at for more than 5 seconds?

The hardest part of building something configurable is the UI/UX. The moment you step outside of the host language, your tooling support goes to zero. Sure, you can pick other popular languages as the language of configuration (SQL, python, Lua, etc.) and piggyback off those ecosystems. But, you still have to build a way for a "non programmer" to visit all of the patchwork sites of "configuration" in a coherent way. Telling the business people to go edit a folder full of .py and .sql files will probably not be received well. Wrapping all of this with a fancy web interface doesn't make the problem less severe either (it makes it substantially worse).

If you have a way to build/deploy your product in <60 seconds from source, worrying about elaborate configuration and customization architecture seems extremely idiotic to me now. The best path I've found is something approximating a common library and a per-customer executable that consumes it and implements the expected contracts. Each customer's project lives in a subfolder on the same monorepo. The power of the hierarchical filesystem is tragically understated throughout our industry.

I had a shift of perspective at some point where I realized that software wasn't just fun to create, but you can solve problems with it, including your own, which is incredibly rewarding and kinda feels like wizardry.

Ultimately I find both to be enjoyable, though in terms of career and life outcomes, focusing on solving real problems and producing tangible outcomes has had more of an impact than noodling with neat implementations that nobody but me cared about.

Turns out if you solve your own problems (or just publicly work toward solving them), there are often other people who also struggle with the sam problems, who may throw money your way ;-)

Any inspection of any economy suggests otherwise. How many tire manufacturers are out there? How many different brands, styles, and types of tire? How many total US Dollars per year are those companies sharing?

How about oil changes? Car washes? How about car wax?

New doesn't equal profitable. Making a different product, or service, is where most of the profits on earth sit.

Wanna be a rebel and broke? Then by all means follow the new-new and barely break-break even.

Can I ask what you had running on that cluster?

If you're interested in writing Raft-backed databases you might be interested in my talk at GopherCon 2023. It walks through doing exactly that, step by step: https://www.youtube.com/watch?v=8XbxQ1Epi5w

[1] https://rqlite.io

AI is not an expert programmer [today]. and it doesnt take an expert programmer to arrive at that conclusion.

It feels like Claude and ChatGPT have both become more sycophantic over the past months.

The number one question I have as a hiring manager is always "can this person actually write code". A GitHub profile with 2-3 projects with multiple commits to each one answers that question really well. I won't filter out people who don't have that - lots of great engineers have never published code before - but the people who do have that are much more likely to get picked for the phone screen.

Examples: https://github.com/bbkane

1. Because half her friends and family are on iOS, and that means fighting the App Store. (This is a social problem essentially, in fighting Apple)

2. Because networking is hard. How would you have shared recipes with a computer in the C64 days? Email? BBS? (There are partial technical solutions to this, but they would require people to run something like friend-to-friend overlay networks)

3. Because most stuff happens in web browsers and that means pay-to-play, or vendor lock-in, or using AWS free tier and being a programmer. (Ass, grass, or cash, nobody hosts for free. Friend-to-friend networks may also help with this)

4. Because a recipe manager with sharing is best implemented as just emailing your recipes to your friends and storing them as txt files locally. Anything more complicated is beyond the scope of a Visual Basic-style drag-and-drop WYSIWYG anyway

5. When was drag-and-drop enough? The widgets need code behind them to save and open files, right?

6. You might be kinda onto something, and the longer I write async code I more I think the programming world is ready for another big pruning. Like when structured programming said "No goto, no long jumps, if-else and exceptions is all you need", we might be ready for "A single control thread which never blocks and never awaits, and delegates to worker tasks, is all you need until you are building some C100k shit"

Because there's no money in it.

In the age of powerful computers, you can use Hypercard on an emulated Mac, you can use any number of hypercard-clones out there. She can just use Google slides. etc.

I even made a few (quite simple, from my today's perspective) games in Pascal during high school and university. I expected to become much more productive over years of practice.

That didn't happen, for several reasons.

First, my expectations for a good game have increased. I don't want to make the most complicated game possible; I am perfectly okay with 2D raster graphics and simple algorithms. But I expect a good game to have animations, sound effects, at least ten levels that feel different, and an option to save game progress. My old games barely had half of that (some were animated, some had ten or more levels, only one had both of that).

Second, things became more complicated. It is no longer "320 x 200 pixels, 256 colors". Windows are resizable; different screens have different sizes. Programs need to be aware that multiple threads exist. Sometimes there are many possible choices, and I get paralyzed by choosing between them. Programs are expect to have installers; it is no longer enough to have one EXE file, and optionally a few data files together in a ZIP file. It felt like every time I mastered something, a new problem appeared to be solved.

Third, as a teenager I didn't realize how much my everyday work would differ from the kind of work necessary to make a computer game. Some skills are transferable: I am more comfortable with using threads, parsing data files, writing algorithms, the program architecture in general. But many skills are not: if my dream is to make a desktop application, then e.g. all the web frameworks that I have learned over those years are useless for this purpose; and they have cost me a lot of time and effort. So from the perspective of making computer games, as an adult I maybe learn in five years as many relevant things as I have learned as a teenager in one year, when I had lots of free time that I could dedicate to this goal.

Fourth, life gets in the way. There is much less free time, and much more things that I need or want to do during that free time.

So here I am, after a few decades of IT jobs, and (a) I can't really make a complete computer game over a weekend, and (b) it's irrelevant, because until my kids grow up I probably won't get a free weekend anyway. Or rather, even the rare "free" weekend (when the kids are away) is spent on other things that have higher priority.

In near future, companies will probably be able to pay lots of money to have their products come up better in the comparison. LLMs are smart enough to make the result seem "organic" -- all verifiable information will be true and supported by references, it will only be about proper framing and emphasis, etc.

It pulls in info from the docs, forums, code samples, shows me how things are connected, and may even suggest why something is good or bad.

Plenty of opportunity to look up docs I didn’t even know about yet.

"give me the terraform configuration for an AWS ECS cluster with 2 services that can talk to each other, with one of them available publicly and the other one private"

Occasionally to give some small self-contained algorithms, for example:

Give me a way to format the difference between dates as human-readable text. For example: 1 day, 16 hours.

I quite like the search-first LLMs like Gemini and Copilot for this reason. They give you links which you can use to verify the output and seem to be less prone to directing you to SEO spam than Google Search/Bing.

Although I do partly think that search engines today are delivering poor performance compared to what they delivered historically so LLMs are benefiting from that.

A recent example is when I implemented a (Kubernetes) CSI driver that makes /nix available in a container so you can run an empty image and skip a lot of infra to manage.

I talked to it a bit and eventually it wrote a Nix derivation that runs the CSI codegen for Python and packages it so I could import it. Then I asked it to implement the gRPC interface it had generated and managed to get a "Hello World' when mounting this volume (just an empty dir). I also asked it to generate the YAML for the StorageClass, CSIDriver, Deployment and DaemonSet.

So LLM left me with a CSI driver that does nothing in Python (rather than Go which is what everything Kubernetes is implemented in) that I could then rewrite to run a Nix build and copy storepaths into a folder that's mounted into the container.

Sure implementing a gRPC interface might not be the hardest thing in hindsight, but I've never done it before and it's now a fully functional(ish) implementation of what i described.

It even managed to switch gRPC implementations because the Python one was funky with protoc versions in Nix(Python bundles the grpc codegen it's so stupid) so i asked it to do the same thing for grpclib instead which worked.

Of course, it didn't last long, and trying to Google now is an exercise in pain and frustration. Lots of people have complained about the various things Google and marketers have done to get there, idk, I just don't like how it works now.

Top LLMs feel amazingly good at rapidly surfacing info online, and as I go through the references they're usually pretty good. I guess the same forces as before will apply, and there will be some window of opportunity before it all goes away again.

The one thing they've consistently nailed has been tip-of-my-tongue style "reverse search" where I can describe a concept in sufficient detail that they can tell me the search term to look it up with.

They can get into small crevasses and the foliage and whatnot and they don't mind getting wet. They can fluster rabbits out. And are somewhat smart. But you still have to make the kill and you have to lead the dog, not the other way around.

"Copilot" is a great marketing name, but a bit deceiving.

That's basically how I use them.

I bet you could write a word processor in an hour. It might only add or delete one character at a time (no selections). It might persist only to a hard-coded "output.txt" filename. You might have to kill the process because there's no quit operation. But that would suffice for a toy word processor.

They're all doable if you focus on the core problems. He's got a github with many of the examples up, it's instructive on how to keep things small.

And I think it's important that (based on the code) he had a solid understanding of the problem space before starting to write code. You don't write that tight when you explore a new space.

Edit: https://github.com/ssloy?tab=repositories for the shortcut link :)