January, 23, 2024 archives
Dream jobs
I have been low-key job hunting since May 2023. Things were getting tough with our store, and my initial hope was that I would be able to get a full-time position somewhere and turn over day-to-day handling of the store to a manager. I should be able to earn way more as a software engineer than I could have hoped to through the store.
The first job I applied for was with Automattic. They don’t seem to advertise specific software engineering roles these days, but just have a general application for that department. I figured with my PHP and MySQL experience, I’d at least start to progress through their hiring process. I never heard back. I even reached out to Matt since he had commented on my blog post about when blo.gs ended up in their hands. I never heard back.
I kept looking. About a month later, I applied for a job with Canonical (makers of Ubuntu Linux). The specific role probably wasn’t a great fit for me, but I figured I would at least get on their radar as someone with a lot of open source experience that was looking for work. I got a form rejection the next day.
And then we started the process of closing the store, and my job hunting became more of a full-time endeavor.
Always I will mentally try on the job for size and temporarily fall in love or at least get comfortable with the idea.
Working for ProPublica or The Getty Foundation would be amazing.
Work for Convoso? Sure, I can make that work.
Amazon? Facebook? TikTok? Why not?
I applied to be the Director, AI and Emerging Technologies at the LA Clippers. Why not?
“Our recruiting staff will review submissions and will contact only those candidates who meet our job specific requirements.”
“If your application seems like a good fit for the position, we'll contact you soon.”
“After review, if your application seems like a good fit for the position, we will contact you to set up an interview.”
It is a frustrating process full of silence with a small sprinkling of rejection.
I have had one interview with a recruiter which led to a quick “After much consideration, we've made the decision to not move forward at this time.” (For Centerfield, working on web properties like TheSeniorList.com. It was a hybrid position that would have required going to an office a couple of times a week. Why not?)
The store is closed now, and I spend even more time searching and applying. Mentally trying on the jobs for size.
Some of the jobs seem like a great fit — a dream job.
Some of them seem like they would fit just fine — also a dream job.
The joy of open source
As I mentioned, one of the reasons I was trying to get organized in setting up my development environment under chezmoi
was because I was wanted to start using Atuin, which does what it claims in making the shell magical. It stores and syncs the shell history (in an SQLite database behind-the-scenes), and while I have only just started using it, it seems pretty great. Before starting with it, I just had the bash history set up on my primary development machine to never expire, so there was six years of history there (now imported into Atuin).
But Atuin is fairly new, and I ran into some rough edges. One is that because I’m still using the bundled bash
on macOS, and it is a very old version of bash
, not everything works correctly (accessing the history by up-arrow just errors out). This has been fixed in the Atuin repo, so it should no longer be a problem after they roll out their next release.
As I finished integrating Atuin into my chezmoi
setup, I noticed that it seemed to no longer be updating the history on my Linux box. When I went into debugging it, I finally found that I was loading two different versions of bash-preexec
. One was being loaded by my chezmoi
setup (where it is set up to download to ~/.bash-preexec.sh
in my .chezmoiexternal.toml
), and the other was being loaded by /etc/profile.d/wezterm
. My version was 0.5.0, the version that WezTerm was loading was 0.4.1.
Between those two versions, bash-preexec
decided to change the variable that they use to prevent double-inclusion, but the implementation was sort of one-way: the new version would set both the old and new variables, but only check the new one. So if you loaded the old one first, the new one would still load and (apparently) not work correctly.
I let Wez know that he was bundling an old version, which he promptly updated (and so it’s fixed in the nightly builds now). I also submitted a patch to bash-preexec
to pay attention to the old guard variable, so whenever they do a new release that particular problem won’t bite anyone else. (They will face a new one, where having an old version of bash-preexec
loaded may prevent the newer version from loading, but that should be relatively straightforward to figure out.)
This journey brought to mind an experience I had at HomePage.com about 25 years ago. We had a fleet of front-end web servers that all accessed user storage on an NFS server (an F5 box) and we were running into trouble where the Linux machines would periodically get stuck or die. It was an all-hands-on-deck situation trying to figure it out, and I eventually hit enough things with hammers to figure out that it was a bug in Linux NFS and there was a fix in a later kernel version that I could just back port and suddenly our Linux machines were stable. I pointed out the fix that could be back ported to Alan Cox, then maintainer of the stable Linux kernel. It’s possible they were pulling my leg about it, but the marketing/PR people at the company talked about putting out a press release about how I had fixed a bug in NFS on Linux. I found the whole idea embarrassing and felt this was all just part of the normal open source process.
(Small side note: The company ended up migrating the front-end servers to FreeBSD, which had been a parallel investigation to me debugging the NFS problem.)
This is the sort of mess I enjoy digging my way out of, and it is generally more fun to do this in the open source world than in some company’s proprietary codebase.
Another tool I plan to explore is ble.sh
which is recommended by Atuin. The entire idea of line-editing and syntax highlighting built entirely in shell code sounds ludicrous.