4 ms·

The other way is to just go skunk and fix a problem. Then if the fix works and people appreciate it, you get more latitude the next time you want to fix somethi

The other way is to just go skunk and fix a problem. Then if the fix works and people appreciate it, you get more latitude the next time you want to fix something. Getting pre-approval consensus is not really the way to go about those things, at least not in that kind of environment. Anything "important but not urgent" will not get the sufficient level of consensus. Generally if you're faced with a problem where you're certain people will find it worth the effort after it's done, but where you can't get approval beforehand, going skunk is the only way. Most of my steps forward in technical reputation have been from those efforts.

Trasmatta 5y ago
I'm not a fan of secret work like that. It can definitely depend on the size and composition of the team, though (and the size of the fix / improvement). Once a team gets sufficiently large, people going rogue with side projects like that can cause more harm than good, in my experience. Hurt feelings / resentment, because somebody else had already planned to fix that issue ("why didn't you just bring it up so we could discuss it first?"). It conflicts with some new feature another team is working on ("if we knew you were working on this, we would have done things differently; let us know next time"). Multiple people might decide to tackle the same problem concurrently, without knowing others are doing the same. You misunderstood something fundamental or lack some context that invalidates the entire solution that could have been cleared up by discussing it with the team first. And then maybe the biggest problem is the whole "putting in extra voluntary work" thing. Higher risk of burnout because you're spinning too many side project plates. Either your main work gets impacted, you start putting in overtime, or management starts thinking they're not giving you enough work, if you have all this time to do side stuff.
- deleted 5y ago
  [deleted]
- narcraft 5y ago
  Ok then don't do it
hsn915 5y ago
> The other way is to just go skunk and fix a problem. Then if the fix works and people appreciate it, you get more latitude the next time you want to fix something. This might surprise you but people don't like you fixing their mess behind their back. They take it as personal insult. They correctly recognize that you think what they did is messy and bad and you fixing it looks to them like an attempt to dethrone them from whatever little position they have carved for themselves within the organization.
- quickthrower2 5y ago
  Yes! I agree. Best to fix up code of people who are long gone instead. No one else will touch it so no merge conflicts either! Just make sure the fix makes others appreciate it. The populist fixes are fixes in dev tool chains that everyone in the team will appreciate. If you want a hobby just make any part of CI faster for some love from the team.
- __turbobrew__ 5y ago
  I guess it varies from person to person. If somebody fixed something I wrote without asking I would be thrilled! I recognize that I am imperfect, limited by time, and striving to move to more impactful projects so I would be more than happy if somebody wants to improve a system I was inexperienced with or didn’t have the time to fix. I would probably give them the low down on the system and try to transfer maintainership of the system to them.
  - exikyut 5y ago
    Reading the GP comment (going skunk), I wondered if the factors behind that turning out positively was the position of the fixer relative to the code/systems in question. If they're not stepping on anyone else's toes it works great. This comment echoes that sentiment a bit, I think; there's an implicit dependency in there on the project not having a collective structural investment, whether that's explicit (overt, with explicitly delineated boundaries) or implicit (implied, fuzzy, part of collective culture), on the thing being fixed.
- tunesmith 5y ago
cageface 5y ago
The risk here is that your fix might significantly improve the code in some way but also introduce a new bug or break some obscure feature. As a dev you're always sticking your neck out when you improve code in ways that aren't directly tangible to users or management. Leadership & management need to buy into the concept that code cleanup and refactoring are necessary but always carry some risk.

Trasmatta 5y ago

I'm not a fan of secret work like that. It can definitely depend on the size and composition of the team, though (and the size of the fix / improvement). Once a team gets sufficiently large, people going rogue with side projects like that can cause more harm than good, in my experience. Hurt feelings / resentment, because somebody else had already planned to fix that issue ("why didn't you just bring it up so we could discuss it first?"). It conflicts with some new feature another team is working on ("if we knew you were working on this, we would have done things differently; let us know next time"). Multiple people might decide to tackle the same problem concurrently, without knowing others are doing the same. You misunderstood something fundamental or lack some context that invalidates the entire solution that could have been cleared up by discussing it with the team first. And then maybe the biggest problem is the whole "putting in extra voluntary work" thing. Higher risk of burnout because you're spinning too many side project plates. Either your main work gets impacted, you start putting in overtime, or management starts thinking they're not giving you enough work, if you have all this time to do side stuff.

deleted 5y ago
[deleted]
narcraft 5y ago
Ok then don't do it

hsn915 5y ago

> The other way is to just go skunk and fix a problem. Then if the fix works and people appreciate it, you get more latitude the next time you want to fix something. This might surprise you but people don't like you fixing their mess behind their back. They take it as personal insult. They correctly recognize that you think what they did is messy and bad and you fixing it looks to them like an attempt to dethrone them from whatever little position they have carved for themselves within the organization.

quickthrower2 5y ago
Yes! I agree. Best to fix up code of people who are long gone instead. No one else will touch it so no merge conflicts either! Just make sure the fix makes others appreciate it. The populist fixes are fixes in dev tool chains that everyone in the team will appreciate. If you want a hobby just make any part of CI faster for some love from the team.
__turbobrew__ 5y ago
I guess it varies from person to person. If somebody fixed something I wrote without asking I would be thrilled! I recognize that I am imperfect, limited by time, and striving to move to more impactful projects so I would be more than happy if somebody wants to improve a system I was inexperienced with or didn’t have the time to fix. I would probably give them the low down on the system and try to transfer maintainership of the system to them.
- exikyut 5y ago
  Reading the GP comment (going skunk), I wondered if the factors behind that turning out positively was the position of the fixer relative to the code/systems in question. If they're not stepping on anyone else's toes it works great. This comment echoes that sentiment a bit, I think; there's an implicit dependency in there on the project not having a collective structural investment, whether that's explicit (overt, with explicitly delineated boundaries) or implicit (implied, fuzzy, part of collective culture), on the thing being fixed.
tunesmith 5y ago

cageface 5y ago

The risk here is that your fix might significantly improve the code in some way but also introduce a new bug or break some obscure feature. As a dev you're always sticking your neck out when you improve code in ways that aren't directly tangible to users or management. Leadership & management need to buy into the concept that code cleanup and refactoring are necessary but always carry some risk.