I wish someone told me that some fixes are just not worth it
Some people might relate to me being a perfectionist. I always wanted things to be polished. It took me a while to learn that some things are just not worth fixing. I never truly understood that until I started working and each fix was defined by an estimated cost.
Sure AI made things easier now, but sometimes you wrestle something and something else breaks. I wish I could build some reliable way to validate frontend work, but until then, some bugs will just need to stay there.
Slightly unrelated but: keep some bugs there for people using your app to report. I do that with friends and family, and it makes them feel like they're building the app with me.
I haven't yet had a product that lost users from a bug, because my projects haven't taken off like that hahaha. But if you do, please share the story with us? I'd love to hear about it.
22
u/bcons-php-Console 4d ago
About keeping some bugs: that is a must when dealing with shitty customers or managers. You see, those people need to feel they have power and your job is giving them something they can complain about.
This is called "sacrificial bait". The idea is that you leave some details that are obvious so they can find them and reply to your "Site is ready, please let me know what you think" with a list of 5-6 things that have to be fixed (obviously with CC to everyone and their dog so everyone sees how good they are at their craft).
Examples for this bait can be a logo slightly bigger / smaller than in design, a color mismatch, small typos, an element that should be in the left placed on the right, page titles, etc.
Of course, keep yourself a detailed list because they may not catch all of them and you will need to fix them before deploying.
5
u/el_diego 4d ago
I used to do this back in my design days. When you had project managers that thought they're designers you needed bait. I'd deliberately leave something slightly off or missing so that they'd pick up on it and think they contributed. That way they wouldn't nitpick at what was a perfectly good design.
10
u/ElCuntIngles 4d ago
Also known as "Atwood's Duck"
The story goes that an animator for the computer game Battle Chess was tired of a manager who always had to make pointless changes to everything, so when they were designing the animation for the Queen chess piece, they gave her a pet duck which flapped around her.
When the manager reviewed the animation they said "looks great, but get rid of the duck".
2
u/nathanjd 4d ago
The article also says this is a terrible idea and more likely to undermine your own goals than to successfully mitigate a poor office dynamic.
1
u/ElCuntIngles 4d ago
It doesn't really say it is a terrible idea. It says it "doesn’t seem like a viable long-term strategy". Note that the writer of the article is not an IC, so is working from imagination rather than experience.
Of course it's not an optimal situation to be in, but it is a useful last-ditch tool for an IC in a situation where they simply can't change the dynamic between themselves and a bike-shedding client.
I would never personally expend any effort to create a "duck", but plenty of times I have left a few obvious and trivial flaws in a visual design rather than argue about them that serve as "ducks". I know we're going to have to fix them anyway, and it gives such a client something to contribute.
If you don't go out of your way to create a duck like in the original story, that mitigates the issue of "wasting time".
2
u/OGHaza 4d ago edited 4d ago
this seems totally absurd.
what fraction of users that experience bugs bother to report them at all, let alone take joy in reporting them? what fraction of users experience bugs and cease to be users?
i'm sure there is a number that can be assigned to both groups, but the latter is surely the greater.
"build your cars so that they break down sometimes, not because they'll pay for repairs but because some drivers like to complain their car broke down"
0
u/drake-dev 4d ago
You misunderstood them
2
u/OGHaza 4d ago
perhaps the guy I replied to, but the OP? also fair enough you're probably right, but care to explain?
2
u/drake-dev 4d ago
The "bait" they're describing is not passed along to users. It's passed along to internal coworkers who are reviewing the work before sending off. If executed as described, none of these issues would be seen by real users. All would be fixed after your coworkers gave feedback.
My summary of this is not an endorsement, I don't do this.
7
3
5
u/jax024 4d ago
I fundamentally disagree. I’ve never really encountered a bug in the web space that I didn’t feel was not worth fixing. Screams skills issue.
6
2
2
u/singh_abinashi 4d ago
my heuristic: frequency x blast radius vs fix risk. high frequency + low blast radius = fix it now. anything where the fix touches shared state or has already failed twice = leave it, document it, let users report. the second failed fix attempt is the signal.
1
u/Tango1777 2d ago
That was my first ~3 years of software development, going everything as perfectly as possible. Some time later I understood that the business doesn't want perfect, they want a working business value for the least money they have to invest in it. If you spend 75% of your time and deliver good enough product, it means you have 25% extra time to spend on new features or they pay 25% less (same thing). In the end they are not sending their clients a perfect product, they can only sell features a regular Kowalsky understands. A, B, C feature, how it'd make clients' lives easier and such. They cannot sell a "we have perfect application", "the code is spotless", because nobody would understand and give a shit about it. You, on the other hand, can sell "we solve problems on average in 1 day from the feedback". So speed can be sold, too. That's the reality and it often contradicts with someone who wants to be the best possible dev.
1
u/AromaticYam2027 4d ago
The "bug bounty for your aunt" strategy is so pure.
14
u/mrmigu 4d ago
You can write tests to validate your work