In Praise Of “Just Because” Hacks

Sometimes you pick a project because the world needs it to be done. Or maybe you or a friend need it. Or maybe you don’t really need it, but it fulfills a longstanding dream. In my mind, the last stop before you reach “why am I doing this” is the “just because” hack.

The ideal “just because” hack is limited in scope. You don’t want to spend years on a whimsical project, and because of this a “just because” hack isn’t usually motivating enough to keep you going that long anyway, except for the tenacious few. A “just because” doesn’t necessarily have to be an easy win, but it makes sense for you to see your way out before you get in too deep.

I’m not sure if it’s the Baader-Meinhof phenomenon or not, but in the last week or so in the Hackaday universe, a lot of people have been singing the praises of “just because” hacks. (Check out this one discussion, for instance.) Mostly, it’s a combination of them turning out better than initially thought, or it’s about the learning that came along for the ride. Of course, many of them spin off into longer, serious projects even if they didn’t start that way.

Not everything in life can be frivolous, of course. But that makes the “just because” hack that much sweeter, and you should try to make mental room for them if you can. When the stakes are low, creativity can be high. You might still want to impose a deadline, lest you fall into eternal yak shaving, but take it easy. You don’t need a justification all the time: the journey can be the destination.

Yesterday’s Future Is Brighter Today

The demoscene never ceases to amaze. Back in the mid-80s, people wouldn’t just hack software to remove the copy restrictions, but would go the extra mile and add some fun artwork and greetz. Over the ensuing decade the artform broke away from the cracks entirely, and the elite hackers were making electronic music with amazing accompanying graphics to simply show off.

Looked at from today, some of the demos are amazing given that they were done on such primitive hardware, but those were the cutting edge home computers at the time. I don’t know what today’s equivalent is, with CGI-powered blockbusters running in mainstream cinemas, the state of the art in graphics has moved on quite a bit. But the state of the old art doesn’t rest either. I’ve just seen the most amazing demo on a ZX Spectrum.

Simply put, this demo does things in 2022 on a computer from 1982 that were literally impossible at the time. Not because the hardware was different – this is using retro gear after all – but because the state of our communal knowledge has changed so dramatically over the last 40 years. What makes 2020s demos more amazing than their 1990s equivalents is that we’ve learned, discovered, and shared enough new tricks with each other that we can do what was previously impossible. Not because of silicon tech, but because of the wetware. (And maybe I shouldn’t underestimate the impact of today’s coding environments and other tooling.)

I love the old demoscene, probably for nostalgia reasons, but I love the new demoscene because it shows us how far we’ve come. That, and it’s almost like reverse time-travel, taking today’s knowledge and pushing it back into gear of the past.

Fossil Files: My .Emacs

Last week, I wrote about cargo culting in a much more general context, so this week I’m going to come clean. The file that had me thinking about the topic was the worst case you’ve probably ever seen: I have a .emacs file kicking around that I haven’t really understood since I copied it from someone else – probably Ben Scarlet whose name is enshrined therein – in the computer lab in 1994! Yes, my .emacs file is nearly 30, and I still don’t really understand it, not exactly.

Now in my defence, I switched up to vim as my main editor a few years ago, but this one file has seen duty on Pentiums running pre-1.0 versions of Linux, on IBM RS/6000 machines in the aforementioned computer lab, and on a series of laptops and desktops that I’ve owned over the years. It got me through undergrad, grad school, and a decade of work. It has served me well. And if I fired up emacs right now, it would still be here.

For those of you out there who don’t use emacs, the .emacs file is a configuration file. It says how to interpret different files based on their extensions, defines some special key combos, and perhaps most importantly, defines how code syntax highlighting works. It’s basically all of the idiosyncratic look-and-feel stuff in emacs, and it’s what makes my emacs mine. But I don’t understand it.

Why? Because it’s written in LISP, for GNU’s sake, and because it references all manner of cryptic internal variables that emacs uses under the hood. I’m absolutely not saying that I haven’t tweaked some of the colors around, or monkey-patched something in here or there, but the extent is always limited to whatever I can get away with, without having to really learn LISP.

This ancient fossil of a file is testament to two things. The emacs codebase has been stable enough that it still works after all this time, but also that emacs is so damn complicated and written in an obscure enough language that I have never put the time in to really grok it – the barriers are too high and the payoff for the effort too low. I have no doubt that I could figure it out for real, but I just haven’t.

So I just schlep this file around, from computer to computer, without understanding it and without particularly wanting to. Except now that I write this. Damnit.

Featured image: “A Dusty Old Book” by Marco Verch Professional.

Cargo Culting And Buried Treasure

I have no idea how true the stories are, but legend has it that when supplies were dropped on some Melanesian islands during WWII, some locals took to replicating runway signs in order to further please the “gods” that were dropping them. They reportedly thought that making landing strips caused laden airplanes to visit. Richard Feynman later turned this into a metaphor about scientific theory – that if you don’t understand what you’re doing deeply, you may be fooling yourself.

I’d like to be a little bit more forgiving of adherents of technological cargo cults. Because the world around us is very complicated, we often just take things as they are rather than understanding them deeply, because there’s simply only so deep you can go into so many fields.

Is someone who doesn’t know the i386 machine language cargo-culting their way through a job as a web backend developer? Probably not. But from the perspective of an assembly-language programmer, any of us who write in compiled or interpreted programming languages are cargo-culting coding. You don’t need to understand a cell phone to dial home, but can you really say that you understand everything about how one works?  Or are you just going through the motions?

So while some reliance on metaphor and “well, it worked last time” is perfectly normal, I think noticing when you cargo-cult is also healthy. It should also be a warning sign, or at least a flag to remind yourself that there may be dragons here. Or maybe just a buried learning opportunity, the X that marks the spot where digging deeper might be productive.

I Need A Hackation

In recent times, the “staycation” became a popular alternative to forays far afield: you could take time off and enjoy your local surroundings without having to get stamps in your passport. But I don’t need to go to a museum or visit an amusement park, much less catch up on Stranger Things. I’ve got a project burning in my brain, and what I need is a few days of good solid time in the basement workshop to make some headway. What I need is a Hackation.

Some projects make great after-work distractions, but this one is hard and requires my full brainpower. It’s just not a beer-and-a-project project. So during the week is out. That leaves weekends, but that’s prime time for hanging out with the family. Sure, I can get work in a few hours of good mid-day think/work time in on a Saturday or Sunday when my son is out playing with friends, but there’s something about devoting a whole day or more to cracking a tough nut.

Of course, I’m fully aware that I’ll probably not get it finished in just a day, and that I’ll want another day, or yet another. So be it. Isn’t that the way it is when you’re at the beach in the summer as well? Shouldn’t hacking be at least as high on the priority list as a trip to Disneyland?

Have you ever taken a Hackation? Because that’s what I need. And please tell me there’s a better name for it.

Art of 3D printer in the middle of printing a Hackaday Jolly Wrencher logo

Brainstorming

One of the best things about hanging out with other hackers is the freewheeling brainstorming sessions that tend to occur. Case in point: I was at the Electronica trade fair and ended up hanging out with [Stephen Hawes] and [Lucian Chapar], two of the folks behind the LumenPnP open-source pick and place machine that we’ve covered a fair number of times in the past.

Among many cool features, it has a camera mounted on the parts-moving head to find the fiducial markings on the PCB. But of course, this mean a camera mounted to an almost general purpose two-axis gantry, and that sent the geeks’ minds spinning. [Stephen] was talking about how easy it would be to turn into a photo-stitching macrophotography rig, which could yield amazingly high resolution photos.

Meanwhile [Lucian] and I were thinking about how similar this gantry was to a 3D printer, and [Lucian] asked why 3D printers don’t come with cameras mounted on the hot ends. He’d even shopped this idea around at the East Coast Reprap Festival and gotten some people excited about it.

So here’s the idea: computer vision near extruder gives you real-time process control. You could use it to home the nozzle in Z. You could use it to tell when the filament has run out, or the steppers have skipped steps. If you had it really refined, you could use it to compensate other printing defects. In short, it would be a simple hardware addition that would open up a universe of computer-vision software improvements, and best of all, it’s easy enough for the home gamer to do – you’d probably only need a 3D printer.

Now I’ve shared the brainstorm with you. Hope it inspires some DIY 3DP innovation, or at least encourages you to brainstorm along below.

Welcome Back, Supercon!

The last two Novembers, Hackaday’s annual gathering was held in remote mode: Remoticon instead of Supercon. While still recovering from jetlag, I’m reflecting on the pros and cons of live versus virtual events. And wondering how we can combine the virtues of both for next year. Come brainstorm with me!

The blatantly obvious pros of having a live Supercon is the ease of talking to everyone who is there, trading code tips, life experience, and must-see projects. In person, you can physically trade badge add-ons in real time, without waiting for customs to clear the packages. Simply hanging out has a real charm to it, and doing so over shared tacos is even better. Spontaneous collaborations were easy and natural. And finally, while you can watch someone electrocute a twinkie with a neon sign transformer on YouTube, you can’t smell the ozone.

Against this, all of the expensive travel, the aforementioned jetlag for some, and the real-world limitations that only so many people can fit in a given physical space at once.

The best part of Remoticon was hearing from people who wouldn’t have been able to make it to an in-person con, whether it’s because it’s of geography or money. Since everything is online, there’s no missing out, and anyone can freely dip in to one talk or another. The online chat channels were better attended during Remoticon as well – perhaps because they were the only game in town – but that was a more global community.

There’s probably nothing that can be done about the tacos, but what could we do about incorporating the benefits of Remoticon? We did stream one stage live, and we had two chat channels open for commentary the whole time. If you took part remotely in Supercon, let us know how it went, and if you have any suggestions to improve our remote experience for next time. Because in the end, we want Hackaday to be as inclusive and as global as the hacker community itself.

Banner Photo by Poyu Chen.