Live data from Hacker News

Writing toy software is a joy

blog.jsbarretto.com

211–220 of 318 posts

Re: Writing toy software is a joy

#211
post #3

Toy Software is a lot like working on your bike/car/boat/whatever. 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.

I actually only like working on software that has a real use, at least to myself. The coolest is when I spin something up fast at work and people start relying on it.

Same goes for my car, it's satisfying doing inexpensive fixes to keep it running. Wouldn't want some mid-2000s BMW project that's stuck in the garage half the time.

Re: Writing toy software is a joy

#212

Earlier quoted context omitted.

I do this. But the killer usecase for me is writing all boilerplate and implementing some half-working stuff keeps my attention on the issue which makes me able to complete more complex things. 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 deri…

I hear a lot of people talk about LLMs writing the "boilerplate" and wonder why they haven't abstracted that away in the first place. Maybe my brain has been permanently altered by hacking Lisp.

Yes, good tooling shouldn't have boilerplate. Minimizing loc (within reason, not code golf) is the best thing you can do for maintainability. Unfortunately things like Java are popular too.

Re: Writing toy software is a joy

#213
post #39

> 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 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 document…

I just used an LLM to sleuth out a concurrency issue earlier - I could see what was happening in the debugger, I just couldn’t really see why - asked the LLM to talk me through lifecycle stuff, and boom, first thing it brought up was apparently the answer. Thank you, glorified fuzzy search! Much quicker than pouring through the docs.

I got lucky sure, and sometimes I don’t get so lucky - but it works often enough to have become a part of my regular approach at this point. Why is the thing broke? Maybe the robot knows!

Re: Writing toy software is a joy

#214
post #39

> 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 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 document…

The few times I've used LLMs as question answering engines for anything moderately technical, they've given subtly-but-in-important-ways incorrect information such that taking them at face value would've likely lost me hours or days of pursuing something unworkable, even when I ask for references. Whether or not the "references" actually contain the information I'm asking for or merely something tangentially related…

Yes, you have to be very careful when querying LLM's, you have to assume that they are giving you sort of the average answer to a question. I find them very good at sort of telling me how people commonly solve a problem. I'm lucky, in that the space I've been working has had a lot of good forums training data, and the average solution tends to be on the more correct side. But you still have to validate nearly everything it tells you. It's also funny to watch the tokenization "fails". When you ask about things like register names, and you can see it choose nonexisting tokens. Atmel libraries have a lot of things like this in them

#define PA17_EIC_LINE PIN_PA17A_EIC_EXTINT_NUM #define PA17_EIC_BIT PORT_PA17A_EIC_EXTINT1 #define PA17_PMUX_INDEX 8 //pa17 17/2 #define PA17_PMUX_TYPE MUX_PA17A_EIC_EXTINT1

And the output will be almost correct code, but instead of an answer being:

PORT_PA17A_EIC_EXTINT1

you'll get:

PORT_PA17A_EIC_EXTINT_NUM

and you can tell that it diverged trying to use similar tokens, and since _ follows EXTINT sometimes, it's a "valid" token to try, and now that it's EXTINT_ now NUM is the most likely thing to follow.

That said, it's massively sped up the project I'm working on, especially since Microchip effectively shut down the forums that chatgpt was trained on.

Re: Writing toy software is a joy

#216

Earlier quoted context omitted.

I do this. But the killer usecase for me is writing all boilerplate and implementing some half-working stuff keeps my attention on the issue which makes me able to complete more complex things. 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 deri…

I hear a lot of people talk about LLMs writing the "boilerplate" and wonder why they haven't abstracted that away in the first place. Maybe my brain has been permanently altered by hacking Lisp.

Boiler plate that is primary (not generated from a concise generation) is counterproductive: instant tech debt.

The way to to use AI is to get help writing that generation logic, not to just get it to crank out boilerplate.

You're not winning just because AI is taking the manual work out of cranking out primary boilerplate.

Re: Writing toy software is a joy

#217
post #29

Earlier quoted context omitted.

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 -…

The converse is actually a negative signal for me. If you list a GitHub profile on your resume, but that GitHub profile is a ghost town consisting exclusively of "test repo please ignore" and "freshman-year assignments I was required to fork from professor's repo," that tells me you don't have an above-average understanding of why you add something to your resume. If you don't have an impressive GitHub profile, that'…

I wouldn't consider a GitHub full of "tutorial apps" as a red flag because it's very easy to underestimate the work behind a project when looking at it from an outsider's perspective.

This is especially true for code that was voluntarily written in someone's free time. For example, each work day is made of 8 hours 5 days a week, but a "hobby day" is more like 3 hours every other weekend. So I would consider one or two features per year to be a pretty productive pace for a volunteer, free time project. Or, worst case scenario, I would just be neutral about it and ignore those projects.

Re: Writing toy software is a joy

#218
It seems to be an unpopular opinion here. But the last thing I want to do when I get off of work is touch a computer. I haven’t desired to be a hobbyist developer nor have I written a single line of code that I haven’t gotten paid for since the day I walked across the stage with my CS degree in 1996. I was hobbyist for 10 years before then.

Life is too short to spend in front of computer.

Writing software funds my joy.

Re: Writing toy software is a joy

#220
post #18

> In 2025, the beauty and craft of writing software is being eroded. AI is threatening to replace us (or, at least, the most joyful aspects of our craft) and software development is being increasingly commodified, measured, packaged, and industrialised. Software development needs more simple joy, and I’ve found that creating toy programs is a great way to remember why I started working with computers again. Sad but t…

> AI is threatening to replace us (or, at least, the most joyful aspects of our craft) 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…

I find using the LLM as a rubber duck helpful, even if, no, especially if I do not even end up pressing send. Just writing out the problem leads me to the answer.
Post reply on HN