Writing toy software is a joy

I'm surprised by the number of bad takes on LLMs in this thread.

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.

I think one of the major issues I (and others) have with LLM's as search is they are heavily biased towards outdated data. The other day I was trying to have it get me the most updated versions of X, X, X from an old project. I tried several providers and all of them without exception gave me an "upgrade" to an older version than was in the project for at least 1 item(by years). I'm sure they are choosing LTS releases over the new ones because that is most popular overall in a dataset. However no matter how "hard" I prompt they keep giving me those old ones over "latest"

I've got a VPS and domain I've had for a long time - for most of these, docker compose + the VPS did the job just fine. I was in the same boat - I'd fallen behind on a lot of the ops stack, and project setup wound up being a tar pit for a couple projects before I got frustrated and just said "Fuck it" and did it the dumb way, which wound up being the correct approach.

I found the trick with the personal projects was to pick the thing I was trying to learn with that project and focus on that - if I was trying to learn React, don't also try to learn kubernetes or lambdas or anything else. You really have to be comfortable with your project kind of sucking for all this to work.

So I'd say if you want to learn proper modern deploy + CI/CD + etc, take a project where you already know the rest of the stack (hell, make it Hello World if you have to) and use that. Keep things simple and in scope, get something stupid working, and then iterate to make it better.

Your project is vastly more specified than a toy project, because it has a real customer (you) who will expect it to work after it ships. That expectation is what separates toys from real tools.

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.

For what it's worth, the two tricks I found for leet-code interviews were 1) do the simple stupid thing first - get something _working_, and then make it good and 2) explain what you're doing and what you're thinking about to your interviewers. I'm still not Great at the leet-code style, but you can get a lot of the way there with some basic knowledge about algorithmic design and complexity and data structures. In general, I've found finishing the problem and being able to talk coherently about it trumps finding the ideal solution.

(I also code like a psychopath - I'm constantly rewriting what I'm writing while I'm writing it, so a) slowing down and b) telling interviewers what I'm doing and why made that look less chaotic.)

I'm also not the person you want to hire if you're looking for deep algorithmic knowledge, though - I've got a long career of delivering high impact systems and solutions, but if you want someone to rewrite the index parsing algorithm in your mature database software to minimize lookup speed, you've got the wrong guy.