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.
I'd highly recommend the Product Bakery podcast as set of great resources for learning more about how to develop great user interview/research skills, whether you work in Product or in design/development more directly.
I discovered the podcast after landing on Christian Strunk's blog (one of the hosts) and it's greatly improved my Product skills and mindset.
(I am in no way affiliated with the podcast and/or blog other than having found it very valuable).
For me, little annoyances really stack up and make the whole experience a pain. I prefer to not have a specific feature at all, but have a great experience on what works, that keep finding little things that annoy me
from your writing, it was very clear that design was your priority, whatever other skills you might also possess. so I feel a bit vindicated seeing your username.
Also relevant: beyond IQ and EQ is the concept of "CQ" or Cultural intelligence, which is even closer to the skillset you describe.
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!
Oh 100% this was a major revelation in my career going from hobbyist to professional gamedev. As a hobbyist I would think "Yeah sure the units are spinning randomly on corners because I messed up the rotation math, but I can fix that anytime. I should be working on this yet-another-feature".
When correct process is to fix the biggest pain point: and surprise! There you go, the next biggest pain point becomes obvious. Repeat ad intinitum and you'll have polished yourself a commercial-grade game.
Just thinking in what I need to do for this do "properly", ie: I plan to make a language as the base!(https://tablam.org).
Eventually I just install https://www.metabase.com and thanks to sane table + view design the end-users are nearly support-free.
Out of interest, did you use the Open Source version. Embedded or standalone?
A couple of folks hacked together an Excel plugin that could make those data changes in bulk. Voila! Customers loved it!
The amount of happy customers we got for that weekend project was overwhelming.
But in the early stages - I agree with you and tend to take the view that it's better to just throw something together and get it out there and being used quickly - irrespective of how bad the code might be underneath.
Get the system out in front of users, and delivering value to them as quickly as possible. You cannot beat the power of getting early feedback and validation of a concept.
For larger (higher stakes) projects this can be in the form of a "prototype" where the expectation is set that it's not a complete product. For smaller projects, fuck it, call it Version 1 (or a "beta" if you must) and get real people using it quickly :-)
Just be prepared to continue iterating from there.
As a dev I also often fall into the trap of "coding for coding's sake" - I love TDD, DDD, clean code, getting the right abstractions... and yes this stuff (when used appropriately) can lead to good maintainable code with low tech debt and easier feature development... but too often as developers we can end up losing sight of the business need and go too far up our own backsides with this stuff. Perfecting the codebase in the name of maintainability and controlling tech debt, when really it's often unnecessary perfectionism - or premature optimisation at least. Maybe that's just my own experience and I'm projecting - but I do see this quite often with even the best devs I work with. Actually more often with the devs that take the most pride in their work. It's a difficult balance to strike.
Totally agree. A brilliant piece of wisdom!
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 mindset and writing style "I'm humbled that such a small change could help so many :)" is far more engaging than the writing style "so much fanfare for THAT, that was obvious I saw that ages ago because I'm not dumb".
I think that's entirely the point he's making! :-)
> I constantly fail at this game.
The best way to get better at the game is to know you have a blind spot. Once you do, then you can come with strategies to work around it. It takes quite a bit of work, especially at first - but like most skills, the more you make the effort to practice them, the less effort and easier they get to accomplish over time.
Whenever I am writing anything explanatory out now, I force myself to step back, and re-read it out loud as if I was reading it to a family member with zero familiarity of the subject. It's pretty effective :) Feels very weird at first, but actually physically reading it out loud is key - forces your brain to process it and not take mental short cuts.
First of all 10x on 10x is doing 9x the work the original team did
Presuming the team sorted the effort-reward ratio tasks, the only things left in the project will be harder than the first team tackled.
If people disagree on where a thing should sit in the matrix then a productive discussion usually ensues. If a thing is really valuable and really hard, we break it into smaller pieces. If someone's pet project is lower value than other easier things, we deprioritize it with no hard feelings.
It's crazy to me that the effort/value matrix is not a core part of tools like JIRA/Trello. Subtask does a pretty good job with this though.
I recently finished "Tiny Habits: The Small Changes That Change Everything" by BJ Fogg , 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!
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.
For what it's worth, it came from the fact that you were doing `git diff master...feature-branch`
Totally agree with you that the coding time is likely a tiny part of the total time spent. Tiny wins are hard to find.
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
If the PM is clueless about tiny wins for the customer you should find a new PM. That's basically the crux of their job.
It is an amazing tool in general. Together with Alfred these are the two main apps that I use all the time.
My particular project had a simple web UI, and all the PM wanted was a feedback link added, and he was frustrated that it wasn't there yet. Although this was trivial and not critical at all to the application, I made sure to get that link up on the page - it was nothing more than a link to a feedback form or a mailto:, it was basic.
Anyway, the PM was super happy when that link showed up. It definitely wasn't because this was some whizbang new feature, or scratching some itch that had been annoying a lot of people. It was because the team showed that we were listening and responsive to him. That's a win, too.
In reality, failure should be normal, expected, and even desired, because if you're not failing, you're not trying new things or taking risks. You should lose sometimes. But success is preferred to failure, so I would prefer to get Tiny Successes through Tiny Improvements.
> Nit-pick: I don't like the language of Successes [versus failures]. I get that people like short words that are associated with happiness and winning, but the underlying messaging are that if we're not succeeding, we're failing, or that we "have to succeed".
In this context:
- Sports competitions have winners and losers, but arguably no failures. Silver and bronze are certainly not failures. The lost first place, but won second. Lost second but won third. Etc. Last place could easily have been competing against themselves.
- Grants/Charity Competitions have winners and non-winners. I would argue neither failures or losers.
Lots of nuance, but my point is that it seems like you have a bias that makes you prefer success/failure vs winning/losing.
I'd rather say the opposite: impact can indeed be measured by number of likes; it shouldn't always, but it often is a good first indicator. Personal worth never can nor should.
Tiny wins got me to switch to MacOS and never look back.
Edit: I know this is sort of off topic, but it’s similar to being able to see the build status from the favicon.
Depends a lot on how you define "impact" at the end of the day. Did such measures make GitHub preferable over other platforms? It's not obvious.
It's easy to mistake the visibility of solving an issue with its impact. Sometimes they have no impact at all yet they seem important.
As a standalone feature there's no significant impact, but changes like these can gradually improve the user experience until they become greater than the sum of their parts.
Simple fixes for pain points will appear magically :)
is something to cultivate, probably the most important factor in my not so experienced eyes