Do That Which Makes Your Life Easy

I have long been a fan of DHH and 37signals’ var­i­ous tech­ni­cal and so­cial ac­com­plish­ments. With a rel­a­tively small team, they have laid the foun­da­tion for a num­ber of suc­cess­ful com­pa­nies and main­tained a com­mu­nity of ex­tremely in­tel­li­gent en­gi­neers who work with it. I have long fol­lowed their work and have found a wealth of suc­cess ap­ply­ing their ad­vice to my own prac­tice.

I re­cently read Getting Real, which was the first pub­lished book con­tain­ing their ad­vice for build­ing a suc­cess­ful SaaS com­pany. I no­ticed that, through­out all of their writ­ten work, all the ad­vice Jason Fried and DHH give have a deeply per­sonal idea baked into them. What­ever you do while build­ing your busi­ness (or ap­pli­ca­tion), do it while set­ting your­self up to have a good qual­ity of life.

My goal in writ­ing this post is not to pro­pose an ap­peal to au­thor­ity. My goal is to come to an idea of why it might work well to make de­ci­sions (while build­ing or main­tain­ing soft­ware) in the in­ter­est of your qual­ity of life. In other words, if you come to a fork in the road where a de­ci­sion must be made be­tween two or more op­tions, you can of­ten safely choose the one that sup­ports your own (selfish) de­sire to im­prove your qual­ity of life.

In an older post, I pro­posed an­other kind of men­tal short­cut. When you imag­ine your­self on the path to be­ing the kind of per­son you most ad­mire, it’s found (and this is sup­ported by a num­ber of psy­cho­an­a­lysts I have spo­ken to) that you tend to be­come that per­son, al­most by ac­ci­dent. The ex­am­ple I of­fered was my own: When I must make a de­ci­sion, I try to imag­ine what “the most ef­fec­tive en­gi­neer” would do.

This men­tal short­cut — choos­ing the op­tion that im­proves your qual­ity of life — can be used in tan­dem with that other short­cut.

Dogfooding

Eating your own dog­food is per­haps the most ob­vi­ous ex­am­ple of this idea of im­prov­ing one’s own qual­ity of life. When you are re­quired — by force of will, or by ne­ces­sity — use your own prod­uct, the in­cen­tives align strongly to­wards mak­ing it bet­ter. If you make a change, and it im­proves the qual­ity of your own life, it’s quite likely it will also im­prove the lives of your pre­sent and fu­ture users.

The ob­vi­ous place dog­food­ing helps is in the search for bugs. If you use your own soft­ware, you re­ceive a rep­re­sen­ta­tive sam­ple of what the ex­pe­ri­ence is like for the av­er­age user who con­sumes your prod­uct. If you en­counter an ob­vi­ous bug, you can guar­an­tee that your users have seen it too.

Which Feature Is Best?

When work­ing on a new fea­ture or ca­pa­bil­ity, it is al­most al­ways bet­ter to pri­or­i­tize the one that will most tan­gi­bly help you.

For me, this meant mak­ing Harper avail­able in Discord. At the time, I was al­ready us­ing Harper a TON in GitHub, and I had grown used to typ­ing out a messy mes­sage fast and hit­ting Ctrl+E to fix all my mis­takes. This let me write code re­views faster, but I felt frus­trated when­ever I needed to col­lab­o­rate with a fel­low main­tainer in Discord, since I had to type slower and fix my mis­takes man­u­ally. By adding Harper to Discord, I make my own qual­ity of life bet­ter and in­tro­duced a core ca­pa­bil­ity to my prod­uct that opened up a new mar­ket for po­ten­tial users.

Indirectly Helping Your Users

There are a wealth of sit­u­a­tions where the de­ci­sion to im­prove your qual­ity of life is cor­rect, even if it does not di­rectly im­prove the prod­uct ex­pe­ri­ence for your users.

Consider your con­tin­u­ous in­te­gra­tion (if you have it). It may take a few min­utes to com­plete, or it may take a few hours. In ei­ther case, you prob­a­bly do not like wait­ing for it to run. Per­haps it has been de­manded that you de­cide whether to (A) add a new highly-re­quested fea­ture your prod­uct, or to (B) spend some time speed­ing up your con­tin­ues in­te­gra­tion.

If you do not think that speed­ing up your con­tin­u­ous in­te­gra­tion will im­prove your qual­ity of life, I sug­gest that you add the fea­ture in­stead (option A). I have ob­served this is rarely the case. I have found that most en­gi­neers spend a non­triv­ial amount of their time sit­ting at their desk, wait­ing for their GitHub Actions work­flow to com­plete so they can free up men­tal space to work on other things. If you have had that ex­pe­ri­ence, speed­ing up your con­tin­u­ous in­te­gra­tion (or even re­mov­ing it!) might be the bet­ter choice.

The frus­tra­tion of wait­ing for this thing to fin­ish is pal­pa­ble for a rea­son: It is slow­ing every­thing down! Re­mov­ing it as a con­straint will al­low you to get more done, faster, bet­ter, and you will be hap­pier as a re­sult. What is there to com­plain about?!

Still Use Your Brain

No mat­ter how many blan­ket rules I or even the folks at 37signals throw at you, please use your brain. Each de­ci­sion should be con­sid­ered with the ef­fort it de­serves. Some­times a men­tal short­cut is enough, and other times you need to but some real gray mat­ter to work. De­vel­op­ing judg­ment for which sit­u­a­tion is which is a dif­fi­cult, but ex­tremely valu­able, skill.