Hacker Neue

Preferences
JohnMakin parent
This just sounds like perfectionism. I believe it is a curse, because I hate working with teammates like this. They'll spin their wheels solving some insane problem no one asked them to do because it's "better" while ignoring the larger scope and goals of the project. I've tried to coach people out of this mindset, because I used to have it very early in my career, til I realized the sheer impracticality of it.

I use this really annoying, poorly supported terraform provider. I've written a wrapper around it to make it "work" but it has annoyances I know I can go to that repository and try to submit a patch for it to fix my annoyance. But why? This is "good enough," and IME, if you sit on things like this long enough, eventually someone else comes along and does it. Is that a good attitude for everyone to have? Probably not, but now it's been a few years of using this wrapper module, I have 2-3 viable alternatives now that didn't exist before that I can switch to if needed.

I could've turned it into a several week project if I wanted, but why? What purpose does it serve? As you grow, you realize there is very rarely, if ever, a "right" answer to a problem. Consider the way you think it should be done is not the only "right" way and you'll open more doors for yourself.

bigstrat2003
Like most things in life, there's a balance to be struck. If you always accept "good enough" and move on, things will be low-key crappy forever and never get to the point where they are actually good. If you never accept "good enough" and move on, you will never get anything useful done because you're going to always find some "one last thing" to polish. The best path is to pursue excellence when you can, but accept that sometimes you have to let things go.
fragmede
There's a difference between picking up on some esoteric detail.in your company's product and making it your only mission to solve it, ok the detriment of everything else vs taking Friday afternoons for a month to fix a Terraform provider for the world. There are two kinds of lazy. The kind that makes us good programmers and the kind that makes us bad programmers. If you're gonna be the second kind of lazy and just wait for someone else to do it for you, you might as well become a manager at work and take credit for their work while you're at it.
JohnMakin OP
It's not laziness though. I have dozens of competing priorities at any time. It is far from the most efficient use of my limited resources and time (and company time) to spend on a project that does not need doing that will inevitably be done by someone else anyway. It provides no business value whatsoever either. It's not "taking credit" for anything unless you count using anything open sourced as "taking credit" for the work done on that project. Yes I use jq, no I do not take credit for writing/maintaining it. Do you see the difference?
fragmede
In the abstract, fixing the root problem >>> maintaining a shitty internal wrapper that has to get reworked every time upstream gets fixed. Not fixing the wrapper repeated is absolutely business value, because not having a half assed fix of an implementation means fewer bugs in terraform plan and apply, which means less time messing about with CI because the stupid thing broke again.

This is of course in the abstract. I know neither the quality of the wrapper you wrote, nor how long it would take you to do clone a repo and write some code for any upstream fix, given all of your competing priorities.

My underlying point is that not fixing things properly has a cost all its own, and wasting time with a half assed solution can cost more than is immediately obvious.

It's impossible to say in the abstract if it is more efficient to actually fix the root problem and be of more business value vs shitting out some wrapper script, it depends on the downstream effects of said wrapper. But I've definitely avoided doing an upstream fix and wasted countless company resources getting a wrapper working when I could have rolled up my sleeves, done said upstream fix a year or two earlier and overall saved the company money.

matheusmoreira
> I hate working with teammates like this.

> They'll spin their wheels solving some insane problem no one asked them to do because it's "better" while ignoring the larger scope and goals of the project.

> But why? This is "good enough," and IME, if you sit on things like this long enough, eventually someone else comes along and does it.

Can't think of a bigger reason to avoid volunteer work on free and open source software than what you just said. Being a "wheel spinner" who cares too much about stuff is foolishness. People hate you and simultaneously take you for granted.

Gracana
I feel like Open Source is the perfect place to apply that sort of effort. Also hobbies. You don't owe anyone anything, so you can chew on a problem just as long as you like.
matheusmoreira
Open source just means you're being taken advantage of. You're working for free to make the lives of people who look down on you easier. They won't do it themselves, their time is too valuable for this worthless nonsense. Better to leave things as is until some unpaid perfectionist can't stand it anymore and fixes it free of charge.

Never forget the words of Zed.

https://web.archive.org/web/20120620103603/http://zedshaw.co...

> Why I (A/L)GPL

> I would actually rather nobody use my software than be in a situation where everyone is using my gear and nobody is admitting it.

> Or worse, everyone is using it, and at the same time saying I can’t code.

> I want people to appreciate the work I’ve done and the value of what I’ve made.

> Not pass on by waving “sucker” as they drive their fancy cars.

If you're gonna go down this route, don't ever do "open source", do free software. AGPLv3 on everything. No exceptions.

JohnMakin OP
I really disagree with what reads like a snide shot at the original post. I'm not saying wait around for some perfectionist to do it, I'm talking about practical considerations in a fast paced and resource constrained environment, something probably many people run into all the time. I'm also not talking about poaching some single maintainer-in-a-garage's pet project and using it for my own needs. I'm talking terraform providers, which are often contributed to by very, very large companies with deep pockets and resources to do so, which is in their interest, because they want it to be easier to use their products.

I also contribute to OpenTofu whenever possible. I work for myself and don't have the resources as the companies that contribute to these projects.

rustyminnow
I submitted a patch for an annoying terraform provider once. It took about a week to fix and almost 3 years for them to merge it upstream. I got to learn Go and gained a much more solid understanding of how terraform works. I gained more from undertaking the project than from the actual fix.

> Consider the way you think it should be done is not the only "right" way and you'll open more doors for yourself.

Absolutely.

JohnMakin OP
Had this exact experience and why I don't bother anymore and fork if it's absolutely necessary.
3minus1
Most people automate things just barely enough to work. The thing is, having a barely working script or process can save someone thousands of hours. It's actually hugely valuable. Trying to make it more robust/productionized/whatever may have diminishing returns.
eviks
> submit a patch for it to fix my annoyance. But why?

To not be annoyed? How is that not a worthy goal in itself?

ag101
i really agree with this

This item has no comments currently.