14 ms·

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

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

northisup 5y ago
wow, super happy I don't work with people like this.
- toomuchtodo 5y ago
  You wouldn’t know if you did.
  - Philip-J-Fry 5y ago
    I would because they'd be more productive than me.
    - OnlineGladiator 5y ago
      They might be more efficient, but by working 1/4 as much they're equally productive!
      - toomuchtodo 5y ago
        Exactly. You get paid for your output, not your effort. Edit: A deleted reply said “You don't even really get paid for output. Output theatre pays better than output.” Great insight I thought worth persisting.
        deleted 5y ago
        [deleted]
    - BatteryMountain 5y ago
      To be honest, I try my best to conceal my gains. I intentionally time my feedback to when it is expected of me.
  - remus 5y ago
    You can probably make a good guess though. If you have conversations at work like bob: "hey come and check out this cool thing I made, I think it could save you a load of time" me: "woah, nice one bob, that's amazing! Let's roll this out to the other devs" then you're probably not working with someone like gp.
- arbitrage 5y ago
  The feeling's mutual, i assure you.
- version_five 5y ago
  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 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
  - jayd16 5y ago
    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.
    - mmcgaha 5y ago
      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 coworkers have more time, he has less, and he is the scapegoat for when things go wrong. Not only that but since it is not a real product of the organization, no one will recognize the time he works on it so he will have to work over time to meet his other goals. Now if someone wants to ask for a copy of what I use, sure but they own their copy and I own mine.
      - jayd16 5y ago
        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.
awillen 5y ago
Why would they have to pay you a cool sum of money for it? It sounds pretty clearly like you did it for work, so unless you have a very unique employment contract, they already own it.
- dheera 5y ago
  Uh, because you could get 4X the "amount of shit" done in the same amount of time? So ideally they should pay you 4X.
- dkersten 5y ago
  For work sure, but it also sounds to me that it was built during personal time. 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)
  - JohnFen 5y ago
    > (although I‘ve also never signed one of those “we own everything you do outside of work” clauses because I find them explosive and abusive) Me too. I always ask that it be removed from the contract, and so far, it always has been.
    - parksy 5y ago
      When I was working as a web developer for a company, I published a game I spent many years dreaming of, and in real terms thousands of hours learning and creating. I wrote the music, drew the sprites, coded the game loops, purchased all the tools, built it using my own hardware etc. The CFO at some party or other after a few beers told me if the game actually became successful, there was nothing I could do to stop them claiming ownership of all of the IP because of a clause I'd signed at some point. Since I left that place and I believe most of my time-limited terms have expired, IP is one of the very few things I'll get caught up on with a contract. I'm flexible around hours, reporting, attire, presence, etc, but IP outside of specifically client-related work activities is where I draw the line. I am a digital creator on my own time, I always have been since I was a child, I draw inspiration from many sources, whether it's work or books or videos or art, or even just a random thought. The notion that one day one of these things randomly becomes successful and a bevy of previous clients lays claim to the fruits of my labour sickens me to the core and goes against every sense of living in a fair and just society. I've knocked back clients who refuse to budge on this issue. I'm no Bill Gates or whatever, but there's absolutely no way I'm signing over rights to things I invent or innovate on my own time. If the people I work for want access to that additional service beyond whatever monkey-shit I'm doing for them then they can pay for it and not just swipe it through some boilerplate IP clauses.
RankingMember 5y ago
Making it broadly available could also potentially just set a new floor for productivity in an industry that doesn't always reward such gains commensurate with their value, i.e. you'd get an attaboy and "alright well now you can do three times as much work for the same pay!"
- jdavis703 5y ago
  Isn’t that the whole point of software engineering? You should always be engineering yourself out of your current job. If I’m dealing with the same issues I have today, a year from now, then I’d view that as a personal failure.
  - eat_veggies 5y ago
    They engineered themselves out of their current job and still get paid for the job they don't have to do. Sounds like they engineered it pretty well.
  - RankingMember 5y ago
    The whole point of engineering is to engineer yourself out of your current job? What? I think I must be misunderstanding you. Are people who engineer planes supposed to be engineering spacecraft or consider themselves failures or something? I'm confused.
    - toqy 5y ago
      They are supposed to engineer machines that engineer planes during their free time obviously
    - jdavis703 5y ago
      Good point. I meant us fake software engineering, not you real engineers with “PE” at the end of your name. My original comment has been clarified.
  - literallyWTF 5y ago
    I hate this mindset. I’m not trying to make my job and the job of others obsolete. I just want to get paid so I can fuck off and do some other shit I want to do.
Aardwolf 5y ago
Real time error messages are useful, but I don't see how they could make you win 4x time
- milesvp 5y ago
  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 cognitive savings of realtime feedback.
  - deleted 5y ago
    [deleted]
  - JacobThreeThree 5y ago
    Without real time errors you can't get in a "flow"? That's hard to believe.
    - pixelbath 5y ago
      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.
    - milesvp 5y ago
      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.
albatross13 5y ago
Respect.
hallway_monitor 5y ago
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. 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.
- willcipriano 5y ago
  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.
  - runevault 5y ago
    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.
    - pkdpic 5y ago
      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.
      - runevault 5y ago
        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.
uhtred 5y ago
I get this. If you tell people, and it gets released into the official tool chain, you will also probably then be its "owner". More work for you with no extra money.
- deleted 5y ago
  [deleted]
- WesleyJohnson 5y ago
  Not only that, but once the company owns it, they'll want to start managing it, making changes, etc. You run the risk of it becoming bloated with features, making it harder to maintain and the whole thing loses the reason it existed in the first place. Maybe that's a stretch, maybe not. 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.
- BeetleB 5y ago
  I was looking for this among all the responses. Surprised you're the only one who mentioned it. 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 :-)
bokchoi 5y ago
Wait, why don't you want to help your colleagues? That seems pretty shitty.
- anthomtb 5y ago
  It’s entirely possible that his colleagues have no desire to be helped, which can happen in a shitty organization.
  - dylan604 5y ago
    Seems like better time spent on looking at how to get out of shitty org than gaming the system
    - slingnow 5y ago
      I'd be curious to see why you're so confident that OP's time is better spent getting out of this organization where they can work 2 hours a day for what I assume is a decent living.
      - dylan604 5y ago
        Financial wellness !== mental wellness.
    - ClumsyPilot 5y ago
      Its funny how gaming the system is 'innovation' for bosses and 'cheating' for employees
- johnisgood 5y ago
  As long as it is only known to colleagues, it is all good, but if word gets out (and the more people know about it and/or use it, the likelier it is), then they may get more work to do and such. Maybe the coworkers do not give a damn either way.
- yourapostasy 5y ago
  A possible reason is stack ranking in annual reviews. 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.
npmisdown 5y ago
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.
- stillicidious 5y ago
  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 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.
  - grogenaut 5y ago
    I had a similar in 2000 during the .com bubble, interviewed at an ecomm company doing libraries, Amazon had not yet put them out of business. All c++ cgi. I asked a lot of questions about the stack and dev speed. They had looked at java but didn't have experience so were just going to plug along in c++. Their customers, libraries and book stores, didn't care. 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 ...
- BatteryMountain 5y ago
  I've also encountered this kind of apathy in other devs. I don't have a good answer what to do about it though.
dylan604 5y ago
And how do you get around the concept of any code you write on company time, on company resources is owned by company?
- benhurmarcel 5y ago
  It’s unenforceable if they don’t know about it.
  - dylan604 5y ago
    Sure, if you questionable morals.
- cyberge99 5y ago
  That’s a legal construct. The company owns it (in licensure), but he’s the sole user/operator if it.
  - dylan604 5y ago
    Right, so if company finds out that you have code written on company time meant to be used to do company work, company can then say that all employs must be able to use that code. OR they could say that you can no longer use that code. No longer abiding by either mandate could be cause for dismissal. Legal construct or not, it is a work product that would be owned by the company. Using that code at a new company would be wrong as well.
onion2k 5y ago
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...
- BatteryMountain 5y ago
  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.
alberth 5y ago
A lot of successful companies are founded this way (Eg HashiCorp, SAP, Basecamp, etc). 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.
- htrp 5y ago
  and more importantly, they get paid in line with what the tool is worth.
GartzenDeHaes 5y ago
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'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.
- peterangular 5y ago
  Having worked in an enterprise this list is 100% accurate. For better or worse (I think it's the latter) enterprises are all about coloring inside of the lines. If you color outside of the lines you may experience functional success in parallel to professional/social failure. 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.
  - mring33621 5y ago
    Agree 100%. Also, there are some very quotable things in your comment. "experience functional success in parallel to professional/social failure" is my favorite, though. Thank you! Source: I work at a huge bank.
- BatteryMountain 5y ago
  Perfectly spot on. It's not about being malicious/apathetic but rather the things you mention above.
np- 5y ago
Kind of similar but maybe in a different context—there are a few tools that I’ve written for myself that speed my work up significantly but I haven’t widely disseminated. It’s not because I don’t want my coworkers to succeed, but more that my tools are directly mapped to the way my brain and hands work. Ie, I’m much more of a shell guy who likes to write command line scripts to speed things up while most of my coworkers prefer heavier IDE/tools/plugins to assist (no judgment either way, its just how our brains work). I offered some of my tools a few times but no one took me up so I don’t bother anymore. 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.
sibit 5y ago
When I was first started my career I was working at a small software company. I spent my evening and weekends building tools and plugins to optimize my workflow and I quickly became 10x more productive than my coworkers. I shared my tools with the company and in return, I was rewarded with raises year after year. I went from 30k to 80k[0] in 3 years. Now I work for a large software company and the same tactics haven't worked out in my favor so I just keep everything to myself. In my experience not only did I continuously get paid more but everything I wrote was FOSS so it helped improve my portfolio. The catch is you gotta work for great people, and that's hard to find. [0] Almost double the median household income for my area.
Hekioi 5y ago
Wow that's a next level shitty. Holy shit. I would not want you and your philosophy around me at all.
- dang 5y ago
  We've banned this account for breaking the site guidelines. 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 https://news.ycombinator.com/newsguidelines.html.
- BatteryMountain 5y ago
  I've taken the time this morning to read and comment on all the messages below my original comment. Please read them with empathy. The decisions are not coming from a malicious place. 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.
Mezzie 5y ago
This is one of the main advantages to being the token tech person in a non-tech group/organization: They have no idea how I do anything or how much time it might take. All explaining or sharing too much does is cut into my free time and possibly leads to additional competition in my niche. 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.
softwarebeware 5y ago
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 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.
- BatteryMountain 5y ago
  Number 3 is most common in my experience, esp in dev shops that uses Java. Very averse to things outside of their Java empires.
8589934591 5y ago
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.
BatteryMountain 5y ago
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!
rurban 5y ago
This only help msvc devs, who are in vendor lockin disadvantage anyway, and are always 10 hrs behind. Normal people used flymake on emacs for the last decades, recently switched to LSP feedback or VScode.

northisup 5y ago

wow, super happy I don't work with people like this.

toomuchtodo 5y ago
You wouldn’t know if you did.
- Philip-J-Fry 5y ago
  I would because they'd be more productive than me.
  - OnlineGladiator 5y ago
    They might be more efficient, but by working 1/4 as much they're equally productive!
    - toomuchtodo 5y ago
      Exactly. You get paid for your output, not your effort. Edit: A deleted reply said “You don't even really get paid for output. Output theatre pays better than output.” Great insight I thought worth persisting.
      - deleted 5y ago
        [deleted]
  - BatteryMountain 5y ago
    To be honest, I try my best to conceal my gains. I intentionally time my feedback to when it is expected of me.
- remus 5y ago
  You can probably make a good guess though. If you have conversations at work like bob: "hey come and check out this cool thing I made, I think it could save you a load of time" me: "woah, nice one bob, that's amazing! Let's roll this out to the other devs" then you're probably not working with someone like gp.
arbitrage 5y ago
The feeling's mutual, i assure you.
version_five 5y ago
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 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
- jayd16 5y ago
  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.
  - mmcgaha 5y ago
    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 coworkers have more time, he has less, and he is the scapegoat for when things go wrong. Not only that but since it is not a real product of the organization, no one will recognize the time he works on it so he will have to work over time to meet his other goals. Now if someone wants to ask for a copy of what I use, sure but they own their copy and I own mine.
    - jayd16 5y ago
      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.

awillen 5y ago

Why would they have to pay you a cool sum of money for it? It sounds pretty clearly like you did it for work, so unless you have a very unique employment contract, they already own it.

dheera 5y ago
Uh, because you could get 4X the "amount of shit" done in the same amount of time? So ideally they should pay you 4X.
dkersten 5y ago
For work sure, but it also sounds to me that it was built during personal time. 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)
- JohnFen 5y ago
  > (although I‘ve also never signed one of those “we own everything you do outside of work” clauses because I find them explosive and abusive) Me too. I always ask that it be removed from the contract, and so far, it always has been.
  - parksy 5y ago
    When I was working as a web developer for a company, I published a game I spent many years dreaming of, and in real terms thousands of hours learning and creating. I wrote the music, drew the sprites, coded the game loops, purchased all the tools, built it using my own hardware etc. The CFO at some party or other after a few beers told me if the game actually became successful, there was nothing I could do to stop them claiming ownership of all of the IP because of a clause I'd signed at some point. Since I left that place and I believe most of my time-limited terms have expired, IP is one of the very few things I'll get caught up on with a contract. I'm flexible around hours, reporting, attire, presence, etc, but IP outside of specifically client-related work activities is where I draw the line. I am a digital creator on my own time, I always have been since I was a child, I draw inspiration from many sources, whether it's work or books or videos or art, or even just a random thought. The notion that one day one of these things randomly becomes successful and a bevy of previous clients lays claim to the fruits of my labour sickens me to the core and goes against every sense of living in a fair and just society. I've knocked back clients who refuse to budge on this issue. I'm no Bill Gates or whatever, but there's absolutely no way I'm signing over rights to things I invent or innovate on my own time. If the people I work for want access to that additional service beyond whatever monkey-shit I'm doing for them then they can pay for it and not just swipe it through some boilerplate IP clauses.

RankingMember 5y ago

Making it broadly available could also potentially just set a new floor for productivity in an industry that doesn't always reward such gains commensurate with their value, i.e. you'd get an attaboy and "alright well now you can do three times as much work for the same pay!"

jdavis703 5y ago
Isn’t that the whole point of software engineering? You should always be engineering yourself out of your current job. If I’m dealing with the same issues I have today, a year from now, then I’d view that as a personal failure.
- eat_veggies 5y ago
  They engineered themselves out of their current job and still get paid for the job they don't have to do. Sounds like they engineered it pretty well.
- RankingMember 5y ago
  The whole point of engineering is to engineer yourself out of your current job? What? I think I must be misunderstanding you. Are people who engineer planes supposed to be engineering spacecraft or consider themselves failures or something? I'm confused.
  - toqy 5y ago
    They are supposed to engineer machines that engineer planes during their free time obviously
  - jdavis703 5y ago
    Good point. I meant us fake software engineering, not you real engineers with “PE” at the end of your name. My original comment has been clarified.
- literallyWTF 5y ago
  I hate this mindset. I’m not trying to make my job and the job of others obsolete. I just want to get paid so I can fuck off and do some other shit I want to do.

Aardwolf 5y ago

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

milesvp 5y ago
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 cognitive savings of realtime feedback.
- deleted 5y ago
  [deleted]
- JacobThreeThree 5y ago
  Without real time errors you can't get in a "flow"? That's hard to believe.
  - pixelbath 5y ago
    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.
  - milesvp 5y ago
    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.

albatross13 5y ago

Respect.

hallway_monitor 5y ago

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

willcipriano 5y ago
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.
- runevault 5y ago
  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.
  - pkdpic 5y ago
    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.
    - runevault 5y ago
      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.

uhtred 5y ago

I get this. If you tell people, and it gets released into the official tool chain, you will also probably then be its "owner". More work for you with no extra money.

deleted 5y ago
[deleted]
WesleyJohnson 5y ago
Not only that, but once the company owns it, they'll want to start managing it, making changes, etc. You run the risk of it becoming bloated with features, making it harder to maintain and the whole thing loses the reason it existed in the first place. Maybe that's a stretch, maybe not. 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.
BeetleB 5y ago
I was looking for this among all the responses. Surprised you're the only one who mentioned it. 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 :-)

bokchoi 5y ago

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

anthomtb 5y ago
It’s entirely possible that his colleagues have no desire to be helped, which can happen in a shitty organization.
- dylan604 5y ago
  Seems like better time spent on looking at how to get out of shitty org than gaming the system
  - slingnow 5y ago
    I'd be curious to see why you're so confident that OP's time is better spent getting out of this organization where they can work 2 hours a day for what I assume is a decent living.
    - dylan604 5y ago
      Financial wellness !== mental wellness.
  - ClumsyPilot 5y ago
    Its funny how gaming the system is 'innovation' for bosses and 'cheating' for employees
johnisgood 5y ago
As long as it is only known to colleagues, it is all good, but if word gets out (and the more people know about it and/or use it, the likelier it is), then they may get more work to do and such. Maybe the coworkers do not give a damn either way.
yourapostasy 5y ago
A possible reason is stack ranking in annual reviews. 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.

npmisdown 5y ago

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.

stillicidious 5y ago
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 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.
- grogenaut 5y ago
  I had a similar in 2000 during the .com bubble, interviewed at an ecomm company doing libraries, Amazon had not yet put them out of business. All c++ cgi. I asked a lot of questions about the stack and dev speed. They had looked at java but didn't have experience so were just going to plug along in c++. Their customers, libraries and book stores, didn't care. 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 ...
BatteryMountain 5y ago
I've also encountered this kind of apathy in other devs. I don't have a good answer what to do about it though.

dylan604 5y ago

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

benhurmarcel 5y ago
It’s unenforceable if they don’t know about it.
- dylan604 5y ago
  Sure, if you questionable morals.
cyberge99 5y ago
That’s a legal construct. The company owns it (in licensure), but he’s the sole user/operator if it.
- dylan604 5y ago
  Right, so if company finds out that you have code written on company time meant to be used to do company work, company can then say that all employs must be able to use that code. OR they could say that you can no longer use that code. No longer abiding by either mandate could be cause for dismissal. Legal construct or not, it is a work product that would be owned by the company. Using that code at a new company would be wrong as well.

onion2k 5y ago

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

BatteryMountain 5y ago
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.

alberth 5y ago

A lot of successful companies are founded this way (Eg HashiCorp, SAP, Basecamp, etc). 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.

htrp 5y ago
and more importantly, they get paid in line with what the tool is worth.

GartzenDeHaes 5y ago

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'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.

peterangular 5y ago
Having worked in an enterprise this list is 100% accurate. For better or worse (I think it's the latter) enterprises are all about coloring inside of the lines. If you color outside of the lines you may experience functional success in parallel to professional/social failure. 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.
- mring33621 5y ago
  Agree 100%. Also, there are some very quotable things in your comment. "experience functional success in parallel to professional/social failure" is my favorite, though. Thank you! Source: I work at a huge bank.
BatteryMountain 5y ago
Perfectly spot on. It's not about being malicious/apathetic but rather the things you mention above.

np- 5y ago

Kind of similar but maybe in a different context—there are a few tools that I’ve written for myself that speed my work up significantly but I haven’t widely disseminated. It’s not because I don’t want my coworkers to succeed, but more that my tools are directly mapped to the way my brain and hands work. Ie, I’m much more of a shell guy who likes to write command line scripts to speed things up while most of my coworkers prefer heavier IDE/tools/plugins to assist (no judgment either way, its just how our brains work). I offered some of my tools a few times but no one took me up so I don’t bother anymore. 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.

sibit 5y ago

When I was first started my career I was working at a small software company. I spent my evening and weekends building tools and plugins to optimize my workflow and I quickly became 10x more productive than my coworkers. I shared my tools with the company and in return, I was rewarded with raises year after year. I went from 30k to 80k[0] in 3 years. Now I work for a large software company and the same tactics haven't worked out in my favor so I just keep everything to myself. In my experience not only did I continuously get paid more but everything I wrote was FOSS so it helped improve my portfolio. The catch is you gotta work for great people, and that's hard to find. [0] Almost double the median household income for my area.

Hekioi 5y ago

Wow that's a next level shitty. Holy shit. I would not want you and your philosophy around me at all.

dang 5y ago
We've banned this account for breaking the site guidelines. 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 https://news.ycombinator.com/newsguidelines.html.
BatteryMountain 5y ago
I've taken the time this morning to read and comment on all the messages below my original comment. Please read them with empathy. The decisions are not coming from a malicious place. 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.

Mezzie 5y ago

This is one of the main advantages to being the token tech person in a non-tech group/organization: They have no idea how I do anything or how much time it might take. All explaining or sharing too much does is cut into my free time and possibly leads to additional competition in my niche. 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.

softwarebeware 5y ago

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

BatteryMountain 5y ago
Number 3 is most common in my experience, esp in dev shops that uses Java. Very averse to things outside of their Java empires.

8589934591 5y ago

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.

BatteryMountain 5y ago

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!

rurban 5y ago

This only help msvc devs, who are in vendor lockin disadvantage anyway, and are always 10 hrs behind. Normal people used flymake on emacs for the last decades, recently switched to LSP feedback or VScode.