Live data from Hacker News

Do you ever avoid submitting something on HN so devs won't ruin it?

news.ycombinator.com

211–220 of 312 posts

Re: Do you ever avoid submitting something on HN so devs won't ruin it?

#211

Earlier quoted context omitted.

A lot of people are assuming the worst intentions here but anyone who has worked in an enterprise knows sometimes it's useful to build tools for your use and not to share. The tool might not even be allowed, C# is probably not in the supported platforms and even if it was, getting it into the official repos can be arduous. If OP really cared about maximizing everyone's productivity of course they would share the tool…

The question I have is how did incentives get so misaligned that this person feels that doubling the productivity of all their peers is unlikely to be worth the effort of presenting a tool.

It's simple: What's the company's response to the tool?

Is it a percentage of the money saved? Absolutely not.

Is it a raise? Unlikely.

Is it a pat on the back? Maybe.

Is it more work, and a lot of pain supporting the tool in ways it was never meant to be used? Absolutely.

And it'll also mean a larger workload and more stress now that the company knows how much easier the job is now.

With that outlook, why would they share it? It makes their life better and easier as it is, and releasing the tool is all or mostly negative.

Re: Do you ever avoid submitting something on HN so devs won't ruin it?

#212

Earlier quoted context omitted.

The question I have is how did incentives get so misaligned that this person feels that doubling the productivity of all their peers is unlikely to be worth the effort of presenting a tool.

Because making it work the way YOU want can be far easier than making it work the way 50, 100, 200 people want. And once they see you as a supplier of thing they'll expect you to give them what they want, because that is how people are.

Exactly, a classic 95:95 scenario. You can build 95% of the functionality for yourself pretty quickly but getting it to work for 20+ people will end up constituting 95% of the total labor if you choose to do it. There has to be a serious reason to take that on. If nobody's asking for it it doesn't feel like a smart use of company time or personal energy. Thats been my approach at my current company and it's kept me in a pretty positive / non-toxic place with the rest of our staff so far.

That said the original comment doesn't seem to be coming at this purely from an angle of practicality.

Re: Do you ever avoid submitting something on HN so devs won't ruin it?

#213

Earlier quoted context omitted.

Seems like a healthy, well-adjusted response! Something didn't work out one time? NEVER DO IT AGAIN!

Commenter complaints about negative, unproductive responses to things they've posted; immediately gets negative, unproductive response.

It's not unproductive and it's clearly poking fun.

"Had one bad experience, never did it again" is, to put it bluntly, immature.

"Only do things that immediately result in a positive experience" is a great recipe for a life and career that descends into grey nothingness.

Re: Do you ever avoid submitting something on HN so devs won't ruin it?

#214

While the question is a little incoherent (it just sounds like OP is mad about the recent YT change), it kind of brings up the sad state of software development ethics. There's no baseline shared agreement of ethical boundaries in the industry. No Hippocratic Oath for software engineers. For every scam, dark pattern, benchmark cheat, fake progress bar, background bitcoin miner, personal data vacuum, or any otherwise…

> some engineer who wants to keep their job and is willing to implement it

some _person_

it's not just a software engineering problem, every one is susceptible to taking shortcuts in any walk of life: the shopkeeper knowingly stocking expired food, the hotel manager who doesnt clean their rooms, the contractor skimping on materials

finding the root cause and delivering a working solution for all these people will probably be a more social than technical challenge. personally i blame entropy.

Re: Do you ever avoid submitting something on HN so devs won't ruin it?

#215

A little over a decade ago, I stopped a project* that got submitted to reddit and hacker news which is how I learned about hacker news via the referrer header. I was young and not exactly entrenched in the culture as I was in the midwest writing code from books without any desire of community, so I wasn't used to opinions. The negative things expressed caused me a depression since I was proud of my work. Unfortunatel…

Very interesting to see emmett, a founder and CEO at Twitch, comment on your project c. 2008.

Some of those reddit comments are less than constructive, sorry to hear you had a bad experience. We're likely worse off as a community for it.

Glad to hear you're back on the horse! Best of luck on your future projects :)

Re: Do you ever avoid submitting something on HN so devs won't ruin it?

#216
post #212

Earlier quoted context omitted.

Because making it work the way YOU want can be far easier than making it work the way 50, 100, 200 people want. And once they see you as a supplier of thing they'll expect you to give them what they want, because that is how people are.

Exactly, a classic 95:95 scenario. You can build 95% of the functionality for yourself pretty quickly but getting it to work for 20+ people will end up constituting 95% of the total labor if you choose to do it. There has to be a serious reason to take that on. If nobody's asking for it it doesn't feel like a smart use of company time or personal energy. Thats been my approach at my current company and it's kept me i…

That is a fair counterpoint. For me it was pointing out there are reasons not to do it that isn't simply being selfish. If a company wants to invest in tooling (a smart thing to do, one of the appeals of Google beyond their comp is they invest in state of the art in house tooling) they should pay staff who's primary job is in the creation and maintenance of tools to increase developer productivity/satisfaction/etc.

Re: Do you ever avoid submitting something on HN so devs won't ruin it?

#217
post #60

Earlier quoted context omitted.

You perhaps have never worked in a system where compile times are measured in minutes. There is a point where the feedback loop is so long it’s very hard to keep in your head what exactly you were trying to accomplish with the last change. Getting that OODA loop small enough means flow can happen. Flow allows you to do in a very short time what would otherwise have taken you hours. Do not underestimate the time and c…

Without real time errors you can't get in a "flow"? That's hard to believe.

Not GP, but when you're waiting for three-plus minutes on "did my change have the desired effect," it's incredibly easy to get distracted by "just checking on this one thing" for a minute and completely losing flow. When writing code, sure, but writing code isn't 100% of my job; I also have to build it.

Re: Do you ever avoid submitting something on HN so devs won't ruin it?

#218

Earlier quoted context omitted.

The question I have is how did incentives get so misaligned that this person feels that doubling the productivity of all their peers is unlikely to be worth the effort of presenting a tool.

Nobody cares about 'the company' - "In US the average share holding lasts just 22 seconds" Management can break the law, leave with their bonuses, and years down the line 'the company' gets fined. Employees are the ones that might be there for decades, but the anglosphere shareholder model allocated 0% stake to employees. TThere are alternatives: Codetermination in Germany is a concept that involves the right of work…

> Codetermination in Germany

For some reason, at first, I read this as "Code termination" (not co-determination) and thought it was a mistranslation of some German compound noun, and I was confused.

Re: Do you ever avoid submitting something on HN so devs won't ruin it?

#219

Earlier quoted context omitted.

Commenter complaints about negative, unproductive responses to things they've posted; immediately gets negative, unproductive response.

Why do you consider it unproductive? I think the perspective provided is very reasonable - if something did not work once, maybe you shouldn't stop doing it forever. What do you think would be a productive response to this complaint?

Because it's just snarky.
Post reply on HN