Joshua Vasquez wrote a piece a couple of weeks ago about how his open source machine benefits greatly from having part numbers integrated into all of the 3D printed parts. It lets people talk exactly about which widget, and which revision of that widget, they have in front of them.
Along the way, he mentions that it’s also a good idea to have labels as an integrated part of the machine anywhere you have signals or connectors. That way, you never have to ask yourself which side is positive, or how many volts this port is specced for. It’s the “knowledge in the head” versus “knowledge in the world” distinction — if you have to remember it, you’ll forget it, but if it’s printed on the very item, you’ll just read it.
I mention this because I was beaten twice in the last week by this phenomenon, once by my own hand costing an hour’s extra work, and once by the hand of others, releasing the magic smoke and sending me crawling back to eBay.
The first case is a 3D-printed data and power port, mounted on the underside of a converted hoverboard-transporter thing that I put together for last year’s Chaos Communication Congress. I was actually pretty proud of the design, until I wanted to reflash the firmware a year later.
I knew that I had broken out not just the serial lines and power rails (labelled!) but also the STM32 SWD programming headers and I2C. I vaguely remember having a mnemonic that explained how TX and RX were related to SCK and SDA, but I can’t remember it for the life of me. And the wires snake up under a heatsink where I can’t even trace them out to the chip. “Knowledge in the world”? I failed that, so I spent an hour looking for my build notes. (At least I had them.)
Then the smoke came out of an Arduino Mega that I was using with a RAMPS 1.4 board to drive a hot-wire cutting CNC machine. I’ve been playing around with this for a month now, and it was gratifying to see it all up and running, until something smelled funny, and took out a wall-wart power supply in addition to the Mega.
All of the parts on the RAMPS board are good to 36 V or so, so it shouldn’t have been a problem, and the power input is only labelled “5 A” and “GND”, so you’d figure it wasn’t voltage-sensitive and 18 V would be just fine. Of course, you can read online the tales of woe as people smoke their Mega boards, which have a voltage regulator that’s only good to 12 V and is powered for some reason through the RAMPS board even though it’s connected via USB to a computer. To be honest, if the power input were labelled 12 V, I still might have chanced it with 18 V, but at least I would have only myself to blame.
Part numbers are a great idea, and I’ll put that on my list of New Year’s resolutions for 2021. But better labels, on the device in question, for any connections, isn’t even going to wait the couple weeks until January. I’m changing that right now.
“if you have to remember it, you’ll forget it” And this is why experienced coders write extensive comments: we’ve all been bitten by ‘write only’ code.
And significative variable/function names.
TBH, I call all my functions “a”, though by the time I’ve written the comment explaining what the function does, I know what it should be renamed to.
Only some experienced coders. Some wander off to FORTH land and don’t use comments, and write shell scripts from scratch without checking man pages ten times.
Coders with really excellent memory and intelligence can be annoying to work with, they don’t understand most programming best practice because they can sorta get by without it.
But they still make bugs, because they make challenges for themselves right up until they’re just at the limit, so a lot of the time they’re not any better than average coders in practice.
Except when they are, but everyone else who has to work with their code will probably mess up.
Average but educated people who understand why industry does what it does, do some amazing work.
I think it’s less a question of intelligence, than using a common language of expression. Patterns only help to a point, a lot of them add more noise than they help, because of the many indirections, it becomes sometimes hard to follow the intent.
And as soon as you do something non-standard, that hasn’t been done many times, your patterns wont help, since you wont recognize what is foreign to you.
There is also no excuse for giving variables bad names, I never did that, also before getting formal programming education. Programming is a form of expression, not a riddle. You communicate with a computer and try to do that in the best way possible.
Unfortunately, a lot of this implicit information is lost when translating from a high level language to assembler. And it’s provably impossible to do some inferences about programs, merely from assembly code level. Cryptic variable and function names and formulations have the same problems.
It’s not a question of intelligence, but whether it is feasable at all. Knowledge is often necessary to fill in the gaps, if you lack that knowledge the possibilities are huge.
I disagree also about preferring average programmers. People need to be able to communicate, that’s also part of intelligence. Being very cryptic and loving to overcomplicate things, usually reflects a specialty skill.
Average people also tend to regularly suck at explaining themselves, if they aren’t doing what they have done countless times.
It’s really about learning to communicate effectively, and this is a skill that needs to be mastered and honed. Your averageness or differenceness is not the deciding factor, more so how much effort you put in explaining yourself, and how often you had to do it.
Average people can also be used to be understood, because there are many other average people with similar thought patterns. But they may lack real explanatory capabilities when leaving that comfortable territory, since they never really had to practice it.
Same as the people focused only on their perspective, that like to be cryptic.
All that to say: it’s whether you are willing to communicate effectively and improve there or not. Programming tools also need to improve much more, so you can express real world knowlege and assumptions, that are only codified in comments, and otherwise dead and not useable.
Communication is not valued enough in science, though it requires also a large set of skills and intelligence. And it’s not about making things relatable to the average person by forced common world comparisions. It’s expressing it in various modalities, so that people can find one that is intuitive to them.
Though you have to limit the effort at some point, because being clear to everyone is like explaining it in 10 ways at least. So again, tool support, that has understanding of what you say in comments, which is technically irrelevant for the code at a lower level, would help. They could automatically present this knoweldge in various ways, so people can use what works best for them/the situation/question at hand.
Explaining yourself is a skill and a type of intelligence, but on the other hand, the average programmer is less likely to do anything that needs explaining, or is remotely non-standard, in the first place.
The majority of talented C++ programmers seem to have a “Why would I need that” attitude, they like to build from scratch, they like to perfectly optimize for the application, and they hate dependancies.
The average programmer will use MQTT, the really exceptional one will write his own well commented message format in 50 lines of C to avoid importing some mega library.
And they’ll probably both perform approximately the same on most platforms.
Speaking of assembler, the exceptional but not quite educated guy is way more likely to use it in the first place, where the average coder coming from a JS and Python background will never touch it if they don’t have to.
There are so many areas where exceptional programmers do better, but in the end, some of them just insist on writing their own non-standard incompatible tools, and the end product isn’t any better than someone with less talent could have done, because they’re only doing 10% of the work and leaving the rest to libraries.
I’m really starting to think a lot of the problem with programming is that programmers hate their industry.
As a user, I want Microsoft-style software, but open source. I want LibreOffice. I want recycle bins Instead of deletion. I want error checking code and popup windows for every problem, support for all common file formats, and a one click, fully integrated UI, and most non-technical users agree. I want everything to work locally when my internet goes down.
The typical coder wants to build UNIXy tools that have some cool challenging algorithm, and despises looking at thousand-line files of nothing but if statements gluing together 100 dependancies, with zero novel logic.
A steady job working on microservices, or weekend tinkering with command line apps, is pretty much a coder’s favorite place to be. It seems that although there is amazing large pieces software out there, coders aren’t really excited about it, and they don’t even trust it to be secure.
I almost think a lot of the really smart ones would be happier in academia.
It’s very odd to have an industry where the desires of the coders are opposite those of the customer.
I never had that problem, I have pretty below-average math skills and don’t really understand the fancy algorithms that well, and I never really had any attraction to using lightweight “do one thing” stuff, but I do run into issues with the people I work with, whenever I say “Let’s just use ”
>they’re only doing 10% of the work and leaving the rest to libraries.
That’s a great way of introducing bugs that you can’t fix – leave it to the magic black box and cross your fingers that everything works as expected. Guess who has to go fix it afterwards?
You do 10% of the work, which creates a program that needs to iterate through 10 versions to squish all the bugs, which ends up being the same work as doing the work from the ground up by a person who actually understands what they’re doing.
The person who has to fix it is me, and I usually can, because I’m using open source libraries. Fixing is faster than DIYing, unless you’re way better than the original library devs, or you’re willing to greatly cut down your functionality.
Some things are just plain outside my skill level to write or debug, like FFTs, cryptography, or Golay coding, but that kind of thing is usually done by popular and well tested libs, and generally those projects attract a lot of maintainers.
Just because I write something doesn’t mean I’m sure it’s bug free, and if things did work that way, other people’s libraries would be flawless too.
Simplicity might get you to excellence when everything is just right, all your parts are high quality, and you have specialists for all the relevant things.
But complexity will get you to “Pretty Darned Good” even when users are clueless, budgets are low, the deadline is three days, and you can’t even wait for requirements before you start building.
If you’ve got some real natural talent for math and enough spatial intelligence to know which pedal is the gas, you’re probably better off at a job that isn’t like that, doing all the cool real innovation and making medical devices or something.
For the rest of us, and all the projects worth doing, but that don’t need, and can’t afford, that level of time, talent, and parts, complexity makes it work anyway, and the art of dealing with huge amounts of complexity at varying degrees of reliability is a very accessible skill that doesn’t require genius or a PhD.
People think that simplicity is somehow “of the common people” or more accessible. But in reality, anyone can make a complex project, and make it tiny, crazy efficient, and cheap, if they make a Mouser order. That’s what consumer tech is.
Simplicity requires understanding every relevant property of every part, sometimes in ways a datasheet can’t quite capture, and it doesn’t leave any room to hide anything. If you do it right, it might be very reliable, and you’ll be able to explain every part, but it’s probably going to require quality parts, skilled assembly, even more skilled design, and it’s still going to happily burn itself to a crisp if the user is the type that has no business near it.
Occasionally you get something like “Prime objects”, like a spoon or a folding knife, that don’t need any extra complexity, but those things are widely loved and celebrated, which to me shows that creating something new like that, is a big deal.
There’s a good use case for “write once” code – code you want to force yourself to refactor and write properly if you ever touch it again.
…Which is why I have not one, not two, but eight dedicated label printers around the shop, each loaded with different media.
I’m still looking for a good Brady-type cable label printer for a reasonable price.
The K40 makes a fine panel labeler too, for any painted metal, anodized aluminum, or acrylic.
Check out Destin’s nifty laser+paint trick to label an acrylic panel: https://youtu.be/cqidD7kVnxY?t=576
Didn’t leave the paper on, or doing it on a painted metal plate? Use masking tape. Also: use multiple etching passes for sharper edges (at least on my laser).
Haha
I once designed a board with eight optos and a microcontroller on it all nicely labeled. The production house decided they liked black solder resist without silkscreen and made 250 boards with the opto’s the wrong side around. :) now that was an expensive rework on their costs.
I’m so used to being the one making the mistakes, I was super surprised the first time I ever had a problem with the production house. You’re supposed to be pros! This isn’t supposed to be a thing!
And then it happened again…
Are there any open source label maker designs? Seems like that would be useful.
Yes: I’ve got an open-source recipe for ink from acorn shells and iron oxide. There’s also open source plans for dip-pen nibs on instructables.
Personally I tend to use a sharpie to label things, but their ink is evil and proprietary.
To clarify – open source stuff is great, but when you want a tool that just works, it’s not so important. I’d put a labeller in that category, with screwdrivers and saws.
So I have one of those label makers that has a cassette of whitw vinyl label tape and a dye ribbon (you know the ones, they’re ubiquitous) and I found that deeply buried in its pictogram/image/punctuation library are greek letters and some key electical symbols (including ground).
By setting the font to small and making the label two lines (which makes the font even snaller and stacks two lines of text on the 12mm tape) I can make labels sufficiently small but still very readable and cut them out from the tape so that they can be stuck to the space “behind” the screw on most styles of screw terminal block.
This has been life changing and it was a strategy that I took up after flubbing the order of signals on screw terminal blocks one to many times… they also stick well to PCBs and I’ve even stuck then on wires before encasing the wire in clear heat shrink tubing. Since the label printer uses dye transfer rather than working like a thermal printer the labels stay completely clear and legible even through clear heat shrink.
i always keep reddish nail polish on the work bench, so at least i can label + on a two-pin connector. i also use it to mark the “top” side of a micro usb connector!
Good ol’ “D1” on the ramps bit ya. That one has got many a reprapper.
Look into a taurino power from reprapdiscount. The vreg is good to 24v.