Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

291–300 of 312 posts

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

#291

Post by BatteryMountain »

npmisdown wrote: post #46
BatteryMountain wrote: post #9

Yeah I do this. Most of what I build, nobody knows about it nor is it release into the wild. Latest example: at my current workplace we have some crappy custom compilers for our platform.... I've rebuilt them in a way that I like (and using C# instead of Java), that enables me to use it in a small visual studio code plugin that enables me with real time error messages as I code against our platform, so basically cons…

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.

I've also encountered this kind of apathy in other devs. I don't have a good answer what to do about it though.

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

#292

Post by BatteryMountain »

GartzenDeHaes wrote: post #88
BatteryMountain wrote: post #9

Yeah I do this. Most of what I build, nobody knows about it nor is it release into the wild. Latest example: at my current workplace we have some crappy custom compilers for our platform.... I've rebuilt them in a way that I like (and using C# instead of Java), that enables me to use it in a small visual studio code plugin that enables me with real time error messages as I code against our platform, so basically cons…

Here's some management issues OP might be referring to. - Who is going to provide support, bug fixes, documentation, manuals, etc? - What happens if you leave? Can our other devs maintain this? - Did I mention documentation? - Did you get this approved by the architecture committee? - Why didn't you follow our process improvement policy? - We are a Java shop, so can you rewrite it in Java; you know this, so why didn'…

Perfectly spot on. It's not about being malicious/apathetic but rather the things you mention above.

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

#293

Post by BatteryMountain »

version_five wrote: post #40
northisup wrote: post #11

Earlier 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…

This is the core of the issue: we don't get time allocated for innovation/creativity and other internal improvements. At town halls we get told we need to be innovative but then.. no time is allocated for it. I suspect a handful of other devs also has their own tooling as mine to make their lives easier, but keeping it for themselves, as telling/showing other can often invite unintended consequences.

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

#294

Post by BatteryMountain »

Hekioi wrote: post #130
version_five wrote: post #40

Earlier quoted context omitted.

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…

He/she is blocking a head count for a person who would improve the success of our team and our company. I prefer people who genuinely like to improve our whole environment than not. Sharing and caring!

I do but the company doesn't care about stuff like this at all. In other ways the company is great but in some other ways not so great.

I do have the urge to share it with others but on the other end I force myself not to do it. I care a great deal. I have shown things in the past, during screen sharing meetings, then I hear people taking screenshots of my work... no thanks.

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

#295

Post by BatteryMountain »

onion2k wrote: post #65
BatteryMountain wrote: post #9

Yeah I do this. Most of what I build, nobody knows about it nor is it release into the wild. Latest example: at my current workplace we have some crappy custom compilers for our platform.... I've rebuilt them in a way that I like (and using C# instead of Java), that enables me to use it in a small visual studio code plugin that enables me with real time error messages as I code against our platform, so basically cons…

Maybe your colleagues haven't asked for it because they built their own, but better, and are only working for 1 hour a day. Maybe you work twice as hard as the rest of them...

I suspect a handful of them have their own tools to ease their suffering, same as me, but most don't and are just apathetic and carry on with their day.

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

#296

Post by BatteryMountain »

bokchoi wrote: post #44
BatteryMountain wrote: post #9

Yeah I do this. Most of what I build, nobody knows about it nor is it release into the wild. Latest example: at my current workplace we have some crappy custom compilers for our platform.... I've rebuilt them in a way that I like (and using C# instead of Java), that enables me to use it in a small visual studio code plugin that enables me with real time error messages as I code against our platform, so basically cons…

Wait, why don't you want to help your colleagues? That seems pretty shitty.

In some cases people play politics: some people are looking for places to find fault or point fingers to if they get stuck, so just limiting the amount of drama in my life.

The code I built is like 500 lines of code, not that complex and any developer with half a brain can build it... so if they want, they can build it themselves. Why should I deprive them from learning how to empower themselves? Its a great learning experience to build tools around your current journey.

And the tools are disposable btw. I've done this at every place I've worked. I have a small graveyard of tools of everything I've built in the past. And sometimes I go and copy code from it for a new tool and so forth. Every developer have a folder somewhere with some cool tools just for in case. If they don't... maybe they just don't care about programming as much as they think.

It's like asking why a mechanic won't share a tool he built by himself for himself, to help him replace a certain part in a car, when he needed 4 arms but only had 2 at the time. He is not obligated to share his tool with the world and keeping it isolated might save lives (lets say there is some risk that someone might die in the case of a malfunction). In the tech world, php comes to mind when I think about releasing things into the wild. I try not to inflict onto others with what is in my head, because how I view the world and how I like to work is not necessarily how other people think.

I work in the Healthcare domain, specifically with medicine and formularies. It is utterly important that we do things correctly. If I share my tools with the others and they misuse it or something goes wrong, and there are real world consequences (a patient gets the wrong medicine/dosage/box or data gets corrupted), then I can guarantee you they will point their finger at me and throw me under 50 different busses. I'm not going to risk that for no good reason.

So it's not as simple and clear cut as just being shitty. I promise you it is not because of selfishness but rather about self preservation (not getting burnt) in conjunction easing my own suffering (cause most healthcare software is an utter shit show, thus my own tooling is just a band aid).

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

#297

Post by BatteryMountain »

Aardwolf wrote: post #31
BatteryMountain wrote: post #9

Yeah I do this. Most of what I build, nobody knows about it nor is it release into the wild. Latest example: at my current workplace we have some crappy custom compilers for our platform.... I've rebuilt them in a way that I like (and using C# instead of Java), that enables me to use it in a small visual studio code plugin that enables me with real time error messages as I code against our platform, so basically cons…

Real time error messages are useful, but I don't see how they could make you win 4x time

Our development life cycle is quite slow/cumbersome with crappy in-house compilers that are on life support... yeah it makes a big difference not having to deploy between each iteration and get local feedback while I'm coding.

I cannot elaborate more than that but it is a bit more hairy than I described. My own tools alleviate some of the problems (sadly not all of them). Doing the best I can with what's available to me (basically building workarounds for shortcomings of our systems where I can see holes).

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

#298

Post by BatteryMountain »

milesvp wrote: post #60
Aardwolf wrote: post #31

Earlier 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…

Exactly this.

Many feature request in our system takes 2 hours to implement where it would be 5 to 10 minutes in C#/Visual Studio (with a tight debug/compile loop).

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

#299

Post by BatteryMountain »

JacobThreeThree wrote: post #204
milesvp wrote: 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.

In our system it is incredible hard to get into flow. All of our work is basically intermittent due to the nature of the system.

You are fortunate that you haven't had to deal with it yet, but it's very real, you don't have to believe us.

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

#300

Post by BatteryMountain »

softwarebeware wrote: post #266
BatteryMountain wrote: post #9

Yeah I do this. Most of what I build, nobody knows about it nor is it release into the wild. Latest example: at my current workplace we have some crappy custom compilers for our platform.... I've rebuilt them in a way that I like (and using C# instead of Java), that enables me to use it in a small visual studio code plugin that enables me with real time error messages as I code against our platform, so basically cons…

One of the big reasons not to share tools that would otherwise increase productivity in a corporate settings, is that people are petty a*holes. They will fall into at least three big negative buckets. 1. Those who will see it as a personal insult if you write something useful and you will then have a target on your back as they work to block you and hurt your career so you never show them up again. 2. Those who could…

Number 3 is most common in my experience, esp in dev shops that uses Java. Very averse to things outside of their Java empires.
Post reply on HN