[HN Gopher] Tiny Wins
___________________________________________________________________
Tiny Wins
Author : tosh
Score : 263 points
Date : 2021-05-02 10:22 UTC (1 days ago)
(HTM) web link (joelcalifa.com)
(TXT) w3m dump (joelcalifa.com)
| jtbayly wrote:
| I'd like to see which of my organization's projects are currently
| failing their GHA build. Does anybody know how I can do this
| without clicking in to every single project?
|
| Edit: I know this is sort of off topic, but it's similar to being
| able to see the build status from the favicon.
| catchmeifyoucan wrote:
| Another blog post from GitHub on "paper cuts":
| https://github.blog/2018-08-28-announcing-paper-cuts/
| jodrellblank wrote:
| Canonical's Ubuntu "paper cuts" project from 2009
| https://ubuntu.com/blog/paper-cuts-need-you
| troelsSteegin wrote:
| 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.
| chrisweekly wrote:
| +1 Insightful.
|
| Also relevant: beyond IQ and EQ is the concept of "CQ" or
| Cultural intelligence, which is even closer to the skillset you
| describe.
| FalconSensei wrote:
| > nuanced experience fixes can have big collateral benefits
|
| 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
| agumonkey wrote:
| Basically go see your users. I've seen countless instances
| where a 2 min walk in an office would have changed a whole
| service life (and even a whole population by ripple effect).
| tessierashpool wrote:
| Good summary, but he's not a dev, he's a designer.
| finiteseries wrote:
| Like many designers these days, they're absolutely a
| developer too. Look at their past work!
| design wrote:
| I'm definitely a designer first, so I see things through a
| design lens. But I think that taking the time to truly
| understand your users as best you can--whether you're a
| designer, developer, PM, support, sales, etc--is the first
| step to building a good product and being able to identify
| these high impact areas.
| cestith wrote:
| 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/
| jan_Inkepa wrote:
| 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.
| lkbm wrote:
| > The lack of arrow in the merge direction page was baffling
|
| 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.
| computronus wrote:
| Sometimes a tiny win can satisfy just one crucial customer. Once
| upon a time I joined a contractor development team with a
| strained relationship with their customer PM who a) represented
| the project to the wider organization and b) controlled the purse
| strings. This PM felt like the dev team wasn't listening enough
| to him or delivering enough.
|
| 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.
| gpvos wrote:
| _> That's not to say that impact can or should be measured by the
| number of likes received (unlike, say, personal worth)._
|
| 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.
| jbkkd wrote:
| He was probably being cynical on the "personal worth" addition.
| activatedgeek wrote:
| 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
| pierrebai wrote:
| 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.
| EricE wrote:
| It's called the curse of knowledge :)
| https://en.wikipedia.org/wiki/Curse_of_knowledge
|
| 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.
| tailspin2019 wrote:
| > The mileage he gets from this small change in this blog post
| is remarkable.
|
| I think that's entirely the point he's making! :-)
|
| > I constantly fail at this game.
|
| Me too.
| jodrellblank wrote:
| To me your comment reads as scornful rather than impressed;
| that you think he is milking something undeservingly and self-
| servingly.
|
| 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".
| HeyLaughingBoy wrote:
| It becomes much easier if you can see things through the user's
| eyes. Then you realize that the tiny change you made is worth
| talking about because it substantially improves the users'
| lives.
| kareemm wrote:
| 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!
| Danieru wrote:
| > 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
|
| 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.
| mamcx wrote:
| In my niche this is reporting. We agonize for YEARS about what
| to do.
|
| 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.
| tailspin2019 wrote:
| Thanks for Metabase... never seen that before, and looks like
| it could solve a similar reporting hole in my current
| project.
|
| Out of interest, did you use the Open Source version.
| Embedded or standalone?
| findjashua wrote:
| did you try apache superset? if so, any reason you went w
| metabase?
| BCM43 wrote:
| Have recently tried both, my guess is the "sane table +
| view design the end-users are nearly support-free" is key.
| Superset is way way more complicated and hard to understand
| IMO.
| tailspin2019 wrote:
| > 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.
|
| Totally agree. A brilliant piece of wisdom!
| debarshri wrote:
| Also, just to add to that, customer also doesn't care about
| your code quality or the fancy new tech you used underneath. In
| early stage, it is all about getting stuff done fast, creating
| value, capturing value and repeat.
| tailspin2019 wrote:
| I agree with this, with your caveat of "early stage". Later
| on we have a responsibility to keep tech debt under control
| to a degree, even if that's invisible to the customer. (The
| side effect of faster development pace and higher quality
| later down the line will certainly be visible).
|
| 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.
| notatoad wrote:
| the customer doesn't care about your code quality or tech
| stack, until you're unable to do something like replace an
| ellipsis with an arrow because your tech debt has become too
| large.
| afarrell wrote:
| The business does however care about the marginal cost of
| delivering new feature improvements.
|
| https://youtu.be/TQ9rng6YFeY
| WJW wrote:
| And of course, the devs often care about using new tech
| since it improves both their current enjoyment of the job
| and (often) their future job prospects
| debarshri wrote:
| If you have a stable team, cost of delivering new features
| are quite low. Tech improvement comes at much larger cost.
| lazyasciiart wrote:
| Technical debt is the concept that some features of your
| existing product can actually make it harder to deliver
| new features. When to address technical debt is quite
| literally the decision on when tech improvement will be
| more valuable than the next new feature.
| itsrajju wrote:
| Completely agree! Long ago I worked at a fintech startup that
| made a Master Data Management (MDM) solution for hedge funds.
| Usually people would log into the webapp, make changes to the
| data, and log out. Do it 10 times and it starts to get boring.
|
| 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.
| robotresearcher wrote:
| These can be good new employee startup projects. Once around
| the dev cycle but not too complex. Early win, happy engineer.
| throwaway823882 wrote:
| Nit-pick: I don't like the language of wins [versus losses]. I
| get that people like short words that are associated with
| happiness and success, but the underlying messaging are that if
| we're not winning, we're losing, or that we "have to win".
|
| 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_.
| michael1999 wrote:
| Kaizen + Genchi Genbutsu. TPS is so valuable.
| hamhamed wrote:
| 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
| machello13 wrote:
| You may find this application useful:
| https://pilotmoon.com/scrollreverser/
| MH15 wrote:
| It's so annoying when I have to open Logi Options everytime I
| want to use a physical mouse to get the scroll going right.
| kareemm wrote:
| > The other challenge is to get those tiny wins into the sprint
| when your PM can be clueless about the ROI on those.
|
| 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.
| agumonkey wrote:
| > low effort high impact
|
| is something to cultivate, probably the most important factor in
| my not so experienced eyes
| nicoburns wrote:
| This is the true spirit of UX. Thinking about how best you can
| improve the _user 's experience_. Like many things, the meaning
| of the term has been diluted over time, but in this sense it's
| truly a beautiful thing.
| ekianjo wrote:
| > That's not to say that impact can or should be measured by the
| number of likes received (unlike, say, personal worth). But the
| individual responses tell a story of how meaningful even the
| smallest tweak can be to your users.
|
| 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.
| antasvara wrote:
| Small wins like this aren't often the reason for someone
| switching, but they can absolutely affect customer retention.
| Removing small frustrations can help to avoid users leaving
| your product, or be the boost needed to bump someone up to a
| paid plan.
|
| 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.
| EricE wrote:
| Yup - friction. Those who figure out how to reduce or
| eliminate it become fabulously wealthy (/waves at Apple).
___________________________________________________________________
(page generated 2021-05-03 23:01 UTC)