… at least document what failed and give the failure analysis a good effort. And then later on, you can “try, try again” or let someone else carry on with the work; they’ll have a good basis to start from.
We were talking about a project to use 10 W blue lasers to post-smooth 3D prints when I came up with this not-very-catchy catchphrase. The project itself is very much “in progress”, which is a nice way of saying that it hasn’t yet fully met its goals. But nonetheless I was entirely happy to watch not one, but two, videos where [I changed a thing] discussed the intricacies of laser-smoothing 3D prints, precisely because it sounds easy but absolutely isn’t, and because the problems were laid out so well.
I definitely take for granted how easy the slice-it-into-layers nature of FDM 3D printers makes path planning. After all, you can print interlocking knots, hinges, and even entire sections of chain mail as long as you only have to go one layer at a time. When you print this way, you never have to worry about the print head crashing into something that you’ve printed before, or being unable to reach into a small valley. To smooth two or more layers of a 3D print into each other, you are suddenly out of the comfy flatland. You have to worry about collisions, obstructions, and all the rest of actual 3D.
But those issues and more were carefully documented as [I changed a thing] went through his attempts at writing the software to drive the laser-augmented machine, and honestly that attention to the problems that were confounding him was worth a dozen “success” videos. In that sense, it worked on me a little like nerd sniping.
Those were my takeaways from the video series, then. One, it’s hard to do laser smoothing uniformly. But two, documenting the difficulties, considerations, and failures for your future self, or for others, is not just good practice, but can also encourage other people to help you with your project, or to take it on themselves. The more thought you put into how and why your project failed, the more bait you’re laying out for the next nerd. And that’s at least one part of what makes the open-source ethos work.
… destroy all evidence that you ever tried. (remove all witnesses, destroy all physical evidence with chlorine based bleach, acids, bases, industrial waste incinerators, and thermite. And emigrate to an non-extradition country and change your name.)
While the response was one of jest, there unfortunately is truth behind “hiding from ones failure” due to the animosity often shown on so many social sites.
There is something about forums that make some individuals real assholes; something that keeps the human spirit in negative territory. And those who so often make rude and crude remarks do not provide any solution or positive insight to move the failure into the light of success.
(Insert image of dead horse being beaten)
It’s why you have to lean into being a bit of a silly clown sometimes. Online one must prove they can laugh at themselves. In real life as well, but it’s a difference of degree. Being online is kind of like being behind the wheel of a car: even a mild-mannered person will allow their cruel side to come out once they’re behind some machinery. I’m guilty too.
Most of us are. I also am. Sure, you can be humble all you want but a backlash on the scale of the internet obviously scares me.
I have around 40 repos hidden for various reasons, sometimes im not happy with the result, sometimes not happy with the polish; sometimes i was just experimenting and keeping it a reference to myself BUT the code i had written was so hacky that I feel embarrassed to change it to public, yet, it’s a working code that makes it clear why i wrote what i wrote.
I feel like no amount of confidence should result you getting beaten like a dead horse but at the same time no amount of self-doubting and low self-esteem should prevent you to be happy with your small successes.
It is, however, very hard to find the middle ground to be comfortable with it. In the best scenario you have a community you can share your s**tpost code and be sure you will get only constructive criticism, but not everyone is lucky like that.
Even though I can’t accept it myself, it is very normal to have publish a unpolished website. Many people has one. Mediocrity is alright.
If only I could accept that fact myself and let myself be.
I have been making an effort on my OSHW projects to list every hardware problem encountered as an issue and including short writeups on the fixes. It has helped me keep track of revisions and mods over the years. With any luck the issues I found will help others as well.
Can’t say I have ever learned anything useful by doing it exactly right the first time. Keeping track of what doesn’t work is actually more valuable to me than what does.
One can build on success, building on failure is futile.
The true value is keeping notes on how you corrected the failure into a successful end product: You can build on such knowledge.
i don’t agree but maybe we’re disagreeing on the definition of ‘building on’.
when i build on success, i use one set of techniques. when i build on failure, i use a different set of techniques. but both success and failure are the foundation to everything i accomplish. in the code editor, at the workbench, and in my relationships too.
failure is easy to build on, i think. i’ve got two big options that both look attractive to me (it has to have this appearance to me, or i won’t continue the project). i can try to do ‘the exact opposite’, which is sometimes clear and sometimes not. or i can try to do ‘something almost the same but just different enough, maybe it will work this time.’ and both of those can cover a lot of interesting ground. can be a good time for me as a hacker. and both of those often lead to something workable.
success is harder for me, but maybe that’s because failure often wears the cloak of success! for example, if the prototype works well, as i add more features, sometimes i get stuck in a trap i made for myself in the prototype. if it looks like success, sometimes i struggle to realize that it was actually failure. that can waste a lot of time if i have been rigidly plowing forward when i should have been using one of the failure techniques to discover more of the problem space.
an example of how failure can clearly illuminate a path is the concept of a bug report. i write down what is wrong, and as i write it down, quesions appear in my brain. and as i pursue the answers to those questions, almost always, more questions, until a remedy appears in my brain. then, a fix. a testcase to show the bug. hopefully another testcase to show that the fix didn’t break everything else. each step of the process almost always immediately causes the next step to appear in my brain. there are a few decision points but failure is like carrying a lantern. it always illuminates one step ahead of me, and i just have to follow.
success is so much harder, man. i never know where to go from success.
Success and failure are just a binary NOT operator in the step-ahead-process. Instead of Why did it not work you ask Why did it work (and what can be changed without breaking it). The difference as building ground is that you need some kind of success to proceed: if you always fail, you get a very sturdy and wide foundation, but you can’t go “up” from there (counting “placing the first brick” as success instead of “wall finished”).
Talking of going down rabbit holes: this way you explore all the rabbit holes, then dig up the ground between the holes, exploring that too. You end up with a planet of dug-out material floating around in empty space, so you may want to stop that process before finishing it.
i believe deeply in diaries of success and failure. but i have noticed that sometimes after success, what i am doing is summarizing ‘online advice’ in my diary. like, in 2023 i replaced the headset of a bike, and over the last week i repeated the whole process on a different bike, learning from scratch from google/youtube/etc. instead of reading my diary from 2023, which — i just checked after the fact — had a great and short description of exactly the processes i just learned.
a lot of things seem redundant lately.
There is no failure, but to choose to give up
To lose the joy of getting back again to start
To look again to taken paths and brushes that may hide a lot
What could be worse than choosing just to stop?
Becoming a beekeeper for example.
Strange way of wording it, “things that failed”. I always think of “thinks that where tried”, why it’s called “try again”, right, during development.
Failure analysis is sounds more like something that was working, shipped, and then failed.