For at least as long since I came up with The Agile Organizer I’ve been using disc binding systems like the Arc-M from Staples. While the Arc-M system works, it was never quite what I wanted. Recently, I finally discovered a product that’s what I’ve actually wanted.

A co-worker recently gave a talk on shuffle sharding and the thought came to me: we know that that for n things taken k at a time you have _nC_k, and what that evaluates to; given n and k. How do we map a number between 1 and _nC_k to a unique set of selections, and vice versa, given the set of selections, can you get back to the original number?

As you get more experience in being a software engineer, the trajectory that companies I have worked for look for you to be able to expand your scope. Something they will call out as a way to accomplish this is the term “influence without authority”, which is just a really fancy set of words that mean “persuasive”. I’ve had good soft skills for a while, but if you asked me what exactly it was I was doing, I’d have had a hard time explaining what it was.

It all started because I suck at the log searching tool I’ll call <LST>¹. Mostly because I used it a little, but not enough to warrant me really digging in and learning it for real and internalizing its search syntax. Between me struggling with the tool, and that it would be multiple seconds between query and seeing results, I was getting really frustrated trying to diagnose issues with the services I was working on.

When working in a code base that’s been around for a while, you will find lies in the code. These lies are usually not put there by nefarious actors, so there’s no conspiracy, or secret cabal. But either by engineers who don’t realize what they’ve done, or more commonly by code evolution, these things happen. These lies are the unaccounted time sucks when working in a code base, as people working on it have to dig deeper, search for things that don’t exist, maintain code that doesn’t need to exist, or worse make incorrect assumptions about the state of the world as they work through and around them.

This is very much a crackpot post. I’m not an SME in the area which I’m writing, so I’m totally unqualified to write on the subject and certainly wrong. But as I was digging into quantum stuff, I had thoughts. I did math. I even plotted a few things. Sometimes something seems all mysterious and astounding. Then you learn how it works, and it’s really disappointing. For me, magic tricks often have been that way.

I’ve spent a lot of time over the course of my career in other people’s code, and as a result, I’ve learned a lot about what kinds of things make code easy to navigate, and which things made reading and debugging code more difficult. The way I promote coding styles are reflections of those things which made things easier, and avoiding those things that make it harder. When I get into a code base, I want to be able to easily:

I’ve know for a long time that you could convert any iterative function to be recursive and vice versa, but up until recently, I only knew how to go from iterative to recursive in a mostly formulaic way. I recently saw a cool presentation where he shows a refactoring to deterministically (at least AFAICT) go from a recursive function to an iterative one. It took me a bit of rewatching and fiddling as to how to apply it, but now having done a few exercises, I have a good feel for it, and I thought perhaps using a slightly more involved example might help explain it to others.

(see here for the full Agile Organizer series) I’ve been using the agile organizer for better than four years and it’s worked swimmingly. But I started working at Dropbox last year on a product called Paper. I figured I’d give Dropbox Paper a go to see how well it might fit in with the Agile Organizer, either for collection or whatever. Well, after 16 months, I’m still using Dropbox Paper to do AO.

(see here for all the posts about using a diver’s bezel) I’ve written a few posts about things you can do with a diver’s bezel, and today, I’m adding a few more. What Day Of The Week Is It? My current daily-wearer watch doesn’t have a day of the week complication on it, and mostly, this isn’t a practical problem I have. However, when I’m off for a few days, I often don’t know what day it is – first world problem, I know.

While I’ve had my organizer figured out for over four years (see here for the full series), I had struggled with the choice of writing utensil. I realize this is more of a connoisseur kind of thing, as strictly speaking, my choices are wide, so if you’re not into stationery, you can basically ignore the rest of this post. I started with the classic Bic Stick pen. While it has the advantage of being cheap and pretty bulletproof (at least for me), it’s not that smooth of a writer.

For my current job, I’ve had to learn how accounting works. In order to learn that, I did the kinds of things you’d expect I might. But one thing I kept finding was that some fairly simple concept seemed to be explained in a way over-complicated way, after I eventually was able to figure it out. I eventually figured out why, and with that, I think that if you’re new to accounting, and a software engineer, I think I can help you out.