Hacker News new | ask | show | jobs
by 101008 21 days ago
I think this is incredible, and I am so happy for him, he deserves all the praise he gets (and maybe more).

I will sin and make this about me, briefly, but just to say that when I was a kid/teenager with a really slow computer, a) I enjoyed coding much more, b) I think I was a way better programmer. Constraints make you better, you have to be smarter. I miss those times.

7 comments

Well, nothing is easier then adding constraints. Removing them is what's difficult - so why don't you add them back if it makes you a better programmer and you enjoy doing it more?

Personally, I think the reason you enjoyed it more as a teenager is just down to the fact you were fully in control of what to do and had no external pressure to earn money etc, so if anything you had less constraints - at least from my point of view

> Well, nothing is easier then adding constraints.

Which is why dieting and quitting smoking are famously easy things to do! ;)

There's something to be said for the "scrappyness" of resource limitations inflicted upon you when solving some problem. A sense of Triumph against the Universe itself is a nice pay-off

Smoking and eating unhealthy food are constraints to life! ;)
Over a much longer time horizon than trying to run Doom on a ZX Spectrum.
> nothing is easier then adding constraints

What's easier is removing the constraints you just added artificially. Constraints you can remove with a flick of a finger are not constraints.

> so why don't you add them back

The reason the proverb says "necessity is the mother of invention" is because "desire" is usually not enough to drive it. It's easy to take the hard road when you're forced onto it, but very hard to choose it when there's an easy alternative.

> Constraints you can remove with a flick of a finger are not constraints.

Why not? Who cares how/why they're there, as long as you follow the constraints, regardless of how easy they are to remove, they're still there.

I frequently use this when stuck creatively in music production. "Ok, now I can only use this filter for any sound shaping", or "Make a song using only instruments outputting mono", or "Maximum 10 cables to make a new sound on the modular synth" or whatever. Really easy for me to skip these artificial constraints at any time, they still help a lot.

> Who cares how/why they're there

The people who face them. The constraints are making the goal harder to reach. The goal is on the other side of the constraints and it takes power of will to refuse to remove them and keep pushing. This forces a different, slower, more difficult to reach solution.

> when stuck creatively in music production

So you're not introducing constraints, you're creatively trying out things to fix your problem. They're not a wall preventing you from reaching your goal, they're the bridge. Your constraint is the temporary lack of creativity, and what you introduce is the means to reach the solution faster.

> Really easy for me to skip these artificial constraints at any time, they still help a lot.

When you remove these you're stuck in a creativity block and failed to achieve your goal. When you remove actual constraints you make the goal easier to reach. It's a matter of perspective and what you want to achieve. You wouldn't want a long road through the mountains as your daily commute but it's probably lovely as a hike.

The only way to make the problems comparable is to set a programming goal of "write the most efficient code to do X" but for real work the goal is almost always "do X".

> So you're not introducing constraints, you're creatively trying out things to fix your problem. They're not a wall preventing you from reaching your goal, they're the bridge. Your constraint is the temporary lack of creativity, and what you introduce is the creative solution.

I feel like we're talking past each other. Adding these sort of requirements in order to "fix the problem", is typically what people are referring to as "adding artificial constraints to foster creativity".

The goal is making a song, anything that restricts you on how you are allowed to do this, is a constraint, as far as I understand the word "constraint" at least.

> When you remove actual constraints you make the goal easier to reach.

Yes, this is why the previous examples are constraints, not "bridges". Without them it's easier, with them it's harder.

I think you're missing the context of what started this thread:

> I was a kid/teenager with a really slow computer [...] b) I think I was a way better programmer. Constraints make you better, you have to be smarter.

The goal is "write software" not "write optimized software".

When your goal is to write a software that runs on your machine, having the constraint of a slow machine forces you to write optimized code which is a slower, more difficult solution. When you have an unconstrained fast machine you can write boilerplate unoptimized code, which is quick and easy. If you constrain your fast computer you go from "easy solution" to "difficult solution" for the same goal of "write software". No programmer will ever say "making the computer slower really helped a lot to write code".

Your goal is "make a creative song" but you're stuck. You don't introduce constraints because they'll make it harder to get unstuck, you introduce them to make it easier. You literally said "they still help a lot".

> I frequently use this when stuck creatively in music production. [...] Really easy for me to skip these artificial constraints at any time, they still help a lot.

That's what you're missing. For you the real constraint would be to get creatively unstuck without any tricks. You are introducing things to help you reach your goal to get unstuck. You're expecting programmers to introduce things that prevent them from reaching their goal of creating programs that run.

In reality one huge reason software is slow and unoptimized is because programmers have beefy machines and can afford to take the easy road.

I didn't expect this simple concept will need so many explanations.

Because the software industry doesn't pay anymore for constraints or doing things "the hard way". Everything is high-level language and by tomorrow. The day after it doesn't exist anymore anyway.

I'd wish to get a project that's low-level, multi-year and high quality of engineering and longevity. Make the best you can – something to be proud of.

Which is often the case in music too actually. So many famous artists and bands created their best work early in their careers. You would think touring and several albums make them perfect the craft of making songs, but I think involving money and external pressure actually kill the creative spark if you’re not mindful about it.
Those early albums often consist of material that was basically battle-hardened by the time it reached the studio. Bands early in their career often spend lots of time all in the same room, writing songs together then do lots of playing for small crowds, where they get a very up close feel for the audience response. Material that doesn’t go over well with band mates and audiences gets dropped.

With the industry’s album release cycle, bands are often under time pressure to cut a new album, so they end up writing in the studio, each person laying down tracks individually, and missing out on all the feedback of earlier iterations.

I wrote about 10 albums and my music generally got better over time, but I just stopped writing because I had children; also less time for creativity with a family.

If I were forced to write music, now, for money or whatever, it would be bad music.

> Well, nothing is easier then adding constraints.

Technically it's easy. Mentally it's nearly impossible. This comment posted on Ars yesterday blew my mind:

https://arstechnica.com/ai/2026/07/we-cannot-choose-to-becom...

tl;dr: When given the easy option, people always take it, even when they know the hard route would be better in the long term. But the full story is interesting and not that long, it's worth reading.

Adding contraints makes it take longer to deliver a result. I probably cannot install today's engines SDKs and related tooling for example. I'd have to write my own. Doable, and would make me a better programmer, but you won't see results for a long time.

As it happens, I do this. I have various projects burning for years and yet to be published because in my hobby time I value good engineering over results.

Simple and easy are often conflated a bit, but measured by outcomes, are quite different. Comments offerring humorous parallels of common simple and easy conflations will follow.
That's true, I just wanted to maybe add a new perspective to 101008 view that if he enjoyed working with technical constraints, he can still target eg embedded systems with massive resource constraints - and also to force an acknowledgement that the reason for his likely nostalgia to this kind of coding is likely more related to the mental freedom he enjoyed while working back then ... Because that too can be done, albeit with the caveat of time constraints because life doesn't go away no matter how much someone may want it to.
I feel exactly the same way. Though one extra factor is that I feel like my time was so pure back then. Now, with multiple degrees, I keep thinking about weird concepts like 'opportunity cost'. There was no opportunity cost when I was a kid. There was just time. Bucketloads of it!
I enjoy going back to basics every once in a while; do Arduino / embedded programming on a shitty netbook (it came with Windows but it has only 32GB of storage so it couldn't even update), build games / stuff in Pico-8, start a new Go project with just the main toolkit, etc.
Yes, true creativity usually or mostly comes from real constraints, in my experience.

As, if there are no constraints in some specific area, there is no kinda "survival need" to improve there, hence brain is not working as hard/smart/deep as it could.

Re: making things about me (but also kind of related), I am working on a project that requires sending encrypted telemetry data from a Crazyflie drone (so, STM32) and it's such a fun experience. Each telemetry payload is just 26B so I had to get creative, write down packet diagrams and then make it work in C. An AI agent helps a bit with some stuff but you're mostly on your own.

In general I highly recommend going the embedded/IoT way if you look for challenges and constraints.

> I will sin and make this about me (continues to make an awesome, general point about engineering)

:)

And that is why gamedevs do not get machine-upgrades