Reflections, diversions, and opinions from a progressive ex-physicist programmer dad with a sore back.
This article is a brief account of my experience setting up, operating, and using [Open Telemetry] on a very small software development project wherein I reach the surprising conclusion that it's probably worthwhile much earlier and at much smaller scales than you might expect.
#tiddlywiki #rust #selfhosting #release
I just published the first (v0.1.0) release of tiddly-wiki-server, which implements the TiddlyWiki WebServer API in Rust using Axum, SerDe, and TiddlyWiki.
There is, in my experience, a certain mindset among some information security professionals. They see themselves as the keepers of arcane knowledge, duty bound to hold the cyber-line, the last thing standing between common application developers and complete pwnage. They're the few, the proud, the ones who can shut it all down in the name of security. I'm not sure if it's a side effect of that field's association with the [“intelligence community”] or mere self importance; every profession has its foibles.
Unfortunately, apart from the usual objections to cops and special forces, I think that the metaphor leads to some dysfunctional tendencies in structure and strategy.
A useful question for understanding software tools is to peel back a layer of abstraction and ask what the thing underneath is. For example:
Knowing this sort of thing is useful when the abstractions break (e.g. when you open a text file with the wrong encoding) or when thinking about the fundamental contours of a system's possibility space. For example, if you know that programs can be configured with environment variables and CLI flags, knowing that the Python interpreter is a program means you know where to start looking if you need to configure it.
While there are many, many articles on the internet explaining how and why to use them, there's less information about what a Python virtual environment (or “virtualenv”) is. Luckily for us, it ends up not being very difficult to investigate.
When I was about eight years old I was quite literary. I read books that were said to be “advanced” for a kid my age and got good grades in language subjects. I came to value this aptitude, and considered it a point of pride. So when I was told that my sentences were strong but I needed to use more paragraph breaks, I was indignant.
Not, mind you, because I thought I had good paragraphs. As far as I was concerned, these so-called paragraphs were a fabrication with no purpose but to make me look bad.
“I read Animorphs books” I said hesitantly, “and I don't think they have paragraphs.” Animorphs books were the height of sophistication for serious eight-year-olds back then, so this would surely put a stop to this misguided attack on my savviness.
Looking back, this reaction is a clear indictment of my education, my overconfidence, or both, but luckily for me (and for everyone I've subsequently written for), my mother overheard my assertion and, with just the right amount of gentle mocking, told me to open the beat up copy of whatever YA novel I was improving myself with that week and look again.
You won't be shocked to learn that the random page I flipped to was full of paragraphs, but I sure was. There they were, little indentations, running down the side of the page, mocking me. I turned the page in amazement, as if I might find vindication on the other side, but there they were again! This was something important to me, something that made me different and special, and yet I had overlooked this feature that was plain to see on every page.
In retrospect I appreciate this lesson in personal fallibility; I've been wrong lots of times, sometimes about things as clear as typography. It stings less when you know it's coming and when you can see yourself as someone who cares for you would: obviously wrong, a bit ridiculous, but just in need of a little straightening out.
#programming #angst #motivation #legacycode
A few nights ago, in the wee hours of the morning, I came to be staring red-eyed at a list of programming languages. I'm a generally optimistic person, I enjoy learning these sorts of things, and I appreciate the things that the tools on this list had to offer. Despite all that, I couldn't contemplate investing in any of them with anything but dread.
One of the nice things about being a professional software developer is that you're always learning things. On a given day, you might be learning about
There are many things to learn. Indeed, one of the problems you might have is finding all of the things that you want to learn about.
I'm curious about some experiences I've had in the course of my work as a software developer. My curiosity comes from a place of profound ignorance, based on subjective observations of my own mental and emotional state.
This is not a well researched or thoroughly studied position, nor is it:
It's to do with a particular kind of anxiety. There are lots and lots of ways that work can make a person anxious, so I want to be clear: I'm asking about a particular, fairly narrow, set of circumstances.
When I'm doing data analysis or building applications with Python and I have to give entities a unique ID, I like to use random UUIDs instead of sequential numbers. Sequential numbers include information about the order and total number of data, but I want my IDs to be just a unique identifier, nothing more.
There is a great diversity of material for improving programming skills and knowledge. It's no great task to give examples of books, blogs, videos, live-streams, interactive tutorials etc. This diversity makes our profession better.
A surprising inclusion in this list is the podcast, which one might expect to be a bit useless: we work with a lot of plain text, complex data structures, design and layout. At first blush, this seems like poor material for a purely aural medium.
Nevertheless, I derive great enjoyment and value from listening to other programmers talk about their craft and I recently had an object lesson in why.
While working my way through the back-catalogue of the Giant Robots Smashing into Other Giant Robots podcast, I listened to a conversation between Ben Orenstein and Matt Knox about deliberate practice for programmers. A few days later, I have a Github repo for my kata and whole bunch of energy for them that I didn't have last week.
That's not a bad return when all I started with was a half-hour of dishes and a free MP3. Where did I find this enthusiasm, and why is the podcast the perfect medium to go looking for it?
An obvious benefit of listening to other professionals is that it keeps good ideas front-of-mind. Kata for programmers is hardly a new idea (heck, Jeff Atwood wrote about them on CodingHorror, so pretty much everyone has heard of them) but it's easy to lose focus and drive in that amorphous category of “professional development” without the occasional injection of perspective. Regularly exposing oneself to the ecosystem of good ideas is a good way to stay on track.
Podcasts also have more emotional weight than blogs or Hacker News. Much as one might like to be a perfectly rational logic machine, a little tug on the right heart-strings can be wonderfully effective. There's a palpable excitement, an infectious enthusiasm that emanates from professionals keen on their craft, and it comes through headphones loud and clear.
And in case this all seems like perfect fellowship and sunshine, there's a slightly pointed aspect to consider as well: competition. Besides being sources of inspiration and content, the characters coming down over WiFi can be the masters we seek to surpass or the antagonists against whom we prepare our opinions. As much as we need idols and peers, rivals and tyrants also have their uses.
So for code snippets and clever hacks, blogs are still king. Videos and prose will win out in the domain of architecture and lofty ideas. But as long as I aspire to a better technical culture than I inhabit, I'll listen to podcasts to make up the difference.
Finding good programming podcasts can be a bit challenging. There are a ton of options to choose from and Sturgeon's Law definitely applies. Try lots of things, be selective, and use an RSS reader or podcatcher to automate your subscriptions. Here are a few solid offerings to get you started.
Giant Robots Smashing into Other Giant Robots. I wasn't really excitied about the business possibilities of being a developer until I heard some of these stories. Particularly good episodes include the aforementioned interview with Matt Knox and an older interview with Brennan Dunn about the business side of being a small independent developer.
The StackExchange Podcast. Worth listening to if only for Joel Spolsky. Lots of good content about scaling up a massive website, online reputation systems, and huskies. The episode about keeping a datacenter running through hurricane Katrina was particularly memorable.
The Cognicast. This one used to be ThinkRelevance (the consulting firm that produces it merged with another one—names and URIs were changed). Often features Clojure and other functional programming topics. This interview on testing is a good one.