Live data from Hacker News

Writing toy software is a joy

blog.jsbarretto.com

51–60 of 318 posts

Re: Writing toy software is a joy

#51
post #11

One of the best things that I’ve done for myself, career-wise, came during a 6-month sabbatical between jobs. I had a bunch of projects that I wanted to do, but I kept finding myself stymied by scope creep - when you don’t have any constraints, it’s hard to decide how big a project should be, and the projects would grow to these massive unfinishable beasts. I decided to constrain myself to one week per project - what…

I would just add that gen AI can actually be a fantastic aid when you're building some toy projects just for yourself. 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 fo…

The joy of personal projects is they can look like shit! You'd also be surprised how much you can learn by just screwing around with something for a day. A big part of the whole exercise for me was getting out of my comfort zone and learning that I can learn. I'm primarily backend as well, and came up through the ops side (as opposed to formal CS), which always led to a lot of imposter syndrome, so a lot of the benefit came from just putting myself in an uncomfortable position and just staying there long enough to work my way through it.

That said, my goal for this was to wear the hair shirt (and also this was before GenAI was really a Thing) - if you just want to make something neat, absolutely vibe your way there.

Re: Writing toy software is a joy

#52
post #38

What's sad is how difficult it is to write software today. In the old days your dad could buy a C64 and cobble together an application. It should be vastly easier to do the same kind of thing with vastly better building blocks today. Why can't some Grandma drag and drop some widgets and have a recipe manager with sharing features amongst her friends and family?

Here's a few disorganized thoughts in good faith

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"

Re: Writing toy software is a joy

#53

One thing I've learned about building toy software projects or even just small personal software (stuff that's actually useful) is to avoid implementing flexible configuration engines. I used to fall into this trap where I thought I should make my software to be configuration-centric so that it would be usable for others in case I decided to make my code FOSS. The problem with that is making a configuration engine is…

> The problem with that is making a configuration engine is a lot less efficient than just writing the code to do the damn thing.

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

Re: Writing toy software is a joy

#55
post #35
post #17

Reinventing existing software has 0 merit. If you cannot be creative enough to invent new things, you shouldn't bother working.

That's rubbish. Reinventing existing software as a learning exercise has plenty of merit.

No it doesnt. Build new things or dont waste your time.

Learning exercise lol.

Re: Writing toy software is a joy

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

This plus easier search of poorly/not-at-all documented APIs is like 80% of my usage too. Besides that, a lot of “here’s my design for xyz system, am I a stupid idiot for using this architecture?”.

Re: Writing toy software is a joy

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

Yup this is where 90% of the productivity benefits come from for me. Instead of needing to spend an hour scouring documentation I can ask an LLM and have an answer in 5 minutes

Re: Writing toy software is a joy

#59
post #11

One of the best things that I’ve done for myself, career-wise, came during a 6-month sabbatical between jobs. I had a bunch of projects that I wanted to do, but I kept finding myself stymied by scope creep - when you don’t have any constraints, it’s hard to decide how big a project should be, and the projects would grow to these massive unfinishable beasts. I decided to constrain myself to one week per project - what…

I would just add that gen AI can actually be a fantastic aid when you're building some toy projects just for yourself. 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 fo…

A good reality check is: if a stranger asks you about a specific part of your toy project, would you be able to explain it?

If you can't, it means there's something there you don't understand, and you lost an opportunity to learn. Of course, this is also true for reusing libraries and stuff.

Within a job, what matters is the _team learning_, and it's roughly the same idea. At least one person in the team should be able to explain anything the team does. Trusting it to an AI puts the whole team in a precarious situation, even if it is something as simple as a CSS layout.

Re: Writing toy software is a joy

#60
post #38

What's sad is how difficult it is to write software today. In the old days your dad could buy a C64 and cobble together an application. It should be vastly easier to do the same kind of thing with vastly better building blocks today. Why can't some Grandma drag and drop some widgets and have a recipe manager with sharing features amongst her friends and family?

> Why can't some Grandma drag and drop some widgets and have a recipe manager with sharing features amongst her friends and family?

Because there's no money in it.

Post reply on HN