Tiny Wins

The ideas here are: pay close attention to your user's actual experience with your product; nuanced experience fixes can have big collateral benefits; there's a way to do that in the context of everything else. All good, from my perspective.

The caveat is that the author in this case is not that different from his users, who are other devs. He gets their experiences. The magic trick for dev is putting yourself in your user's experience when they really don't think like you. Non technical, kids, accountants, whatever. You really have to drop your assumptions and forget your investments and just see things the way they do. Empathy rules, but I feel it is hard to codify that as a skill. There's a big leap before tiny wins.

EDIT- to add, the signals to look at first are user complaints, and user's efficiency on tasks with your product, aka usability studies. Empathy informs your takeways from that.

One of the dev failure modes I regularly see when consulting (and have fallen into myself, many times) is believing value is a function of effort spent coding. More of the latter means more of the former.

But it turns out customers don’t care how long you took to build the thing. At all.

There’s a lot of win in finding and plucking low hanging fruit - those high leverage features that seem almost too easy to do that you can do them anytime... but never get around to because you’re always working on something bigger and more interesting.

Related to this if OP is reading, I’d love to be able to drag and drop and upload images into GitHub wikis the way I can into GitHub Images. Between those two changes and uploading to wikis you’d have my vote for employee of the month!

While this article focuses on a niche, tiny wins are a universally applicable concept. I think they are a powerful abstraction.

I recently finished "Tiny Habits: The Small Changes That Change Everything" by BJ Fogg [1], which talks about this in generality. The essence is that behaviors are a product of motivation, ability, and prompts. By keeping things tiny, we avoid the need of very high motivation, the need for very high ability, and devise easy triggers/prompts to get work done. It has been quite fun to identify tiny habits in my daily routine, I've collected quite a few and narrowed down on what works and what doesn't.

This is then applicable to software engineering, product development etc. One of Instagram's co-founder was apparently enrolled in the author's class, and therefore pops up as an example a few times through the book.

I've always ridiculed self-help books. This book does have a self-help flavor, but always concludes with precise actionable advice. By developing a general framework and a mental model around habits (think abstraction in usual software engineering terms), it does feel more controllable. Highly recommended!

[1]: https://www.librarything.com/work/23220746/book/198725553

I'm always impressed by people who are top dogs at self-promotion. These are small projects, small changes, but presented as best as they could, with as much fanfare and congratulations as can be achieved.

I mean, an arrow for data flow direction? It sure is better than a non-descript triple dots, but was it that non-obvious? The mileage he gets from this small change in this blog post is remarkable.

I constantly fail at this game.

The lack of arrow in the merge direction page was baffling (given that IIRC elsewhere lines were used to indicate change direction). Glad they fixed it.

What's missing in this article in talking about how little time the changes took ("This was a one-line code change that took a few minutes.") is if there was much consultation with designers/management/UX-people involved, and much testing needed after.

Totally agree - you can either spot those yourself by putting yourself as a user or listening to your customers. The other challenge is to get those tiny wins into the sprint when your PM can be clueless about the ROI on those..

While we're on the subject, if someone from Mac OS can please seperate my trackpad and mouse settings so the scroll natural/reverse is kept between for each device, that'd be appreciated

The similarity to the Eisenhower Matrix for task scheduling is apparent. The two of them would pair nicely in a discussion.

https://www.eisenhower.me/eisenhower-matrix/

Another blog post from GitHub on “paper cuts”: https://github.blog/2018-08-28-announcing-paper-cuts/