I love it when people say "Oh, I'm not a programmer" and then continue showing the stuff they've built (and fully programmed) that is a way beyond in complexity than what most of us professional programmers get to work on, like ever... :)
The very complexity of the stuff they build is part of the problem. They are typically very smart, but often build Rube-Goldberg machines instead of looking for a simplification.
an easy way to find work to help with on github is to go to hackaday or some other such 'hackaton/diyer' community and follow the project links -- you can spend the entire evening fixing foot-guns and lazy/naive implementations of fairly well understood early CS concepts -- that's not to say that professionals don't make the same mistake, but amateurs who are just trying to get something to work rarely hit the codebase again after the thing does what they want.
Are you saying that programmers do? I mean, they should, but…
Usually with a variety of reasons, but it boils down to not prioritizing keeping the code clean. Invariably that's led to a higher carrying cost and decreasing ability to meet business goals.
But you're right, it's a rare developer that's interested in doing the unsung work of keeping a codebase clean.
When you interrogate, they'd say almost sheepishly 'oh I'm no programmer I just threw this together.' I don't think they realize 98% of programmers are just throwing things together and acting like a God when it actually works...
Inspiring. Love when people do this. Makers gonna make . . .
More generally speaking, I wish more people were like this creator - unafraid to just dive in and get stuff done. I have done a little bit of teaching introductory programming and one of the things I emphasized is that "works but is suboptimal along some professional measure" mostly rounds to "works" even in professional settings.
Part of my actual day job is working with non-professional software developers and helping take "non-professional" prototypes to "better" implementations. Having a working prototype is often a much better starting point that a poorly specified set of requirements . . .