I’m currently working with a new and exciting client. Secret project is moving forward slowly right now and I might be picking up another mentee fresh out of boot camp shortly. Good times.

Me and my wife also visited the US for PAX Unplugged and saw NYC while we were at it. The jetlag is really screwing with me right now. Other than that, happy to be back in the swing of things.

Podcast recommendation: Hurry Slowly

Hurry Slowly is a very good podcast by Jocelyn K. Glei. It is calm and gives you well-scoped episodes that neither overstay their welcome nor pass too quickly. It tackles productivity, focus, creativity and pacing yourself with a warmth and curiosity that I rarely find elsewhere.

I found her through Focused (previously Free Agents, I'll cover that at some point) and since then she has been a good addition to my thinking on running my own business. The content is mostly interviews with different experts within the subject matter. Some episodes focus on her reflections. Pick what episodes seem interesting to start. It is not sequential.

The latest season does away with the productivity angle and Jocelyn shifts focus in a way that has me curious. I heartily recommend the backlog and I look forward to what is coming.

How we run dangerous commands

I'm in an odd mind-space and have been turning some tech-culture things in my head. Shared experiences, culture and tradition. Maybe I can blame the holidays. I'm glad I have some people to share this thinking with because I feel like I'm thinking in a few new angles.

Have you ever had to run a potentially dangerous command on a production server? A destructive piece of SQL? A batch update/data migration script? Cleaning up accumulated garbage files in a recursive manner?

How did you approach it?

Do you have a small alarm bell that goes off in your head when you are close to doing something that would be really painful (or impossible) to revert? Do you adjust your approach because of this? I know I do.

Like a cluster of synapses that got together just for this, to prevent me from shooting myself in the foot at the terminal. Probably from the time I blew away my entire music collection with a bad shell script. Or the first time I rm -rf:ed something that ended up resolving to /. I haven't had this kind of catastrophic failure in a while. Thanks brain.

When I feel that tingle of "are you sure this is the query you want to run?" I usually end up taking the SQL query, changing it to a SELECT and just eyeballing the output a bit. Does it hit the expected number of rows? Do the results look reasonable? Double-check that I just ran a fresh backup if possible.

Similarly with any recursive rm command on UNIX, what files would this hit?

Dry-running commands that support it.

I'm also well aware that this is not recommended operations in any way. If you can run testable migrations that can be rolled forward and back, that's better. If you can do it better and the trade-offs make sense, do it the better way. But don't feel bad if you don't have those opportunities or resources. We do what we can with what we have. You can get far by just developing a good instinct on when you're about to screw yourself over.

Is there a word for this alarm bell? This instinct? This moment of hesitation and the practices you put in place for making sure you're not screwing up? I think it is a shared experience of many server-wrangling developers out there. I know an old colleague that always commented out the command in case he'd accidentally fire it before it was ready. Another one that would type it out and Ctrl+C to cancel it but keep the command on screen while checking things.

It's an interesting thing to me. A small moment of recognizing that you're fallible wetware and that the machine, software and hardware, does not care. Is this the central friction of human-computer interface design?

A moment of humility, perhaps.

Rituals around deployment

When a new thing is going out, what is it you do? Do you run a specific command? Do you press a button in a Cloud console? Do you have a friend or colleague double-check your input values? What lead up to this point?

There are processes you can adopt where CI and CD will completely eliminate the final button press. I've found these to be rare in actual reality. But I hear it's a strong idea. That doesn't completely evade this thought either way. It's not all about the tech. What does your CI/CD pipeline test for and why does it do that? Who's notified, what information is broadcast when an update goes out? What rules does it use for success and failure?

It seems like there is some level of ritual around updates/releases of software wherever I've worked. I either create one from my habits or lessons learned combined with the requirements put on me or I step into and try to understand one that already exists. If I find it lacking I'll usually try to leverage understanding it, into improving it.

Why do I call it a ritual rather than just a process? I'm not convinced it is only a technical, structural matter. Often we do things that aren't strictly necessary but are reassuring.

You make sure Alex in Marketing knows the update is going out because they get pissed if they don't feel included. You have a colleague check your thinking on something. You have QA give the OK on the staging environment. Maybe you review the commit messages, or the file changes that go into the update in full. Maybe you only check if there are migrations to run. Do you tag a release? Do you push it to a specific branch.

Much like some specific flavor of a burial ceremony you have things that seem arbitrary to some but are usually part of the culture (colors, songs, phrases), things that serve a clearly social purpose (saying a final goodbye to the deceased, closure) and things that are fair to consider a technical necessity (burying/lowering the casket/putting the deceased somewhere).

In a release process some checks, steps and sign-offs can seem arbitrary but are ingrained in the culture and may have an unclear purpose or be entirely vestigial. Some only serve a social purpose. Some are a technical necessity or clearly technical choices.

I think most dev shops end up with some kind of ritual. Sometimes only for communicating the changes to the surrounding organization. Other times it can be a technically quite intricate ritual with many mysterious incantations to get that particular system up and running with a new version. The latter type is usually good targets for significant scripting and automation.

As humans I think we put some level of importance in ritual. Some feel stronger about it than others. To some it's about safety and changes to the ritual can feel frustrating. To some finding an ideal ritual is the goal and changes are inevitable. Some desire a minimal ritual or an iron-clad-double-verify-none-shall-pass sort of approach. Sometimes that's dictated by culture, sometimes by actual regulations, sometimes by resources.

I think some people rely on the stability of ritual while some view it more as a tool for a purpose. But that might also be why it works. Because it is something which many different types of people can see value in. It is a point where the lines cross, venn diagrams overlap and where the abstractions of the ritual can abstract away the differences of the participants in a shared procedure.

The longer a ritual has lived the harder I think it is to maintain the protective abstractions. Some will want the ritual to remain as it always was and some will find it stifling and want to change it. I think a lot of people experience this with Christmas for example. For many people the very basis of how to celebrate things with your family is a source of potential conflict. While the general idea of the ritual is to come together with loved ones, the particular ritual is loaded with years of tradition that some love, some endure and others try to avoid.

My family is very progressive, our Christmas celebrations has had its requirements scaled back quite far. So far in fact that I've started to re-introduce some things I've ended up missing into me and my wife's Christmas traditions. While I'm glad we aren't gripped by a tradition set in stone by our grandparents I also actually want a Christmas tree. Because I like it. The tree awakens fond memories.

So what's my point? Probably that our process as it is not exclusively based in cold logic and business realities. And that's fine. We remain fallible wetware and sometimes we need our creature comforts. Framing a process as ritual changes my expectation of what it should achieve from the raw technical output to a wider consideration of the people involved.

UNIX as a tradition

I'm not sure I should say UNIX, or hacking or what to center the culture around. It is not only free software, or open source, it is not just MIT, it is definitely not exclusive to Silicon Valley startup culture. But as a developer on Linux with mostly open source tech you are working in a world wrought mostly from a mix of cultures, some of which I mentioned. I'll center it around UNIX because I think that's largely accurate.

When you use a term such as grok or borked you're leaning on that tradition. There is a lot of useful shorthand that stem from this common traditional lexicon. Some of this stuff is also quite the shibboleth, a way to identify if people are part of this tradition.

Tech and software development as a culture is widening and I'm sure there are plenty of developers who have minimal exposure to this particular culture. That's fine. Years in corporate dev might not expose you to this, I don't know, haven't tried it. Going through a software dev bootcamp at 30 you might have no previous interest and you won't absorb a culture from a X weeks long intensive course.

So the traditional culture of UNIX is not the only culture of software development and tech, though its influence can probably be found all over. But it is my culture. It is where I found my footing. A lot of the culture is also a bit old and a bit outdated. Most of the terminology in the Jargon file is not in use or generally recognized. A lot of people are in open source now with no particular connection to the wild 80's hackers covered in The Underground Book (free download by the way).

A lot of them have never heard of The Hacker's Manifesto. Which burned bright to me as a teenager.

That's fine. The culture has its traditions and history, I don't think it will be forgotten. But it's also fine to leave some of it behind. Some of it was only funny back then, some stuff seemed dated even when I got into it. Some of it is irrelevant. Some of it should be brought with us as good, useful, relevant ideas, interesting thoughts or inspiring history.

I feel increasingly aware that my way of knowing about computers, my way of getting into programming is not the only real way. I continue to practice the UNIX tradition, I rather like it. I'm very fond of its history. I appreciate a lot of its culture. But it doesn't live or die with whether new-comers know the heritage of grok. I'll happily put a new-formed hacker in touch with these roots. But if they don't want it, we still have plenty to share.

If any of the above questions or thoughts resonated with you, or if they were like nails on your mental chalkboard, feel free to respond and let me know. I read what I get and generally respond. I'm curious how this sits in other people's minds.

Links

Since I had a lot of words built up inside and you've been subjected to many of them I'll keep this to some simple delights:

Making Backpack Pattern - By Noodlehead

I want to try my hand at sewing something like this. I generally have a bunch of things I want to make that require me to know some sewing. I think it seems like a cool and doable project.

Atacac - Sharewear

This stuff is a bit wild. Sharewear patterns that you can pick up for zero money or more and then make clothing of. They also make the clothing if you'd rather not do the work. I like the ideas and I've had a chance to see their operation. Next time I drop by I'll try to find some time to talk to the people running it. I really like what they're up to.

ElixirConf 2019 - Lightning Talk - Heralding Harald

I've been following Daniel Spofford's work on Harald off and on in the Elixir Slack. He is making a Bluetooth Library that can run natively on the BEAM VM. The progress seems solid and it will be a glorious addition to the Nerves stack to have a native Elixir Bluetooth library rather than shelling out to bluez.

Let's Encrypt makes certs for 30% of web domains

I'm mostly delighted to see this level of adoption. Let's Encrypt made something (HTTPS/SSL for web hosts) that used to be very finicky into something quite trivial. Which is sometimes what progress feels like.

Cyberpunk web design UI framework

I'm a sucker for cyberpunk. This delighted me.

Ableton - Get Started Making Music

This seemed like a cool resource for learning some music stuff in a tech-friendly way. Ableton makes a big ol' music-making application. I haven't gone through it but it seemed quite neat and over the last year or so I've done a bit of learning about digital music-making.

KeyHut - Free Point-of-sale system

The site looks dreadful but is fantastic and the system seems well-loved among its users. There is space for everything out there.

Syntax Highlighting is Backwards

I don't think I agree with this one because I rather prefer to find the opening and closing of my control flow stuff. But I appreciate the exploration of alternatives.

Thanks for reading, you can get in touch with me at lars@underjord.io

Have a lovely day, I need coffee

- Lars Wikman