Every technical person knows, unlike artists and politicians, that they can be provably wrong; at least to a degree. Math tells the truth. Coupled with this knowledge is an ego which is often entirely based on our output. If our mechanism works, we feel good because we are provably good.
Unfortunately, unlike the robots we build or the simple minds we spin out of code, we are still human at the end of the day. When we feel the sting of being wrong we often respond poorly. Some of us slip into depression, claiming it all and dredging up a few other mistakes from our past along for the ride. Some of us explode into prideful rages, dropping our metaphorical shorts to show that this one fault is no fault at all compared to a history of personal majesty. Others become sullen and inward. Others ignore it all together. Others yet strike out at those around them leaving unpleasant barbs. The variations are endless, but I do think there is an ideal to be reached.
Despite the risk that the nature of the things I’ve learned will reveal exactly what kind of arrogant sod I am, I’ll give it a go anyway. I’ve made many mistakes, and I have many more to make, but these are some of the things I’ve learned. I’ve learned them all in technical fields, so I’m not sure how broadly the advice applies, but luckily this is Hackaday.
When I started boxing classes I was told, at my level, I could do just as much good for my form by doing core exercises such as crunches, running, push-ups, and pull-ups for a month as I could by doing the class. I consder habits like safety, cleanliness, and documentation to be habits that influence the quality of hacks much the same way. They’re not really related, and the work can get done without them, but their implementation alone improves the quality of everything you do at the workbench.
The best mechanic I’ve ever met had a well-organized shop. All of his employees wore nitrile gloves when they worked on engines to protect their hands from the chemicals inside. They used ear protection and safety glasses. His rates were low, and the car was always repaired fast. I never had to go back for the same repair twice. He knew exactly what repairs were done, and even kept the parts removed from my vehicle to show me if I desired. I got some of the most fantastic explanations of why parts failed from him. Two blocks down the street was a shop which was unorganized and had double rates. The employees were always sitting on the waiting chairs in the lounge. It took one trip there to never return.
A while back I wrote a piece titled, “It’s Time the Software People and Mechanical People Sat Down and Had a Talk“. It was mostly a reaction to what I believe to be a growing problem in the hacker community. Bad mechanical designs get passed on by what is essentially digital word of mouth. A sort of mythology grows around these bad designs, and they start to separate from science. Rather than combat this, people tend to defend them much like one would defend a favorite band or a painting. This comes out of various ignorance, which were covered in more detail in the original article.
There was an excellent discussion in the comments, which reaffirmed why I like writing for Hackaday so much. You guys seriously rock. After reading through the comments and thinking about it, some of my views have changed. Some have stayed the same.
It has nothing to do with software guys.
I definitely made a cognitive error. I think a lot of people who get into hardware hacking from the hobby world have a beginning in software. It makes sense, they’re already reading blogs like this one. Maybe they buy an Arduino and start messing around. It’s not long before they buy a 3D printer, and then naturally want to contribute back.
Since a larger portion of amateur mechanical designers come from software, it would make sense that when I had a bad interaction with someone over a design critique, they would be end up coming at it from a software perspective. So with a sample size too small, that didn’t fully take into account my positive interactions along with the negative ones, I made a false generalization. Sorry. When I sat down to think about it, I could easily have written an article titled, “It’s time the amateur mechanical designers and the professionals had a talk.” with the same point at the end.
Though, the part about hardware costs still applies.
I started out rather aggressively by stating that software people don’t understand the cost of physical things. I would, change that to: “anyone who hasn’t designed a physical product from napkin to market doesn’t understand the cost of things.”
With the advances in rapid prototyping, there’s been a huge influx of people in the physical realm of hacking. While my overall view of this development is positive, I’ve noticed a schism forming in the community. I’m going to have to call a group out. I think it stems from a fundamental refusal of software folks to change their ways of thinking to some of the real aspects of working in the physical realm, so-to-speak. The problem, I think, comes down to three things: dismissal of cost, favoring modularity over understanding, and a resulting insistence that there’s nothing to learn.