Re: Collaboration Sucks

Earlier this week, I came across a re­ally great post from a prod­uct en­gi­neer over at PostHog. If you haven’t al­ready, I highly rec­om­mend read­ing it. With the ti­tle “Collaboration sucks,” I think it makes its mes­sage clear.

If you had shown this ar­ti­cle to the Elijah Potter from a year ago, he would have agreed with most of what it says. I was of the strong opin­ion that col­lab­o­ra­tion was fun­da­men­tally coun­ter­pro­duc­tive to get­ting sh*t done. Since then, I’ve com­pletely changed my tune. While I don’t be­lieve col­lab­o­ra­tion is the se­cret weapon my pro­fes­sors in school made it out to be, I think it’s es­sen­tial to work­ing on am­bi­tious pro­jects for a long time with­out burn­ing out. Furthermore, at least for open source pro­jects, I think it’s crit­i­cal for pri­or­i­ti­za­tion of work.

First, let’s get some­thing out of the way. Although the post ti­tle de­clared that col­lab­o­ra­tion in any form was bad, the meat and pota­toes of the post have a slightly dif­fer­ent tune. He merely said that it is­n’t that col­lab­o­ra­tion is bad, just that too much col­lab­o­ra­tion is bad. I can get be­hind this, but I still think there’s more nu­ance lurk­ing in the shad­ows.

I think Cook’s post out­lines many of the var­i­ous ways col­lab­o­ra­tion can go wrong. I par­tic­u­larly en­joy the red flag ex­am­ples he pro­vides. I’d like to pro­vide some ex­am­ples of col­lab­o­ra­tion go­ing right.

Since all of this is strictly re­lated to Harper, it’s pos­si­ble that both these ex­am­ples are only help­ful to open source pro­jects.

It Boosts Motivation

When I go a lit­tle bit too long with­out en­gag­ing with a mem­ber of the Harper user base, I start to feel a bit de­flated. I start to for­get who it is all for.

As a part of my own writ­ing en­vi­ron­ment, Harper ex­ists to make writ­ing more fun and more hu­man. I can think crit­i­cally about my mes­sage while spend­ing less time wor­ry­ing about gram­mar or punc­tu­a­tion. For oth­ers, it poses to do all that with­out vi­o­lat­ing their pri­vacy. It’s great to hear from them, and how we can make our ser­vice even bet­ter.

I know I’m do­ing some­thing right when I’m act­ing as cus­tomer sup­port and read a mes­sage like this. I feel em­pow­ered. Not only do I know what I am do­ing right, I feel highly mo­ti­vated to keep do­ing that thing.

In Open Source, Your Collaborators Are Also Your Users

When work­ing on open source soft­ware, es­pe­cially one that val­ues pri­vacy, clearly stat­ing a pol­icy of be­ing friendly to pull re­quests is ob­vi­ously crit­i­cal. For one, it makes it clear that bug fixes are wel­come and will be swiftly re­viewed. Less ob­vi­ous is the feed­back re­sid­ing within the pull re­quest.

Here’s an ex­am­ple. A user en­coun­tered an is­sue re­sult­ing from a change in Obsidian’s API. Not only did he take the time to re­port the prob­lem, he also went through the ef­fort of im­ple­ment­ing a fix. What does this tell us?

For one, it gives us an idea of where our doc­u­men­ta­tion is suf­fi­cient. He was able to find the in­for­ma­tion needed to build the code and run it on his own ma­chine. In the fu­ture, we don’t need to pri­or­i­tize the Obsidian plug­in’s doc­u­men­ta­tion.

More im­por­tantly, how­ever, is the fact that the fea­ture was valu­able enough for this user to spend time fix­ing it. If it is valu­able for him, we can safely say that it is valu­able for other users. Now that I have suf­fi­cient ev­i­dence, I might con­sider bring­ing sim­i­lar func­tion­al­ity to other plat­forms, like our Chrome ex­ten­sion.

Collaborating in an open source con­text can be hugely in­for­ma­tive, since your col­lab­o­ra­tors are also your users. In my ex­pe­ri­ence, this is sur­pris­ingly un­com­mon, even in com­pa­nies that claim to have a cul­ture of feed­back.

There Is Still Such a Thing As Too Much

While I’ve found these par­tic­u­lar cases to be pro­duc­tiv­ity-boost­ers, I un­der­stand that fo­cus­ing too much on any one thing can be detri­men­tal. First and fore­most, the goal should be to ship as high a qual­ity of soft­ware as pos­si­ble, as soon as pos­si­ble.