Ben Kuhn Profile picture
17 Mar, 10 tweets, 2 min read
People ask me for a lot of advice on what to do about technical debt. Here some things I’ve learned about how and when to prioritize fixing bad code:
1. Distinguish global vs local problems.

Local problems are things like a poorly-implemented module—it slows you down if working on that module, but is fine otherwise. Global problems are things like “we use database transactions wrong” that infect everything.
2. Fix local problems the next time they get in your way.

(i.e. trust that they’ll get solved eventually by a “make the change easy, then make the easy change” process.) Leave TODOs in the code, deprecate methods, etc. as breadcrumbs for anyone else who might want to fix.
3. For global problems, rank by: how fast is it getting worse? (How high-interest is the debt?)

Agree on a time budget (e.g. X% of eng time). Spend that time going down the list in order.

It’s ok to temporarily be over/under budget, as long as it evens out over time.
4. Decouple “stop the bleeding” from “fix everything.”

You can often solve the “gets worse over time” / “causes ongoing pain” parts much more cheaply than fully fixing the problem. Look for these opportunities; they’re great ways to get more leverage out of your time budget.
Wave example: we had a bunch of badly-written unit tests. Instead of rewriting them all at once, we started a second unit test suite with better infra + conventions and set a rule “all new tests go in the new suite.” Then we gradually ported old tests as needed.
At some point you do actually need to finish these migrations, otherwise they impose a confusion tax on everyone forever. But if you fix the bleeding asap first, you’ll lose a lot less blood overall :)
5. For global problems, spend more time than you think on “thinking real hard:” benkuhn.net/thinkrealhard/

The days you spend on design will determine the outcome of weeks/months of migration effort, so the leverage of additional (productive) hard thinking up front is high.
Two other corollaries:
1. The trickiest part of fixing a global problem is the migration path. This often ends up being the main thing my designs solve for.
2. The most important skill for fixing tech debt is being good at extrapolating the consequences of your design decisions.
Ultimately, of course, avoiding bad code comes down to thinking carefully and putting in the work. But the above framework helps me focus my attention on the few most important problems, without being distracted and overwhelmed by the massive space of potential things to do!

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Ben Kuhn

Ben Kuhn Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @benskuhn

26 Mar
This is another great takeaway from last thread, which I *should* have learned from changing jobs, but actually took ~20 more cycles on the motivation roller coaster to realize.

For me, bad focus was ~always a response to circumstances, even when I wasn't consciously aware!
My first years at Wave, I repeated variants of the following ~monthly:
- notice I'm stressed/unfocused
- "huh, having an off day"
- go climbing, read books, etc.
- still stressed
- gripe to boss eg "accounting sucks"
- boss helps fix accounting problem
- ✨happiness returns✨
Eventually I started interpreting stress/unfocus as a sign, not that I was having a bad day, but that I was working ineffectively or on the wrong thing. Eg, I'd know I needed to be hiring faster, but kept getting distracted by other, less important, more urgent projects.
Read 6 tweets
24 Mar
One thing that surprised me when I switched plans from "earn lots of $ and donate" to "build important things," is how much more productive I became.

I thought if I was earning the $ by doing intellectually interesting work I'd stay motivated. Turned out that wasn't true!
Actually, it was even worse—I *thought* I was motivated while I was doing plan A, and only when I switched did I even realize *how motivated it was possible to be.*

Several friends had this experience as well. Makes me wonder how many people are stuck in that state.
(For example, I never thought I'd be pumped enough about work to live for 1+ yr in a country where I didn't speak the language! Or to have the stamina to spend 20+hr/wk on the phone with an accounting firm. Or etc.)
Read 11 tweets
16 Feb
I just finished *Creative Selection* by Ken Kocienda, which is largely the story of how he came to build the iPhone keyboard.

It’s a great example of how many twists and turns it can take to come up with something that seems so incredibly normal!

v1 started out looking like...
some wacko phone-keypad variant, because the developers were super worried about touch targets being small. The input method for this was: tap to get the top letter, swipe left/right to get the bottom letters.
Except instead of the letters being organized like a phone keyboard, they’re jumbled up. (Presumably to make sure that common letters were taps, not swipes? But that plus the gestures seems impossible to learn.)
Read 16 tweets
15 Feb
People sometimes ask me whether Wave has any plans involving crypto, presumably because of the narrative that crypto is supposed to help with financial inclusion.

Unfortunately, in reality it doesn’t and we don’t. Crypto does not solve any hard financial inclusion problems.
Wave needs to solve, roughly, 3 problems in order to financially include someone:
1. track their balance
2. comply with regulations
3. convert balance to/from cash

Crypto is a very exciting solution to 1, but Postgres is a boring solution to 1 that is much faster.
People sometimes think crypto helps with 2, because it’s *technically* not currency. This is... not a great assumption about how governments/regulators work. It turns out that if you follow the letter but not the spirit of the rules, people eventually notice and tell you to stop.
Read 8 tweets
10 Jan
It feels like every couple days, I learn a new Git trick. (Sigh.)

I'm going to start a running thread indexing them, because (Git's defaults are so bad that) some of them are pretty big quality of life improvements!
A fun one I noticed recently is that they added `git switch <branch>` as a more intuitive replacement for checkout. Extra fun: `switch -m` moves your uncommitted changes (no more `stash/pop` dance!). Hoping this is a sign of more UI improvements to come!
Maybe my favorite: `git log --first-parent` shows history but *only merge commits*. Even if your repo doesn't squash-merge, this still gives a clean view of your history. A former coworker liked (our use of) this so much he wrote an explainer: …om.s3-website-us-east-1.amazonaws.com
Read 18 tweets
15 Dec 20
Happy @threadapalooza! 100 (tweet-sized chunks of) stories from trying to build mobile money in Ethiopia, Ghana, Nigeria, Senegal and Cote d’Ivoire.

(Minus the ones I’m not supposed to talk about :P)

It all starts in ~Sep 2015 with me pretending to be an accountant.
“Huh?” It turns out doing the accounting for an international money transfer business is hard. There is a normal way of doing this, but instead of trying to find out what that was, we were like, “this seems like it should be 100% automated! We’ll just do that.”

LOL
(This was part of our general take that hiring was for chumps, instead we’d scale ourselves by building internal tools)

So that’s how I ended up closing Wave’s 2015 books by spelunking through a homegrown database for 3mo with handwritten SQL and a half-baked Flask-Admin UI.
Read 69 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!