3 ms·

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 m

by 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 :-)
- behnamoh 5y ago
  Thanks for sharing. That's sad to hear. May I ask how you find out if management appreciates such productivity tools? In my experience, some people who seem really nice turn out to be extremely toxic and demanding once they find out my potential in doing things quickly and my quality work.
bsder 5y ago
Agreed. Ownership sucks and everybody will duck it even if they depend upon it. 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.
- BatteryMountain 5y ago
  Thank you for sharing. I've had one or two similar events over the years. I think often times people don't even know that they are indirectly using something or have indirect ownership of something. Only when switching it off does it get crystalized.
BatteryMountain 5y ago
We do currently have an abandoned tool in our chain that was built about 4 years ago but the guy ran away. We have yet to untangle his mess. Our operations/devops units kicks heavily against stuff like this for this very reason. 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.

by 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 :-)

behnamoh 5y ago
Thanks for sharing. That's sad to hear. May I ask how you find out if management appreciates such productivity tools? In my experience, some people who seem really nice turn out to be extremely toxic and demanding once they find out my potential in doing things quickly and my quality work.

bsder 5y ago

Agreed. Ownership sucks and everybody will duck it even if they depend upon it. 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.

BatteryMountain 5y ago
Thank you for sharing. I've had one or two similar events over the years. I think often times people don't even know that they are indirectly using something or have indirect ownership of something. Only when switching it off does it get crystalized.

BatteryMountain 5y ago

We do currently have an abandoned tool in our chain that was built about 4 years ago but the guy ran away. We have yet to untangle his mess. Our operations/devops units kicks heavily against stuff like this for this very reason. 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.