Am I the only one using LLMs as if they were a search engine? So before LLMs I was searching on Google things like "pros cons mysql mongodb". I would read the official documentation of each db, forums, blog posts, stackoverflow entries, etc. It was time consuming on the searching side. The time it took to read all the sources was fine for me (it's learning time, so that's always welcomed). Now with LLMs, I simply prompt the same with a little bit more of context "pros and cons of using mysql vs mongodb when storing photos. Link references". So, I get a quick overview of what to keep an eye on, and the references are there to avoid relying on hallucination.

It's true that sometimes I go ahead and say "give me a data schema for storing photos metadata in postgres. I wanna keep X in a different table, though" (or something like that). But I do that because I know very well what the output should look like (I just don't wanna spend time typing it, and sometimes I forget the actual type that I should use (int vs integer?)).

I decided to constrain myself to one week per project - whatever I could get done in a week was what I’d do for this project. The experience of going from zero to something useable in either a new language or a new framework or a new field in a week was enormously confidence-building - learning that I was actually pretty good at this whole programming thing and breaking through a bunch of walls I’d run into previously in my professional career gave me an incredible amount of trust in myself to be able to take on new challenges that really helped me when I was looking for a new job. At the same time, it reminded me what I loved about programming - in a week, I was able to build something that solved a problem I had or that someone I knew had, and I got to do so in a creative and intellectually challenging fashion.

If ever you find yourself in a position to take a couple months off between jobs, skip the leetcoding or whatever else and just build some toy projects - you’ll be amazed how much you already know.

Working on your bike is fun. Working on the bike you need to ride to work tomorrow is stressful.

I miss writing toy software. It’s fun. But inevitably I want to use said software and that’s where the trouble starts. You find all the bugs and none of the time to fix them.

- Tiny ray-tracer: https://github.com/diegomacario/Super-Sunshine - 2D rigid-body simulator: https://github.com/diegomacario/Dyna-Kinematics - Character animation system: https://diegomacario.github.io/Animation-Experiments/public/... - Animation curve visualizer: https://diegomacario.github.io/Animation-Magic/public/index.... - Motion capture playback in the web: https://diegomacario.github.io/Hands-In-The-Web/public/index...

That's a mountain of code that served one purpose: to gain knowledge.

However, am I the only one finding those time estimates way too short?

I'm not the fastest programmer on Earth, but I'm not the slowest either, and I think most of those projects would take me a lot more time than those estimates, specially if I'd be working only 2-3 hours per day.

I feel most of those projects would take significant time researching and learning about the subjects, before even starting to code.

Example: recently I replaced my Pelican blog by my own hacky static site generator written in Odin, working 2-3h per day, it took me 2 weeks -- and this is a simpler project than many on that list.

LLMs spoon-feed you with information about how things are implemented. You are not supposed to know how everything works when you start these projects. You're supposed to try your best, inevitably fail, then research the topic and understand where you went wrong, then adjust your approach. If you know how everything works and just follow the tutorial, you won't know what makes other methods fail, and by proxy what makes the one you chose work.

Write a language parser with a regex. Find out that it can't parse recursive statements. You've now learnt that regex can only parse a specific subset of syntaxes. Try to workaround this by pattern-matching the most nested statement first. Find out that it blows up performance. You now know more about time complexity and know what to watch out for when you write a real parser.

Write a non-optimizing compiler from scratch. Find out that you can't make do with unsound optimizations because you can't keep track of what optimizations are applied where. Find out that implementing sound optimizations is hard because you need to track use-def chains. Then you'll understand why SSA is used. Find out that code motion is a mess. Learn about sea of nodes. Merge every optimization pass into one because you're unable to order passes right. Learn how e-graphs solve this.

Write a layout engine. Get stuck on being unable to define what a "width" is. Workaround this with min/max/natural widths, introduce binary search, etc. Learn how this stuff works in practice (this is something I haven't personally done yet).

They say we learn from mistakes. Please don't let the smart (or "smart", depending on how you look at it) machine stop you from making them. It's not a teacher and it doesn't know how to educate.

The tip I can share is: publish them on GitHub.

You'll find out some of them are useful to a lot of people.

I have multiple toy repos with 20+ stars and one with 200+ stars.

Just put one screenshot and simple instructions to run on README.md, no need to write a manual.

As simple as `npm install && npm run start` is enough instruction for most.

The screenshot is important tho.

I get where this is coming from, and I even agree with it today, but I also want to tag it as "don't cache this opinion too hard". It's interesting to notice when and how our advice for getting help from AI is different from our advice for getting help from other humans. It would be kind of odd, wouldn't it, to put a paragraph at the bottom of a blog post that said "by the way if you have friends who are expert programmers, I don't recommend asking them for help." I think there are two clear reasons that feels odd: 1) expert friends can actually answer your questions and get you personally unstuck, which is huge, and 2) expert friends usually understand why you're doing what you're doing and that they're supposed to help do it yourself instead of just doing it for you.

One thing I bet few people have tried (because I haven't tried it myself) is actually asking an LLM to guide you like an expert friend would, instead of just spitting out code to solve your problem. Maybe they're bad at that, I wouldn't be surprised. But if so, I bet in a year or two they'll be amazing at it. It might be good to build the habit of clarifying what sort of help you need, instead of assuming an LLM will give you the wrong kind of help?

That said, I feel the conclusion on learning with LLMs deserves some more nuance. It really depends on how you use them.

This is a terrible prompt for learning:

> Implement this solution for me

This is an AMAZING prompt for learning:

> Please give me an overview of ELF. Focus on the highest level abstractions, more of the 'why' than the 'how'

Certainly one can argue that it takes something away, in that you did not have to conduct the research yourself whenever a question occurred. However, if you are engaging in honest intellectual work (i.e. really thinking), then having a Socratic teacher always ready to discuss your questions is a profound accelerant to the learning process.

-Family calendar/weather dashboard

-Bluesky reader that allows you to hide posts you've "seen"

-Work PM dashboard to make time tracking more gamified and dare I say... fun?

-Chrome Reddit extension that hides posts after viewing for X seconds

-A WordPress plugin to replace a plugin no longer maintained

What I love and had to get used to was looking/using these apps and being happy with them being only 90%. Initially I had Claude make many UI enhancements but I learned to just let most stuff go and focus on the function and building new stuff, not refinement.

The whole thing with getting people to like your work, using it for clout or padding your resume has an appeal to it that I won't dismiss, but all that takes the fun out of it.

I just don't have much else I actually enjoy in life, so ruining it with peer-pressure, chasing clout, impressing people, worrying about career prospects is a buzz-kill. I used to think that if I am passionate about something like this and I get really good at it, maybe it will help my career and prospects but the real world doesn't work that way. it sucks the joy, fun and passion out of you if you let it.

All that to say it is perfectly fine to like coding for the sake of enjoying it and nothing more. Others play a sport (or watch it), work on arts & crafts, or raise chickens or whatever, I code. I am not particularly skilled or great at coding either, I just enjoy it, and that's it.

If you have fun coding, be protective of your joy! even if you don't take it to the extreme like I do. that's my only point.

It takes regex(s), searches attribute values and/or inner text, and applies a given CSS rule to elements that match. The UI is awful (regex escaped to be inside a json string escaped to be inside a textarea all parsed by javascript) but I know how to use it.

It can probably be used for many things, but I just use it to set visibility: none on elements that link to sites I don't ever want to see (facebook, twitter, linkedin, popular pay/register-walled sites, etc). For example, my HN and reddit views just have blank lines where links any of those sites would normally be. For the most part, I add a site once, and forget they ever existed (except when their CEOs do awful things).

For example, I wanted to know if I can make 1 Kubernetes cluster span multi region, multi cloud. So I slapped TailScale for networking, replaced etcd with multi-region PostgreSQL Aurora, and span the Kubelets between my Raspberry Pi, Digital Ocean VMs, and AWS EC2. And then as the "customer app", I run CockroachDB, rqlite, and tiDB on it (one at a time, I don't want to burn money for this).

It was janky, zero SLA, I likely mis-tuned all the databases, and cost a bit of money :(. But it totally worked, all the db nodes can discover each other. I was satisfied and that's enough.

Another example would be writing my own Raft-backed database, similar to the ToyDB Rust project posted here. Is the DB useful? No. But it is so much fun and I learned a lot.

My AWS S3 bucket and private Git repo are a graveyard full of toy projects. My own Dropbox clone, Pinterest clone, Delicious clone, subset of Google Maps clone, etc. etc. are all RIP in there.

Sad but true. I especially feel that comment about losing the most “joyful” part.

# Andy Oran, Greg Wilson: "Beautiful code"

I don't need to let a computer write my software. I already know how, and I enjoy it. I need the computer to do the hard part (gathering requirements, speaking with stakeholders, etc).

Software is a joy.

  GameBoy Advance game (difficulty = 3/10, time = 2 weeks)

  Physics engine (difficulty = 5/10, time = 1 week)

  Threaded Virtual Machine (difficulty = 6/10, time = 1 week)

  POSIX shell (difficulty = 4/10, time = 3-5 days)

But regardless of the time estimates, I appreciate the idea!

That gave me a good chuckle. Yeah look, you can change your data layout to be in more of an ECS format, make some optimizations and call it a day; but in reality you're still going to be pretty far from the real thing.

I can say this because I've been working on one for some months now, of course I'm going for a production build and also to turn it into a Unity asset that's worthy of being sold, so it's going to require a lot more effort. The goal of mine is to ensure that its extremely simple to use (which Units DOTS totally fails at) while still being as efficient as possible.

Some notable things I've had to do for this project:

- I have a tool releasing on the Unity asset store (currently being vetted) that performs optimization for you, e.g. you give it a variable such as an int, a range of let's say 1..1024; then it'll automatically time your code while searching for the best sample in the range. I needed to create this for the next item, which is

- My C# Thread tool which runs managed threaded code for you. It creates no garbage so and uses the above optimizer on three different variables so as to find the best amount of threads, calls and inner loop sizes to use for your code. Because of that it can run managed code almost as fast as Burst/Jobs (whereas they use their own compiler and optimize code instead of using Mono). It can even beat Burst on small to medium workloads as long as the code inside doesn't contain some efficiency that Burst can natively fix.

- Then of course there are other things an ECS needs like pathfinding, unit collision avoidance etc. For these I have both CPU and GPU solutions since CPU only really works up to about 10k entities at a decent framerate.

So yeah, I don't recommend trying it; it's probably a total waste of time.

The compiler, chess engine, and text-editor have been targets for years but I haven't quite gotten around to doing them.

I like the idea of the bitwise challenge.

I had been thinking that another challenge that I'd like to see (and have a go at) might be a plotPixel Challenge.

Make a game that does all rendering with

    PlotPixel(x : int, y : int, color:??? )
    NextFrame(offScreen:boolean = true, clearNow:boolean =true, clearColor:??? =0)

It would be easy enough to test if a game obeyed the rules because a full video capture of the game should be possible by intercepting just those functions.

Perhaps a (generous) source code size constraint to stop people going too crazy. (maybe 64/128/256k source-code, zipped). Not for code golfing as much as to avoid people trying to squeeze Crysis though a straw.

https://github.com/vidarh/re

Got a few PRs for you when you get to this, friend.

> What I cannot create, I do not understand

I suspect Mr Feynman would have phrased this a bit differently if he had first-hand experience with the modern front-end technology treadmill.

Here's a little toy I made. Try to keep the comet on-screen by clicking to spawn a planet: https://ssl.pepas.com/gravity/gravity.html

Written in C / SDL 1.2: https://ssl.pepas.com/gravity/

Checking out Linus’ first commit of Git and comparing it with my own solution was also very interesting (and humbling).

If anyone is interested, here’s my toy Git implementation in Go https://github.com/emanueldonalds/shit

I can't afford much n the way of software, so I've been trying to learn to make do with FOSS.

It's like cooking a beautiful and tasty gourmet recipe that serves only one.

I'm sure I'll keep buying commercial games from companies with reasonable terms (GOG, maybe?). But writing my own is great fun. It'd be nice if someone else enjoys them, but they're mainly for my own enjoyment.

Oh, and I "vibe code" the old fashioned way: with a REPL and some chill tunes.

But I do like writing programs in some strange new, non-CS domain where very little software to address my very particular needs already exists. Most of the software I've written in the last few years has been of this kind, for the purposes of learning Finnish. It is amazing what a few shell scripts, fzf wrappers, and well-timed calls to an LLM can do for accelerating one's own learning process.

I work on Dart professionally. I've also been tinkering on a toy programming language that may never see the light of day. My toy language has gone through several incarnations but a while back I was working on adding algebraic datatypes, pattern matching, and exhaustiveness checking to it.

The canonical algorithm for exhaustiveness checking is this paper by Luc Maranget: http://moscova.inria.fr/~maranget/papers/warn/warn.pdf

When I first started dabbling in programming languages over a decade ago, I tried to understand that paper for weeks and just could not wrap my head around it. I don't have much of a formal CS background and that paper was impenetrable to me.

So here I am tinkering on my toy programming language and I run into again. I give it another try and laboriously implement it in my interpreter, basically doing a straight translation. I don't understand the code, but it seems to sort of work. So then I start refactoring it a tiny bit at a time into a style that fits the way I think about code. Eventually the algorithm sort of folds into itself and before I know it, I finally understand how it works. The end result was only a page or so of code, but my toy language had real exhaustiveness checking work.

Meanwhile, at work, I am working on adding pattern matching and exhaustiveness checking to Dart [1]. Exhaustiveness checking here is a much harder proposition because Dart has subtyping, unlike my toy language and the ML languages that Maranget's paper works on.

I'd been hacking away at an exhaustiveness algorithm for Dart based on a couple of papers about Scala's approach but they were sort of approximative and inelegant (in my opinion, maybe they are a great fit for Scala).

But once I understood Maranget's algorithm from implementing it in my toy project, it finally clicked for me how it could be adapted to work with subtyping in a sound, coherent way. I wrote it up as quickly as I could and (with a lot of additional help from a teammate to handle generics), that became the algorithm we shipped:

https://github.com/dart-lang/language/blob/main/accepted/3.0...

It wouldn't have happened if I hadn't coincidentally been working on a toy pattern matching implementation at home.

[1]: https://dart.dev/language/patterns

Seems like the link changed, and thus not caught by the dupe detector.

The things I find fun writing and learning about and the tools I use to do it are so disconnected from anything i do professionally.

I agree. However: Your best bet is likely to build it by hand and then see if you can get an LLM to build it.

It is looking like we are living in a world where an important tool to have in your toolbox is going to be the skills and experience of working with the LLM/AI tooling. There are skills, knowledge, tools, tips and techniques that you need to develop to effectively use these tools, just like the honing you get from writing the code.

Over just the last half hour I did a brain dump of "hot tips" to a friend of mine who is just starting to use Claude Code to kick-start him.

The LLMs are REALLY good at writing small toy programs, and at the end of the day it's great to have little tools that you'll use every day.

These projects are going to be sideprojects and with busy schedule it might get tough to find motivation. Using LLMs for some of the parts can give the momentum required to continue.

We can also learn from studying the output generated by LLMs.

also lol toy projects expose your defaults hard. how you name vars when there's no PR. how you layout dirs when no one's looking. do you even test stuff or just printf until it works. do you log or do you trace or just guess.

Life is too short to spend in front of computer.

Writing software funds my joy.

Go to gym.