Mastodon

How I Work

A high level overview of my work style and how it helps improve my productivity.

How I Work

Recently, I received this nice reply on Twitter:

There's some technique to my productivity and I'd like to try to describe it in this post. It's mostly focused around minimizing idle time and easing context switching. In turn it allows me to have high output and visibility while keeping work-life balance in harmony.

What this is not: A prescriptive, "10 tricks to improve your productivity" guide. It works for me, it definitely won't work for everyone.

Principles

(in no particular order)

Keep multiple clones of the main project. At any given point I'll have 3-5 branches going and it's nice to be able to put something down without soft-resetting my workspace. Sure, you can git stash or git commit -am "WIP", but still requires changing branches and re-syncing the IDE. Sometimes I even have multiple open at once.

Minimize builds. If I can make a change without needing to build it, great! Dependency updates, simple refactorings, etc can all be committed and left to CI to build. Similarly - work in small well-isolated projects that build quickly and without much of a dependency dragnet. This is an excellent incentive to modularize.

Don't wait for CI. CI will take its time and there's no real benefit to watching the console log or sitting idly while I wait. I have GitHub reminders set up with matchers for our common CI jobs so it will ping me on Slack if there's a failure. In the meantime, I'll switch to working on something else (more coding, code review, etc). If you maintain multiple clones like mentioned above, you can easily jump back in to fix small issues CI reports too without doing a whole context switch.

Work on multiple things. Only 1-2 larger things, but I track a lot of small work I can pick up in idle moments. Dependency updates, small bugs/improvements, etc. I always feel like I have something I could do and as a result I don't feel limited by smaller gaps of time. This is where a lot of my OSS work happens too, as those aren't usually large scale tasks.

Get it working first. Then optimize from there. Until I have a working (test) case, I have no idea if my changes work and likely to run in the wrong direction for too long. The first iteration of any solution is usually the stuff of technical interviewer nightmares. But it works!

Use magic cursors, replace in path, and structural replace. I use these all the time and they are refactoring superpowers. They're also exceptionally useful for hand-processing bulk data rather than trying to script it. Low effort, high reward.

Script migrations. Basic Kotlin scripting can do a lot of work in migrations for you. Not necessarily kscript even, just a simple scratch file or fun main() implementation usually suffices. It doesn't have to be precise, just enough to do most of the grunt work and let a human come through and clean up the rest. Low effort, high reward.

Don't keep thoughts in ephemeral places. This includes in my head. If I'm so far down the rabbit hole in a thought that I'm worried about losing it all with an interruption, I'm too deep. I can barely remember names, why would I try to keep complex logic in there? Scribble things into comments and notes quickly and often. You know what's a super dumb but super simple way to remember a relevant line of code? I set a breakpoint on it. Not because I'm going to hit it in the debugger, but rather just because that highlight's a reminder for me later. I have to leave breadcrumbs because otherwise I will absolutely forget it.

Put things down. This might feel obvious, but if I'm at a dead end on something then I'll just put it down for a bit. No reason to idle on something that's not clicking. The human mind operates on parallel tracks and even when something's on the back-burner, some part of your head'll still ponder it and come up with something later. If I'm on a time crunch and can't put it down for a few hours or a day, rubber duck debugging with a coworker for a few minutes is immensely helpful too.

Leave breadcrumbs. Related to the above two, but if I'm getting pulled away from something I was in the middle of then leaving a short note or few comments allows me to switch back on to it when I return. For me, this completely mitigates just about any interruption I get throughout the day.

Sleep is the best debugger. If I'm really stuck on something or not sure how to go about it, sleeping on it is the best tool.

Embrace the gaps. Not everyone can context-switch easily, but I 100% believe it's a skill that can be practiced and a lot of it is down to mentality. If I react to every interaction like it's ruined my day, every interruption is going to ruin my day. If I've comments/notes/breadcrumbs, I can easily pick up where I left off.

Misc

While not principles really, these are some other relevant details of how I work:

Closing

Some people are watchmakers, meticulously working on exactly one thing for days or weeks at a time until it's perfect. I am not a watchmaker. I'm more like a chef, preparing a number of dishes at once. Some are big, some are small, some are on the back burner, some are maybe boiling over. Sometimes all the burners are on and sometimes I'm not in the kitchen.

Everyone's different, but this works well for me. I hope this is at least interesting for some and maybe even helpful for others. Please don't take it as gospel or anything resembling blanket advice though! Do what works best for you, try different things, identify what slows you down, and try to improve it.


Thanks to Cli for proofreading this!