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 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.
You and me both brother :)
> No programmer will ever say "making the computer slower really helped a lot to write code".
I guess I'll be the first, as a programmer I do this all the time, when developing browser stuff I frequently throttle the available bandwidth and introduce jitter in the network connections so I can see and understand how things work with less optimal network connections, loads of us professional programmers do this when aiming for high quality software meant for end-users, in loads of different environments, not just browser development. Making the computer/IO/whatever slower/"less" does help a lot to write software for others.
> You're expecting programmers to introduce things that prevent them from reaching their goal of creating programs that run.
Well, yes and no. I expect professional programmers, my peers, to do this, as this is how you typically build reliable software, but I don't expect everyone to do this, definitively not amateurs just programming for fun.
> 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".
Cheers for the attempt to decide what my goal is but no, the goal never is "make a creative song", the goal is precisely as previously stated: "make a song". Helpful tip for the future, read and understand what people write and don't assume they lie or misunderstand their own intention, and it'll be easier to understand other's point of view.
Regardless, I feel like both of us are digged into our understanding what the whole "add constraints to do better" process means and is, and no harm no foul, what I know helps me and I'm sure what you know helps you, so lets just leave it at that :) Wish you the best of weekends!
For me wearing a parachute is a constrain and carrying it is an act of will. For a skydiver not so much.
Again, my goal is "Ship working software", I don't care about optimizing at all, just baselevel "working" state of things, that's why I test things like reliability. But also again, our perspectives and understanding of terms seems to diverge a bunch, so much that discussing them seems relatively fruitless, at least seemingly to the two of us.