Live data from Hacker News

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

news.ycombinator.com

281–290 of 312 posts

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

#281
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.

I didn't mean to imply that you can't get into flow with even day long feedback loops. But the flow is definitely more likely to break while you're waiting for the feedback loop. I'm not sure you can really be in flow state between iterations if you're using punch cards circa 1970. But you might be able to reach flow state while writing said code between iterations, you'll just make sure to test more than one thing per iteration if possible. There's also a different state of mind that may look like flow for people who have to wait weeks to see if their code works. I know someone who grew up in a boarding school, and only had access to computers on the weekend, so he'd work on the code all week, only to get a chance to test it at the end of the week. He claims that's one of the reason he's such a good coder today, and I've heard similar anecdotes elsewhere.

But all kinds of things can knock you out of flow and so you might need to develop other strategies to compensate for something like a long compile time. I personally will write code, and every so often fire off a ./compile && flash_embedded_device && connect_to_device command then go back to write more code while I wait the minute plus it takes for me to get to run a test. This helps, but flow would be much easier to maintain if I didn't have to wait more than 5 seconds for the same test.

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

#282

Earlier quoted context omitted.

You're way too nice.

but window dressing because unenforceable unless the subcontractors contract assigned all work product to the payor - this rather neatly turns the responsibility for unlicensed software in production over to the manager, who should have at least passed that to legal for dd, failing which I am tempted to presume that the manager was not acting in good faith.

> failing which I am tempted to presume that the manager was not acting in good faith.

That was my impression. It looked like he saw an opportunity to rip off a bunch of neat software (without knowing exactly what it was he was acquiring) for no money at all.

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

#283

Earlier quoted context omitted.

> Increasing productivity never lays people off, unless the people were originally being unproductive. Maybe in some imaginary world with spherical cows, infinite demand, and no friction (physical or transactional). In the real world, increasing productivity so that one person can do the job that ten used to do very often results in layoffs. 70 years ago there were hundreds of thousands of telephone switchboard opera…

once again this is a clueless understanding of increasing productivity. If I build a tool and make a person irrelevent, then I didn't increase productivity of the laid-off worker. I merely increased my own productivity. What OP said was his tool specifically increased the productivity of all other users , which means his team can churn out features faster. Show me a management team that says no to it

That's easy: a management team that only needs ~X new features per month, not 4X. No organization has an infinite demand for features. If they currently have 50 devs working on the platform, maybe after quadrupling the productivity of each dev they'll keep 20. Speed of development increases by 60% and they save 30 developers worth of expenses, which means hefty end-of-year bonuses for every manager up the chain. More likely they keep about 13-15.

It's naive and boneheaded to insist that productivity increases never result in layoffs.

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

#285

Earlier quoted context omitted.

And how do you get around the concept of any code you write on company time, on company resources is owned by company?

It’s unenforceable if they don’t know about it.

Sure, if you questionable morals.

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

#286

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…

I can relate to this so much. In my first job I was working with analysts who spent a lot of time generating reports. I was a SQL dev who had learnt python recently and automated my report generation. It cut down work from 1 day per report to less than a second. I shared this with my manager who shared it with the team. The team ended up sending me the files for me to run it. And the ones who wanted to run the script on their system ended up having me on-call support half the time fixing issues unrelated to the script.

I cited a system upgrade and informed everyone the scripts were gone. We're back to how we were, except I had a lot of time in my hands now. Since it was my first job I felt bad for not helping out people. After my experience I feel it's not worth it.

You can say the same arguments for having a really well defined customized editor and your coworkers wanting the productivity you have. I showcase using pycharm, but I do my actual work using emacs.

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

#287

Earlier quoted context omitted.

> I could see not wanting to support a tool. I had one time written a small tool to reformat a CSV file for one of the office workers. One day she comes to me to make some change to the tool, but I was extraordinarily busy with my real work - and I only came in that day because there was a fire burning that I was best suited to putting out. So my refusal to drop the emergency that I was fixing (on my day off) in orde…

>> So my refusal to drop the emergency that I was fixing (on my day off) in order to modify this tool that had already saved her probably tens of hours of tedium, let to resentment and ultimately to me being fired from the place. Man, we live in a society… glad you are in a better place now!

Yeah, the people who could appreciate me, the developers and developer management, were ultimately less influential than an administrative staff member. And this was a software business, writing software for clients. Not a software division of some larger entity. One grudge is far more powerful than a chord of appreciation.

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

#288

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…

Another cool one that I've made:

In dotnet there is a package called ssh dot net (spelt out). With this package you can programmatically ssh into your vm's (basically open a normal ssh tunnel from c#). Its great. I use this in conjunction with the postgres dotnet driver to connect to our production databases. I use this when I don't feel good about doing data maintenance directly in sql and need more type safety. So I use my little C# tunneler quite a lot to get my work done quickly and safely, all while the other devs are fighting over vim/emacs vs using postgres in the terminal. So me using my own little tool for all of the risky stuff has been a godsend. That and Datagrip (I have a paid version of this, worth every single penny). The little tunneler reads the database schema when it starts up then generates a class/model for each table so it closely matches with it, that way I can fiddle away and write some clean sql against the db without stress. I know it sound silly but it works great!

So yeah. The company I work for is a strictly-java shop with an apple fetish (so everyone has macbooks). Little do they know I haven't touch the macbook in almost two years. I use my desktop Ryzen pc with a bunch of C# tooling. Ha!

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

#289

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…

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…

Telling them that I use C# will just paint a target on my back since everyone is anti Microsoft and they cringe if you mention anything Microsoft related.

Other than that, there is a ton of admin/red tape to get past if I want to introduce it as official tools and some team needs to be able to support it.

My intentions are actually not malicious at all, I'm just reducing my own frustrations and avoiding adding more stuff onto my plate.

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

#290

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.

Another small issue is that the company I'm at is kind of risk averse and try not to use custom tools built by individual devs. They've done it once and now they are stuck with that one tool(also a kind of custom compiler like mine)but the dev is long gone. So unless it becomes an official feature of our systems and some team (not an individual) can support it and there is a clear tech/business benefit, they would most likely deny the dependency. And to be honest, it has kept things sane/boring. It's good stewardship in my mind so I'm at peace with their apprehensions.
Post reply on HN