Writing toy software is a joy

I love that attitude! This is essentially my preferred answer to "what would people do in a post-AGI world when they don't need to work any more".

> Perhaps you’re a user of LLMs. I get it, they’re neat tools. They’re useful for certain kinds of learning. But I might suggest resisting the temptation to use them for projects like this. Knowledge is not supposed to be fed to you on a plate.

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?

I'm writing a shell right now in ruby after seeing a few other folks doing so and looking at the current state of shell development and not finding anything I really liked. It is indeed, a lot of fun. Using Vidar's really quite nice text editor to do so is equally pleasurable.

https://github.com/vidarh/re

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

There are several sources of joy in programming. Some lean more toward the process and exploration of the problem domain, others more toward the outcome and impact.

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 ;-)

This is also a great way to stand out among other candidates in the resume-review stage of a hiring process.

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.