Author: Jud

Technologist interested in building both systems and organizations that are secure, scaleable, cost-effective, and most of all, good for humanity.
A Rose By Any Other Name

A Rose By Any Other Name

In all my time thinking about how naming is hard, I’ve never come across a concise set of practical suggestions for choosing variable names in software. Until now. I’ve used the A/HC/LC Pattern my whole career, but never had a term for it. Honestly it could use a better name (naming is hard!) but the concept is solid.

There isn’t a single piece of advice in the above that I disagree with, and a few I absolutely love (my goodness do I hate context duplication in namespaced variables).

The Lies We Tell Ourselves

The Lies We Tell Ourselves

I’ve written before about the importance of writing documentation. Like anything else it’s a skill that takes both training and practice. The latter only takes time, but there’s not a lot of material out there on the former. Therefore it made me happy to discover Write The Docs, a global community of people who care about documentation.

The recommendations in their Beginner’s Guide To Writing Documentation I found quite helpful. And loved this quote, which is only tangentially related to docs:

Fear is what happens when you’re doing something important. If you are doing work that isn’t scary, it isn’t improving you or the world.

The article argues that writing documentation for yourself and others is one way to alleviate fear, and I agree. So go forth and write!

Put A Bow On It

Put A Bow On It

I spent a bunch of time over the holiday cleaning up some Python tools I’ve written, and packaging them up for easy distribution via an internal PyPI repository.

The endless list of things to learn never ceases to amaze me, in this case I got to play with tox for matrix testing/packaging, and twine for publishing. Also got a lot better at writing setup.py files and integrating quality tools like flake8 and safety.

Here’s a couple helpful write-ups that I found when researching best practices for Python packaging:

Packaging a Python library
Python packaging pitfalls

In the course of the above, I also found it necessary to inquire about modifying an open-source tool for measuring code coverage. Turns out it was easy enough to make the modification and submit a PR to the maintainer. If you’ve never contributed to an open-source project, I highly recommend it!

Something Different

Something Different

All the time spent indoors during the pandemic quarantine has afforded unique opportunities for creativity. Last night we played some D&D as a family, and to get in the right mindset, I wrote a backstory for my character. Thought I’d post it here for posterity. Enjoy!

I never knew my parents; no one did. I was left in the dead of night on the portico of the Second Temple of The Mother, naked and shivering. Reverend Shaeltiel brought me in, and quickly became like a father. As I grew, it became clear I was more than human. Not just because of my lanky frame and luxuriously long and straight hair. The reverend had never seen anyone with my thirst for knowledge. By my sixth year-day I’d memorized the entire Sacred Codex, and by my tenth there were no more books in the temple library I hadn’t read at least twice. Still I craved more.

It first happened during a thunderstorm. I laid awake, reciting an ancient poem to myself in a failing attempt to soothe my anxieties. Simultaneous with a flash of lighting outside my window, I felt a prickling sensation on my hands, and behold! Little arcs of electricity bounced between my fingers. I caught my breath, and the sparkling stopped. I would get no sleep that night.

Early the next morning I went to Reverend Shaeltiel and explained what happened. He sighed, and brought me to his study. Only behind the heavy doors did he tell me that he’d long feared for this day, for my prodigious intellect had tapped into forces older than any beings on earth: the elemental forces. He explained that with further study and practice, I could master these forces. How did he know this, I asked. Because he too could command them. It was a skill forbidden by the church, however, and in his zeal for faith he’d resisted its practice. With time, he said I could do the same, but first I had to learn control.

For months we trained together, always in secret. I brought forth light from darkness and summoned great bolts of fire from my hands. From a hidden chamber in his study, Reverend Shaeltiel provided massive tomes containing even greater possible feats where even the great storms could be tamed and focused. My knowledge grew, and my power grew with it.

In retrospect, it was inevitable that I’d be exposed, for there are to be no secrets in the Faith of the Five, and this was a small temple, in an even smaller village. I’d been practicing a thunderclap incantation, and how I might combine it with an amplifying focuser. Little did I know the resulting shockwave would explode from my chambers, shattering the stained glass in the adjoining sanctuary and echoing across the valley. Reverend Shaeltiel came running, his eyes met mine, and together we came to the same conclusion: it was time for me to choose: either embrace the rules of the faith and rein in my burgeoning abilities, or find my fortunes elsewhere. I chose to go.

That evening I left the temple, and now I quest for further knowledge and how I can bring the power I wield to defend truth and justice, and to show to myself and the templars of the Faith of the Five, that they needn’t fear the ancient elemental forces. They are but tools for a greater purpose, a purpose only the future can reveal.

No Silver Bullets

No Silver Bullets

I thoroughly enjoyed the advice given in Scaling with common sense, probably because I’ve violated each of those principles at various times in my career, and are (hopefully) wiser for doing so.

But the real gem was a link to the following sketch:

I’ve been in that meeting, both as the speaker, and as the listener. Whenever I hear someone say “just move to microservices” like it’s some kind of magic spell that instantly fixes all problems, I want to go full-on Andy Bernard and punch a hole in the wall.

No True King

No True King

Recently I’ve revisited thoughts I’ve had about what it means to be a senior engineer. One summary I came across that I liked was making the move from “delivering” to “leading”.

And another I gleaned from an email Eric Raymond sent to Linus Torvalds regarding the latter’s over-reliance on his own genius. While not sent in the context of senior-level engineering, I think it’s still informative of an attitude adjustment that must be made when taking on the mantle of leadership:

The bill always comes due — the scale of the problems always increases to a point where your native talent alone doesn’t cut it any more. The smarter you are, the longer it takes to hit that crunch point — and the harder the adjustment when you finally do.

There will come a time when your raw talent is not enough. What happens then will depend on how much discipline about coding and release practices and fastidiousness about clean design you developed before you needed it, back when your talent was sufficient to let you get away without.

I would add “ability to delegate and elevate the work of those around you” to that last paragraph. It’s hyperbole to say that every line of code written by an engineering leader represents a failure, but I coach up-and-coming senior folks to think that way nonetheless.

Slacker Part Deux

Slacker Part Deux

The advice in Five Nonobvious Remote Work Techniques is broader than just Slack, but given my prior post on best practices, I thought I’d mention it for further reading.

Technique number three from that article made me think of an additional helpful hint for Slack conversation. If you initiate a conversation via at-mention, you should be prepared to dialogue in real-time. There’s a cost to causing an interruption to another person, and one should try to minimize the duration of said interruption by treating the interaction as if it was an in-person conversation.

Also, No Hello. Get to the point.

Be A Slacker

Be A Slacker

No online collaborative tool is perfect, but when used well, Slack is pretty close. Having participated in multiple Slack workspaces across several organizations over the past few years, I’ve become somewhat opinionated (and hopefully qualified) on what constitutes “used well”. Here’s my take on some best practices:

Yes, I own Slack socks
  • Set up your profile with your real name, and add a high-quality photo. This helps interactions feel more personal, and when communication is done primarily over the Internet, every little bit helps.
  • Set up notification rules and a do not disturb window in preferences.
  • Strongly consider disabling audio notifications, as they can be a distraction to those around you.
  • Conversation in public channels is always the preferred approach.
  • Single-user DMs are acceptable for private conversation, but consider if your discussion might be valuable for others to see and contribute to. When in doubt, go public.
  • Group DMs should almost never be used unless the topic is sensitive and needs immediate response. Otherwise consider using a public channel with @mentions.
  • Temporary channels are an acceptable alternative to group DMs. Prefix them with temp-, and /archive them when conversation is complete. Typically these should not need to exist more than a day or two.
  • Discussion in a public channel where response from a specific small group or individual is needed can be easily accomplished through use of @mentions. Brief side discussions can be done with threads vs. splitting off into a new channel or private DM.
  • @channel notifies all members of a channel, even if they are outside of working hours, and should be reserved for emergencies. @here is almost always more appropriate, as it only notifies members within working hours. Even better is a small list of specific @mentions.
  • Use /mute when you want to stay in a channel but not get notifications from it. @mentions will override mute, so you’re still reachable.
  • Use /dnd when you need to ignore all notifications for a period of time (e.g. to go heads-down on a task, you’re giving a presentation).
  • Consider turning off message preview in notifications, unless you want to run the risk of a sensitive (or embarrassing) message being viewable by others.

Happy Slacking friends!