5 ms·

As one of these problem people myself, it's helpful to know that this is considered bad behavior. I'm not sure it should be though... The thought process is th

As one of these problem people myself, it's helpful to know that this is considered bad behavior. I'm not sure it should be though... The thought process is that many times the barrier to adopting a better technology is just the time investment. So if you're sick of working with a problematic system, but the team doesn't have the time to fix it, fixing it away from work might remove that pain point from your life. And since often these projects begin and even end as just an experiment, there's not much reason to tell the team until you have something. It doesn't really seem to have much of a downside - assuming you're just presenting whatever you come up with to the team later as an option, and not going crazy and replacing production systems without asking.

danso 10y ago
> It doesn't really seem to have much of a downside - assuming you're just presenting whatever you come up with to the team later as an option, and not going crazy and replacing production systems without asking. That's a big if. The fear is that such a person doesn't have the judgment to not be the type of person who goes into personal-overdrive into making unfeasible changes (or, worse, into bikeshedding). It doesn't mean that such a person is a horrible person, just that opening lines of communication should be a priority, rather than letting that person put themselves in a position of difficulty.
erikb 10y ago
Don't take these articles too seriously. There are a lot of reasons people consider someone a troublemaker. It's more about your 1:1 connection to other people than what category of person you are.
- sdegutis 10y ago
  Yeah, in general, it's good practice to not take any article on HN seriously. Assume that the article's author and every commenter may not be experts at the thing(s) they're claiming to be. Especially when there's social aspects involved.
kazinator 10y ago
It's okay to rewrite whatever you want in off hours. Just deploying it without consulting with anyone in place of the original production system would be a poor quality behavior. If you think you have something, make an isolated test deployment of it for internal evaluation, and so on. No matter how the existing system sucks, at least it has some mileage in deployment and has been through some QA.
cookiecaper 10y ago
Independent of social context, this type of act is generally viewed favorably. Machiavelli claims that "nothing makes a Prince so well thought of as to undertake great enterprises and give striking proofs of his capacity." [0] How this would go down in your particular workplace all depends on the surrounding political and social context. It could either be interpreted as "Wow, that guy is such an amazing programmer that he was able to refactor our whole legacy system in his spare time! We should definitely keep him on board and learn from this kind of work, even if we can't do a full-scale replacement." or "Wow, that guy is so self-absorbed and unwilling to cooperate with his teammates that he went home in a fit of anger and thought he could replace 10 years of work in a few weekends! What an abrasive blowhard. Let's fire him next time he gives us an excuse." The halo effect is going to be the primary determinant here. [1] If your colleagues and superiors are predisposed to interpret your actions favorably, they'll probably do so until you give them a reason not to, and vice-versa. It takes a lot of work to maintain a good halo, and it should be considered your primary job duty if you wish to have a fulfilling career as an employee. Humans are social animals and will evaluate everything about you, including your technical competence, by the social signals you output. Successfully managing these can get complicated in the workplace due to the competing interests of the people you come into contact with during the course of your employment. [0] https://en.wikisource.org/wiki/The_Prince_%28Hill_Thomson%29/Chapter_XXI https://en.wikisource.org/wiki/The_Prince_%28Hill_Thomson%29... [1] https://en.wikipedia.org/wiki/Halo_effect https://en.wikipedia.org/wiki/Halo_effect
scubaguy 10y ago
The "without telling anyone else" part is potentially the problem. Imagine you committed time and energy to build a decent system - not perfect, but most people are ok with. You feel a sense of ownership on this system. Then one day, a coworker of your tells your manager that he has built a new system in his off time. He also made a conscious decision not to discuss the effort with you. How would that make you feel?
- SerLava 10y ago
  >How would that make you feel? Like manning up. This is snark, but I'm actually being pretty serious here. I would want to know if the new system is going to make everyone's lives easier.
  - SideburnsOfDoom 10y ago
    > I would want to know if the new system is going to make everyone's lives easier. If it's a large system designed by a person on their own in a corner, without interaction, without feedback on features and usability? ... it's unlikely to and I would be rightly wary. I have however seen existing systems that have pain points that everyone complains about but no-body has the time for fixing, until someone finally takes a few days out to experiment with something different, and sometimes the results are excellent. But IMHO that's not exactly a "rewrite".
    - jdbernard 10y ago
      It very much depends on who that person in the corner is. I've seen junior devs waste a lot of time doing this. However, I have seen one or two examples of a senior dev solving a real pain-point that wasn't getting fixed within the system, for one reason or another.
      - SideburnsOfDoom 10y ago
        Right; for me the determining factors between the two cases are: 1) It is a known pain point, so the problem has been discussed. Probably a lot. The pain is the reason for the code, and if there's a new tool involved, that's additional not a main reason. 2) it's usually a technical task - for example something related to faster, more reliable deployments. This means that the requirements are already well-known by the engineer, and that it probably hasn't been addressed yet as it's hard to tie to a business benefit. 3) Experience of the engineer. Senior devs are more likely to chose a good target.
orionblastar 10y ago
I often would suggest rewriting apps in a different language or platform. Management had a problem with our ActiceX based web apps not working with Macs or OS/2 machines. I offered to rewrite them to use Java instead and I was told no because Java wasn't made by Microsoft and if I wrote anything in Java I'd be fired. Another job I aaw that VB 6.0 and Windows 98 was too slow and I offered to rewrite the app in C ir C++ and use GNU/Linux to make it faster. Same problem not Microsoft so management didn't want me to rewrite it.
pm24601 10y ago
What aren't you doing while you are going off and being a super hero? Are you disobeying your manager's direction? (And thereby undercutting their creditability/authority - and how does that make the manager appear to their supers/peers?) Why can't you go to your manager and ask for permission? If not, why not? How would you feel if your "great" rewrite is rejected - because someone else was already doing the rewrite; or because the system is going to be redesign entirely? (For example, the code will be ported from .NET to Java - and all the .NET code will be discarded) If you haven't yet, try being a manager for a while and then see if you still think that this sort of troublemaker.

danso 10y ago

> It doesn't really seem to have much of a downside - assuming you're just presenting whatever you come up with to the team later as an option, and not going crazy and replacing production systems without asking. That's a big if. The fear is that such a person doesn't have the judgment to not be the type of person who goes into personal-overdrive into making unfeasible changes (or, worse, into bikeshedding). It doesn't mean that such a person is a horrible person, just that opening lines of communication should be a priority, rather than letting that person put themselves in a position of difficulty.

erikb 10y ago

Don't take these articles too seriously. There are a lot of reasons people consider someone a troublemaker. It's more about your 1:1 connection to other people than what category of person you are.

sdegutis 10y ago
Yeah, in general, it's good practice to not take any article on HN seriously. Assume that the article's author and every commenter may not be experts at the thing(s) they're claiming to be. Especially when there's social aspects involved.

kazinator 10y ago

It's okay to rewrite whatever you want in off hours. Just deploying it without consulting with anyone in place of the original production system would be a poor quality behavior. If you think you have something, make an isolated test deployment of it for internal evaluation, and so on. No matter how the existing system sucks, at least it has some mileage in deployment and has been through some QA.

cookiecaper 10y ago

Independent of social context, this type of act is generally viewed favorably. Machiavelli claims that "nothing makes a Prince so well thought of as to undertake great enterprises and give striking proofs of his capacity." [0] How this would go down in your particular workplace all depends on the surrounding political and social context. It could either be interpreted as "Wow, that guy is such an amazing programmer that he was able to refactor our whole legacy system in his spare time! We should definitely keep him on board and learn from this kind of work, even if we can't do a full-scale replacement." or "Wow, that guy is so self-absorbed and unwilling to cooperate with his teammates that he went home in a fit of anger and thought he could replace 10 years of work in a few weekends! What an abrasive blowhard. Let's fire him next time he gives us an excuse." The halo effect is going to be the primary determinant here. [1] If your colleagues and superiors are predisposed to interpret your actions favorably, they'll probably do so until you give them a reason not to, and vice-versa. It takes a lot of work to maintain a good halo, and it should be considered your primary job duty if you wish to have a fulfilling career as an employee. Humans are social animals and will evaluate everything about you, including your technical competence, by the social signals you output. Successfully managing these can get complicated in the workplace due to the competing interests of the people you come into contact with during the course of your employment. [0] https://en.wikisource.org/wiki/The_Prince_%28Hill_Thomson%29/Chapter_XXI https://en.wikisource.org/wiki/The_Prince_%28Hill_Thomson%29... [1] https://en.wikipedia.org/wiki/Halo_effect https://en.wikipedia.org/wiki/Halo_effect

scubaguy 10y ago

The "without telling anyone else" part is potentially the problem. Imagine you committed time and energy to build a decent system - not perfect, but most people are ok with. You feel a sense of ownership on this system. Then one day, a coworker of your tells your manager that he has built a new system in his off time. He also made a conscious decision not to discuss the effort with you. How would that make you feel?

SerLava 10y ago
>How would that make you feel? Like manning up. This is snark, but I'm actually being pretty serious here. I would want to know if the new system is going to make everyone's lives easier.
- SideburnsOfDoom 10y ago
  > I would want to know if the new system is going to make everyone's lives easier. If it's a large system designed by a person on their own in a corner, without interaction, without feedback on features and usability? ... it's unlikely to and I would be rightly wary. I have however seen existing systems that have pain points that everyone complains about but no-body has the time for fixing, until someone finally takes a few days out to experiment with something different, and sometimes the results are excellent. But IMHO that's not exactly a "rewrite".
  - jdbernard 10y ago
    It very much depends on who that person in the corner is. I've seen junior devs waste a lot of time doing this. However, I have seen one or two examples of a senior dev solving a real pain-point that wasn't getting fixed within the system, for one reason or another.
    - SideburnsOfDoom 10y ago
      Right; for me the determining factors between the two cases are: 1) It is a known pain point, so the problem has been discussed. Probably a lot. The pain is the reason for the code, and if there's a new tool involved, that's additional not a main reason. 2) it's usually a technical task - for example something related to faster, more reliable deployments. This means that the requirements are already well-known by the engineer, and that it probably hasn't been addressed yet as it's hard to tie to a business benefit. 3) Experience of the engineer. Senior devs are more likely to chose a good target.

orionblastar 10y ago

I often would suggest rewriting apps in a different language or platform. Management had a problem with our ActiceX based web apps not working with Macs or OS/2 machines. I offered to rewrite them to use Java instead and I was told no because Java wasn't made by Microsoft and if I wrote anything in Java I'd be fired. Another job I aaw that VB 6.0 and Windows 98 was too slow and I offered to rewrite the app in C ir C++ and use GNU/Linux to make it faster. Same problem not Microsoft so management didn't want me to rewrite it.

pm24601 10y ago

What aren't you doing while you are going off and being a super hero? Are you disobeying your manager's direction? (And thereby undercutting their creditability/authority - and how does that make the manager appear to their supers/peers?) Why can't you go to your manager and ask for permission? If not, why not? How would you feel if your "great" rewrite is rejected - because someone else was already doing the rewrite; or because the system is going to be redesign entirely? (For example, the code will be ported from .NET to Java - and all the .NET code will be discarded) If you haven't yet, try being a manager for a while and then see if you still think that this sort of troublemaker.