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.

A couple of good reads I’ve encountered in the last month or so that cover things I’ve thought myself, but are written much better than I would have: The Beginner’s Creed - something I’ll probably keep in my notebook in perpetuity. Small Functions Considered Harmful - related to my DRY Isn’t Free post. I’m an Idiot The Wrong Abstraction. If you’re a programmer/software engineer/whatever, read them, they’re well worth your time.

(see here for the full Agile Organizer series) I’ve now been using my agile organizer system for now going on three years, with a few adjustments, but the main principles firmly in place. I did however switch form factor from letter sized to junior sized paper (5.5” x 8.5”, or the half-letter-sized) and 2x2 sized stickies rather than the standard 3x3. As not everything winds up on stickies, as I keep a running log of what I’m doing, notes, etc.

(see here for all the posts about using a diver’s bezel) I previously wrote about things that you can do with a divers watch bezel. Since then I’ve figured out a few things. It occurred to me that most of the techniques I spoke about in the previous post work best when you have a fully transferred minutes bezel (i.e. a marker on the bezel at every minute), like you find on just about all Seiko Divers, the Rolex DeepSea, newer Omega Planet Oceans, Omega Semaster 300Ms, Fortis divers, as well as many others.