I would say thinking about the indended audience for your creative outlet is a good discipline - even if it's only one person. It often gives the project more of a focus which helps with motivation and makes it more enjoyable.
Honestly a lot of useful software is ‘unimportant’ in the sense that the consequences of introducing a bug or bad code smell aren’t that significant, and can be addressed if needed. It might well be for many projects the time saved not reviewing is worth dealing with bugs that escape testing. Also, it’s entirely possible for software to be both well engineered and useless.
I see a lot of people talk about 'insecure code' and while I don't doubt that's true, there's a lot of software development where security isn't actually a concern because there's no need for the software to be 'secure'. Maintainability is important I'll grant you.
Oh, finally someone who speaks the truth :D yeah, security su*ks everywhere. True. But when you grow a product with time, you fill the holes one by one when you start losing water. With AI, you will have so many holes in your 15 days made battleship, that... good luck putting it at sea, you can tank in the first minute. As Moltbook has shown. I don't have to find proofs (which I dont actually find). I just need a counter example and... first big vibe product I've seen, first gigantic security failure. Plain to see.
For sure, but I haven't written a single piece of software where security would ever be considered a factor. Not all software runs on the web, not all software deals with accounts etc.
I think this is too broad. If, for example, I get Claude to set up a fine tuning pipeline for rf-detr and it one shots it for me, what have I lost? A learning opportunity to understand the details of how to go about this process, sure. But you could argue the same about relying on PyTorch. Ultimately we all have an overarching goal when engaged in these projects and the learning opportunity might be happening at an entirely different level than worrying about the nuts and bolts of how you build component A of your larger project.
Yeah, I used to enjoy writing code but after a while I realised I actually more enjoy creating tools that I (and other people) liked to use. Now I can do that really quickly even with my very limited free time, at a higher level of abstraction, but it's still me designing the tool.
And despite the amount of people telling me the code is probably awful, the tools work great and I'm happily using them without worrying about the code anymore than I worry about the assembly generated by a compiler.
I’m building an application for documenting modular patches, mostly for my own use case. It uses ML to recognise the patch points, knobs and toggles from a photo of the front panel. You can then build racks from the scanned modules and then store presets of the knobs and connections which are displayed as simple schematics. Idea is ultimately to have it on an iPad as reference to accompany a live performance. Had some fun fine tuning the cable physics engine.
reply