I mentioned something we built at work and got the typical HN nitpick about it and decided to never bring anything else up again. If something is open source and you don’t like just move along.
Seems like a healthy, well-adjusted response! Something didn't work out one time? NEVER DO IT AGAIN!
Do you ever avoid submitting something on HN so devs won't ruin it?
101–110 of 312 posts
Re: Do you ever avoid submitting something on HN so devs won't ruin it?
#102Earlier quoted context omitted.
My experience is complete opposite to yours. I've built at least hundred of little tools here and there to improve my productivity to the point where single keypress is what only needed in every other context to run specific scenario. I've tried to give it to my fellow devs around to make their lives easier. No-one seems to care enough even to try.
It sounds like you deserve a new job with more challenging peers. Environments like that can suck the life out of a bright flame Reminds me of a younger self going to interview for the technical team at a bank. I arrived full of youthful zest, thoroughly aced the interview. One of the interviewers, who already looked rather zombie-like, accompanied me to the exit. As I walked off he lit a cigarette and shouted after…
They passed. Reason was I was too much of a cowboy and they were afraid I'd rewrite their whole system within a few months of starting.
I can read that many ways these days but I'm glad they passed ...
Re: Do you ever avoid submitting something on HN so devs won't ruin it?
#103I once wrote a python script that went through the various ticket prices on the megabus website (which used simple GET queries in the url), to find out future dates with cheap tickets. It's the kind of thing that you could do by hand, but the website (intentionally?) made it a tedious and time-consuming clicking exercise to compare effectively. They changed their API eventually, but I made decent use of the script fo…
The best part is, eventually you hit things like booking something as soon as it gets online. And it happens so fast you figure out there are multiple engineers out there, each with their own script, fighting it out
Re: Do you ever avoid submitting something on HN so devs won't ruin it?
#104Earlier quoted context omitted.
wow, super happy I don't work with people like this.
Why would you care? He's not actively harming his coworkers, he's doing what is asked of him work wise, and his colleagues presumably are too - and are themselves getting apparently slack jobs if there is 6hrs per day of easily automated work. Imagine if your coworker told management about an efficiency hack that made you responsible for 4x the output per day. Would you rather work with that person? Personally, I wou…
Re: Do you ever avoid submitting something on HN so devs won't ruin it?
#105Re: Do you ever avoid submitting something on HN so devs won't ruin it?
#106Earlier quoted context omitted.
Assuming its not trivial, its hiding a useful tool from your coworkers. Why share any knowledge at all? Why mentor someone if it just gets them more work? Seems pretty toxic to me.
This isn't any different than keeping a bunch of text snippets that you use as a starting point for creating things. Text snippets may seem trivial in comparison to some tool that writes code or checks for your common errors, but when there is a bug in your text snippet, you own the bug. Let's say he gives away his tool and all of a sudden he is the guy who has to work on it when other people have problems. Now his c…
Re: Do you ever avoid submitting something on HN so devs won't ruin it?
#107Earlier quoted context omitted.
This isn't any different than keeping a bunch of text snippets that you use as a starting point for creating things. Text snippets may seem trivial in comparison to some tool that writes code or checks for your common errors, but when there is a bug in your text snippet, you own the bug. Let's say he gives away his tool and all of a sudden he is the guy who has to work on it when other people have problems. Now his c…
Sure, there's plenty of reasons to not push every line you've written. However, the stated reason is to keep a "competitive advantage" against their coworkers.
Re: Do you ever avoid submitting something on HN so devs won't ruin it?
#108Earlier 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.
I've also made the mistake of sharing my tools only to find criticism but no offer to help make improvements. Fuck em, wasting my time.
Re: Do you ever avoid submitting something on HN so devs won't ruin it?
#109Earlier quoted context omitted.
Real time error messages are useful, but I don't see how they could make you win 4x time
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…
Re: Do you ever avoid submitting something on HN so devs won't ruin it?
#110I mentioned something we built at work and got the typical HN nitpick about it and decided to never bring anything else up again. If something is open source and you don’t like just move along.
Seems like a healthy, well-adjusted response! Something didn't work out one time? NEVER DO IT AGAIN!