Let's say I found a way to bring back the number of dislikes of YT videos. Knowing that some YT devs are on the platform, I'd be reluctant to share it so that they won't know about it [0] and ruin the already-ruined YT experience. It shouldn't be like this, I know. But I've lost hope in the well-intentions of some devs in the industry. I thought we were supposed to have each other's back, but apparently money makes people do anything.
[0]: At least for quite some time.
Edit: By "well-intentions" and "having each-other's back", I mean devs doing something that most devs would enjoy, not making each other's life harder. Going back to my example: As a dev, how many times have you watched a YT tutorial to sharpen your skills? Now w/o the dislikes count, all devs have a much harder time filtering useless videos. Whoever removed the dislike count on YT has caused millions of wasted hour-man. Then again, if they're paid well, many devs would do the same.
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 constantly compiling in the background as the file changes. It's great. Can it improve the lives of the 50 or so other devs working on the same platform? For sure (it saves a ton of time and frustration). Will I tell them about it or release it onto our private git repo's and make it part of our platform/build chains? Nope.
I can give you 20 good reason why I won't do it but really don't want to get into it. If they want it, they ask for it & while they are at it, they can pay me a cool sum of money for it. Until then, it is my own private competitive advantage that allows me to work 2 hours per day instead of 8. Not embellishing.
If OP really cared about maximizing everyone's productivity of course they would share the tool. But if I'm working at a large enterprise and increasing productivity may only lead to laying people off I have exactly zero motivation to share something like this.
I hand wrote them licenses in perpetuity to the half-dozen utilities that I'd written. One was simply two API calls, it popped a message box, and if you hit ok, would restart windows without rebooting (win16)
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.
It's our fucking job to optimize the world around us.
How do you think can we, as a society, advance while doing bullshit jobs?
Make me obsolete!
Also, scaling tools to more than one user is incredibly hard. Software development is still custom / art. This tool works because it is suited to OPs workflow and his "way of thinking". In order to make it work for others, it needs lots of improvement and generalization, which is incredibly hard. Some people may even hate it, because they have their own best way to do things.
Devs should stop being delusional about their self-importance in these things. There are 100 other factors going on in an org and your one little tool ain't gonna make a penny difference in the profitability or productivity of the company (unless you have data to prove it, including impact on profitability)
Generalizing a solution, becoming a product owner, maintaining it for others, or even worse having some douchy manager take your idea and ruin it, seems like it would be way more work than I can handle and still do my day job.
[0] Almost double the median household income for my area.
This involved calling engineers at their desks and offering workshops where they got some continental breakfast and to try out some very expensive IC design tool.
The company had a web application written in ColdFusion that had a bunch of forms to fill out each time a phone call or email exchange was performed with a lead. Enterprise sales would use this information to move sales through the pipeline.
I got bored really quickly of tabbing through the page and the repeat data entry based on call or email outcome. So I found a windows macro tool and wrote 5-10 macros that handled 80% of all call outcomes, making it trivial to add details.
Ideally, the web application would just get this kind of automation. However, some of the macros were campaign specific--they just didn't do it.
When my manager saw how I was pulling off the call volume and results, (which were modest--it was still largely cold calling), everyone on the team got a license to the macros and I was asked to share the macros around.
They were all RCGs or recent masters grads, so it wasn't really a problem. But it immediately set a floor for "why are you typing that and using your mouse to finish this call? We have a tool to do that" kind of thing.
- 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't you write it Java?
There's also people issues with the other devs who may not like OP's tools or want to change their process.
Large orgs/enterprises aren't about solving the problem - it's about the ceremony around solving the problem expecting the problem to solve itself eventually. Going around that ceremony can/will be seen as "going rogue" and will often end in termination of some sort. If the company wants/needs someone outside of that ceremony they will likely go "hire a consultant" vs. trying to find solutions within the ranks.
I'm not supporting this - I'm just saying it's how it is at the majority of larger companies that I've worked for/with. Honestly I think it sucks and stands in the way of real problem solving.
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.
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 me, "don't accept the offer, this is not a place for someone like you!"
Made a variety of friends over the years who have shared stories of that bank. It's notorious, the interviewer was absolutely right.
Person sees a massive inefficiency at their employer. They know of a way to save time and money by building a tool to solve for it.
That person starts their own business to sell that product to others.
No better way to find product / market fit than to have first hand experience in the problem that needs to be solved.
There are also larger ideas and projects I keep to myself because I think they're viable and useful but refuse to see them ruined by the current scene/think the drawbacks of letting the idea out in our current culture outweigh the advantages.
I don't LIKE either of these things, but it'd be foolish of me to ignore the lessons I've learned over the past quarter of a century.
In my first job, I would make constant productivity improvements like this. This resulted in two problems:
1. The team became dependent on them, but only I would maintain them (management's directive). Although productivity went up, management saw me as the bottleneck because if the tool acted poorly, that team member's work was held up until I fixed it. I ended up with a lot more responsibilities, yet had to keep up with all my teammates who were using the tool to be more productive. That's a recipe for burnout. And except for one bonus one year, I didn't get paid more and it was made clear to me that all this stuff would not contribute to a promotion.
In summary: I needed to maintain all this, do my "regular" job, and had no option not to work on the tools any more.
2. Since management loved all these tools, they decided to own them: Prioritized features, changed behavior for the worse, etc. I now had to not only maintain my babies, but I had no say on the development of said babies.
I was eventually fired for not being productive enough on my "real" work.[1]
I'm not jaded, though. Now in every new job, I test the waters. If management acts this way again, I stop showing people my productivity tools, and slowly look for another job. Often, management really does appreciate and reward me.
[1] Well, and for other reasons. I quit first, and they retroactively fired me :-)
Also, if it does decreases work time by 3/4, guess what happens when the business finds out? Deadlines and estimates get pushed up, and everyone is expected to get that much more done. Sometimes, as a developer, you need a trick up your sleeve to keep your head above water fighting unrealistic expectations. If everyone has the same trick and it becomes part of your SDLC, the goal post just gets moved.
Back in the Bad Old Days(tm) when disks still spun and displays weighed as much as a human, all manner of crap used to go into /usr/local but nobody would ever own it--consequently, you'd have knife fights over versions of Perl, for example. Eventually my VP turned to me as a noted BOFH and asked "This is getting out of hand, should we just delete it?" "Depends--will you fire anybody who gives me static?" "Yes." "Consider it gone."
So, I warned people for 4 weeks that everything not owned by somebody was going away. Then at 3 weeks. And at 2, 1. Then at 3 days, 2 days, the day before twice. Through all this only a single soul signed up (and it was an intern ordered to--we transferred the intern to my group and gave his manager a ding and a tongue-lashing later. But that's a different story for after more alcohol).
And finally on the magic day, I wiped it out (with a backup of course).
All holy hell broke loose. Everybody trooped to my cubicle.
To which my response was: "Great! You're here so we now know that you depend on something in /usr/local. So, which package are you the owner of?" Half of them would start screaming. Probably a third would start begging.
To which my response was: "Look. This isn't difficult. You have a dependency. Sign someone up from your group to manage the dependency. Then I'll put it back."
In spite of that, 90% of them walked away without signing up. Being dead in the water and hoping for some other poor fool to take ownership was considered less problematic than signing up for global ownership of a software tool.
That's how crappy "ownership" is in a company.
Unless I can guarantee myself (and them) that my tool will be a very tight integration with the rest of the system and not become a wart, then I rather won't introduce it. It has to fit properly with the rest of the puzzle.
Deleted Comment
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.
Personally, I wouldn't want to work at a company that apparently is not incentivizing creativity. I'd rather work somewhere where I knew if I did something like this I'd get more money or career progression or something, not just more work to do. But I certainly don't blame the employee for this
I definitely see that in many of the people I work with at my clients. The more efficient staff members typically only share pretty trivial life hack-esque tips. Their comprehensive framework of all of their efficiency tricks? Kept in their heads.
If they share it, they lose their edge against the peers they are ranked against. If they don't share it, they consistently are in the top 5-10% of employees with the most story points each sprint, and they get better raises.
This is an easy decision for the employees to make. You get what you incentivize for.
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).
Do not underestimate the time and cognitive savings of realtime feedback.
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).
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 care less about improving productivity and in fact would rather that everything is tedious, error-prone, and time-consuming so that at least it's mindless for them to go about their day.
3. Those who see everything they don't understand through a lens of fear and hatred. They will not understand your tool OR why it is helpful, and will instead see it as an alien invasion or viral infestation in their workspace, and will work concertedly to resist it.
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!
Normal people used flymake on emacs for the last decades, recently switched to LSP feedback or VScode.
If I use my own time to make something, work isn’t getting it without paying for it. I don’t care what the contract says about personal projects (although I‘ve also never signed one of those “we own everything you do outside of work” clauses because I find them exploitative and abusive)
Holy shit.
I would not want you and your philosophy around me at all.
It is important to know when to leave your mark in the world and when not to. Sometimes it is better not to inflict my own way of life onto others. Just because it makes me work better doesn't reduce other people's efforts. And with the extra time I gain, I do still use it for work stuff, but not on the mundane stuff. I also work in the slow behemoth industry known as Healthcare, so introducing new things carry a ton of risk in our domain and some personal risk. It really depends on the situation, the people/company involved the domain, the government and how formal/academic things are. Context is everything.
My preferred alignment is Neutral in DnD terms. Specifically in this order: Chaotic Neutral, True Neutral and then Lawful Neutral. It's amazing how well the DnD alignment matrix fit onto real life situations. I don't even play the game.
I hope my comments in the conversations on this topic helps others navigate and balance this kind of problem that we all face at one point or another. Introspection and empathy helps a ton in this case. Don't just think about how it will improve other's lives, but also the consequences if things goes wrong. If you ignore the dark side of your invention, you might be blind sided by those consequences when they appear. Then you are forced to pick a side: either support and fix your creation or shrug your shoulders and tell yourself that you don't care. That has it's own set consequences, both for others and your own mind.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
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. Unfortunately, for the business, the right thing to do was to stop developing the language and use shit that the local labor market could handle.
This awareness of what the market could support was depressing as hell, and I eventually couldn't be an effective leader for that company as I was more interested in doing interesting things versus the right thing. I found it boring, and that's when I went into big tech to work on interesting things.
Now, I'm older, and I'm up to my shenanigans again with a new language: http://www.adama-lang.org/
One thing that I have learned is that you can't make everyone happy, but you can make a small group of people ecstatic. Next year, I intend to work on my language full-time (ish) and ship something that people can use with just a command-line.
* https://www.reddit.com/r/programming/comments/6ori0/kira_is_...
* https://news.ycombinator.com/item?id=226480
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 :)
So I made a little code to pull from FM and put into Word. So we could fill these forms, required for payroll, in minutes rather than hours (not a joke). And my team mates loved it. And then our lead claimed it as his own work, presented his accomplishment to the next boss up, bonus, congratulated and promoted. (Fuck you Ed)
Most folk only got they own back.
It had no impact on my career path and I'm still making stuff GPL and BSD and MIT.
The mobile page asked for the full passcode whereas the regular page asked for specific digits which, while still automatable, wasn't as easy
The code/method might have been useful to others at the time (especially your Mints and that) but I didn't want them changing it. The mobile site was, as far as I could tell, a relic from an older era that I stumbled across by accident
Everything's starting to catch up now so it's no longer needed. My bank now (Monzo) even does webhooks for transactions if you set them up :)
On the topic of YouTube I really don't get the reaction to removing dislikes, seems a bit overblown. I am biased in that I've never noticed them other than that one Futurama neutral video that keeps them synced with the positive votes though (which ofc is now broken)
Incidentally removing the number and replacing it with a big DISLIKE in caps makes it much more noticeable. I am way more likely to click it if the video is bad now, for whatever that matters
Edit for OP edit:
> Now w/o the dislikes count, all devs have a much harder time filtering useless videos
This is the only argument I've seen opposing the removal of dislikes so far. Are there any others? Even silly reasons, anything other than "bad tutorials tho"
Is that argument not enough? It is now harder to distinguish good videos in a video platform filled with sub-par content, any other argument would pale in comparison.
For me, no. I've never used the dislikes for this, it seems like such a crowbarred in reason everyone latched on to for lack of a better argument
I tend to judge the content on the content
The first few comments were negative — not ideal but certainly okay! — but then the author started getting harassed off-site. I was contacted and immediately deleted the post.
Start to finish, the whole process took maybe 30 minutes, but it was sadly instructive and I think about it every time I submit something here. It's probably made me comment less.
Because of a post here on HN? What happened?
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 for a couple of years.
To me it looks like the lind of script that, had it gotten traction, Megabus would have changed their interface a LOT sooner (and also I'd be competing with others over the cheap tickets!); so I kept it to myself.
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
I don't see the link with your example. How would people profit of finding the number of dislikes on YouTube?
Also, sharing this would increase the number of users of the exploit, and its general publicity, making it more likely to be fixed. Nothing to do with having each other's back.
And then, considering that you are disclosing a security leak, the "having each other's back" thing to do here is disclosing that to google, not exploiting it yourself
Dead Comment
A reason to be afraid to submit may be that the number of respondents that don’t know how to review may exceed the number that do, causing the net result to be more destructive than constructive. Which brings me to another skill — how to ignore input that (even if you receive it) does not really matter, or at least not right away or not as much as other things.
If only as a profession we could resist the urge to quibble about things that probably are fine (or at least not pressing) so that there is more time to dig into the heart of a design or implementation. Yes, that’s an interesting algorithm; no, let’s not segue into the choice of back-end on the web site that happens to host the documentation; yes, that will help with maintainability; no, the number of spaces here does not really matter; yes, that is a good recommendation but not under these time constraints; no, I will not rename 125 variables to suit your arbitrary choice instead of my arbitrary choice.
I would also add that “review” is often misinterpreted as “pure criticism” (again, in code or in HN comments) and it can be nice for unsolicited positive feedback to occur too. Things like “I like how this was done”, or “I’ve never seen anything like that, clever” as opposed to an unending wake of negativity that tries to tear apart any given project.