Unprofessional programmer. Former professional programmer. Former leader of the Pirate Party of Canada. Recurse Center alum/never-graduate. I build things because I want them to exist.
If you read my previous blog post, Agile programming with ADHD, you could be forgiven for being left with the impression that I am a superhero, not least because I open the blog post with those words.
My intention was to counter the notion (no less present in my own mind) that ADHD is exclusively a burden, all cloud with no silver lining. However, while I have certainly found ways to use the peculiar characteristics of my brain to my own advantage, there are plenty of times when I have to try to muscle my way through things that my brain really does not want to do.
While my previous post talked about ways I use my own quirks to my advantage, I would also like to give some exposure to mitigation strategies: things that are unambiguously harmful, and how I keep their impact as limited as I can.
A year ago today, I left my last job to do a 3-month batch at the Recurse Center, followed by... something. I never really articulated what that something was going to be, which was part of the point. I wanted to take some time to discover what really motivated me as a person.
I expect to be on that journey for the rest of my life, but a year on, I do have a few thoughts to share. In honour of one tradition I don't miss, the sprint retro, I'll structure my insights according to the good ol' liked/lacked/learned/longed for format.
Today I'm proud to announce initiative.sh, a storytelling aid for game masters with a particular eye towards Dungeons & Dragons. initiative.sh is designed to be used at the table (real or virtual), supporting your creative process as sessions evolve in real time.
This project has been a product of about six months of focused development so far. It's particularly exciting for me because it is the first product launch of my funemployment. This also marks the first time in longer than I can remember that I've bootstrapped a project of my very own from greenfield to a real, sustainable development cadence.
I am a superhero.
Let's get that out of the way right off the bat. I am a superhero who can shoot laser beams out of his eyes. Pretty cool, huh? Only problem is, it only happens when I sneeze. And it always happens when I sneeze.
This is what ADHD is like. It's taken me a long time to figure out that shooting laser beams out of my eyes has its practical benefits, and it's taken me even longer to find some admittedly unreliable ways to control it: making the laser beams happen when I want them (let's call that "sneezing powder"), and making my superpowers go away on the occasions when I don't want to light whatever I'm looking at on fire (let's call that "clothespins on the nose").
Okay, but really. What superpowers do I have?
Every now and then, I find myself facing a giant pile of files that need renaming in some way. Now, there's always a tradeoff of number of files vs. complexity where the balance of time spent makes sense to reach for an automated tool, but learning a few tricks off the top of your head can tip the balance in favour of automation and save a lot of time.
Like what seems like most of the tech world by now, I recently got a reMarkable 2 tablet and love it. Major credit where it's due: reMarkable doesn't even make you jump through hoops to get root filesystem access. It's enabled right out of the box, and you just have to plug in a USB cable and connect using the IP address and password provided in the on-device help. No danger of tivoization here.
However, it does get tripped up slightly by the classic open-source foible of
deciding that making an edge case feature theoretically possible is good
enough, and there's no need to make it intuitive. In this case, I speak of
modifying your lock
and adding custom
Both workarounds involve manually modifying a particular directory on the
/usr/share/remarkable, which gets overwritten every time you install a
software update. Fortunately, Git has my back!
Note: Data in this blog post has been anonymized, for obvious reasons.
When Quebec announced that it would be sending proof-of-vaccination emails to everyone who had been vaccinated with an attached QRcode, I got a bit weak at the knees. I couldn't wait to pick it apart and shake my head at the amount of private medical information that would doubtless be exposed in the process.
Well, my proof of vaccination finally arrived, and the result is… actually pretty okay. Still, there's always some fun to be had in zero-knowledge hacks, so I thought I'd blog about my experiences anyway.
Since I left my job, I've tried to refocus myself on simple one-person projects that I can ship and (to some extent) forget about. Hopefully a few will see a modest profit, some others are intended to be open-source projects, and quite a few are just for my own amusement.
However, the biggest problem I've encountered so far is a stark reckoning with where my strengths really lie. I've spent ten years working full-time as a programmer, long enough that impostor syndrome shrank from a constant specter looming over me to only the occasional bout. I'd even gotten pretty comfortable calling myself a "senior software developer" with a straight face. The wakeup call for me has been leaving my work and attempting to do a junior's job again.
Self-employed. Programmer without portfolio. Gainfully unemployed. Funemployed. Retired. These are all terms that I've tried on over the 6 months since I left my last job (ever?) at the tender age of 33, but none of them feel right.
Perhaps I can best express my goals in terms of what I don't want. On one end of the spectrum, I don't want to be idle or hedonistic. On the other hand, I don't want to found a startup that will go public or sell to Google for billions. It seems like finding a place between those extremes should not be difficult, but my search is ongoing. (And this article, such as it is, has no answers to offer, only more questions.)
At this point, most developers use Git as a tool for collaboration. We have our rote-learned commands to pull, commit, and push. And of course, there's that one coworker who knows a bit more about Git than everyone else, who helps get us back on track whenever our local repos end up in a strange state.
But what if I told you that Git can be a valuable tool without ever setting up a remote repository? I'm not just talking about having a working version of your code base to roll back to if you mess something up, although there's that too. Used correctly, Git can help to structure your work, identifying gaps in your test coverage and minimizing dead code.
A simple application to select Mysterium cards so you don't have to.