8 ms·

>That guy who decides to rewrite an entire system in his off-hours in a new language without telling anyone else? I have worked with this person on more than o

>That guy who decides to rewrite an entire system in his off-hours in a new language without telling anyone else? I have worked with this person on more than one occasion and I would love to work with them again. Entire new products and verticals are often the result of such projects. Companies have such a hard time dealing with risk. They think that the only appropriate thing is to always minimize risk. "Look, I have minimized risk at every opportunity. I am doing a great job!" That's not true all the time though. When exploring new business models or in some other situations high risk activity should be preferred.

tonecluster 10y ago
She talks about risk/reward and acknowledging the benefit new tech can bring to an organization. Minimizing risk doesn't mean no risk. High risk regardless of reward should not be preferred; risk/reward discussions and reasonable decisions should be preferred.
allengeorge 10y ago
Sometimes that behavior arises because the person is bored, or they feel their skills aren't being utilized, or they feel like their concerns about an existing system are being minimized.
- djsumdog 10y ago
  Yea, those people need to learn to work on their own stuff. I do so much of my own/oss work at work and am surprised at how everyone has always said I'm doing great and my stuff is always out faster and more tested than everyone else. ..expectations are low, and there's value in keeping it that way! :) (all my favoruite stuff has been stuff I've worked on for myself, that doesn't earn any money. I find almost all of it more worthwhile than any of the technical entrenched garbage I've written in the corporate world for the past decade of my life)
  - slig 10y ago
    I hope you realize that working on your own stuff at work can get you in trouble.
  - BostonEnginerd 10y ago
    Be careful with this. Companies often claim ownership of anything that you do during work hours.
    - cookiecaper 10y ago
      ...which can have wide-reaching implications if you release work product produced during work hours as OSS. While your company may seem like they don't care now, that can always change. Copyrights last a long time. Please don't risk the well-being of an open-source project by surreptitiously submitting code that your company owns.
      - bitL 10y ago
        Everybody should have an anonymous shell corp in Caribbean and release spare time work via those...
        cookiecaper 10y ago
        Seriously not a bad idea.
        eumoria 10y ago
        you're not part of the cabal so you'll just get insta-arrested
        eumoria 10y ago
        you're not part of the cabal so you'll just get insta-arrested
funkysquid 10y ago
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.
gaius 10y ago
Why does she care what anyone does in their free time? That corporate attitude that a company owns any IP you create, is the REAL problem.
- nkrisc 10y ago
  I think you're misinterpreting it. She's saying a person who rewrites (implied: and implements) a core process without informing other developers or product teams.
  - brazzledazzle 10y ago
    It would have been nice if they had been more specific. Judging by the comments that implication isn't obvious to everyone.
    - nkrisc 10y ago
      Yes, it could be more clear. As that interpretation seemed illogical and unrelated to the topic, I assumed that wasn't the intended meaning, however.
balls187 10y ago
> That guy who decides to rewrite an entire system in his off-hours in a new language without telling anyone else? I had a boss who came back from vacation that was so threatened by the automated testing harness myself and another coworker created, that she rewrote the entire system herself. It was very demoralizing.
- sqldba 10y ago
  I've seen this. Automated a bunch in well documented PowerShell modules which I trained staff on and was all taken out when I left. Because the PM said, "If it can be in a script it should be in C#!" Of course the C# programmers didn't like being taken off of productive work to build infrastructure tooling which was working perfectly well in PowerShell where it belonged. So they quit. So did the remaining DBA staff. All of them. So the company told their customers this feature was broken and would not be updated in the foreseeable future. That was a year or two ago. They could just run the script. But they refuse to on principle. So they suffer and the customers suffer. Companies are great!
tmaly 10y ago
I worked with that guy too, he left the company 4 years ago, and I am still maintaining his homebrew ORM that has no documentation or working tests.
- krisdol 10y ago
  Why didn't you rewrite it?
  - zilean 10y ago
    Writing documentation and tests would be a better way to address the pain point.
    - pm24601 10y ago
      This is victim-blaming. It would have been better yet if the person hadn't created work for others with this homebrewed ORM.
  - sqldba 10y ago
    Replacing a home brew ORM in an application of any scale is a massive time and bug investment. It will be tied into every single aspect of everything, and even into the build and database deploy processes. It often has its own classes with their own internal behaviour which get passed around raw - so you can't just upgrade one price of code and test and move on, you'll have to rewrite the entire product at once. Having seen it done I can understand very easily how someone could not just remove it.
    - tmaly 10y ago
      I have no choice but to replace it as the databases it accesses are changing. But as you said, it is a massive sink of time to change a core part of your system that some many other parts depend on.
coldtea 10y ago
>That guy who decides to rewrite an entire system in his off-hours in a new language without telling anyone else? Damn! I was thinking about doing that right today for a subsystem we use at work... trying to gauge its performance in the new language and eventually "sell" it to replace the existing one...
- cloverich 10y ago
  Its been a bit over generalized -- sometimes its a nice surprise. If that subsystem at work is a source of constant pain and annoyance, it may be welcomed with open arms. I think the case she's intending to illustrate is something like someone going rogue and re-writing a working system. In another language. Maybe a language that nobody really wants to use. They could have at least discussed it with their colleagues. Two (mostly) different scenarios!
wglb 10y ago
A couple of instances of this come to mind. One is Paul Graham's story of Trevor Blackwell rewriting the viaweb code in Smalltalk. Paul said No. Reddit was written originally in Lisp, but they rewrote it in Python. That stuck. I think that attributing resistance to the off-hours rewrite just because of minimizing risk is oversimplifying the issue.

tonecluster 10y ago

She talks about risk/reward and acknowledging the benefit new tech can bring to an organization. Minimizing risk doesn't mean no risk. High risk regardless of reward should not be preferred; risk/reward discussions and reasonable decisions should be preferred.

allengeorge 10y ago

Sometimes that behavior arises because the person is bored, or they feel their skills aren't being utilized, or they feel like their concerns about an existing system are being minimized.

djsumdog 10y ago
Yea, those people need to learn to work on their own stuff. I do so much of my own/oss work at work and am surprised at how everyone has always said I'm doing great and my stuff is always out faster and more tested than everyone else. ..expectations are low, and there's value in keeping it that way! :) (all my favoruite stuff has been stuff I've worked on for myself, that doesn't earn any money. I find almost all of it more worthwhile than any of the technical entrenched garbage I've written in the corporate world for the past decade of my life)
- slig 10y ago
  I hope you realize that working on your own stuff at work can get you in trouble.
- BostonEnginerd 10y ago
  Be careful with this. Companies often claim ownership of anything that you do during work hours.
  - cookiecaper 10y ago
    ...which can have wide-reaching implications if you release work product produced during work hours as OSS. While your company may seem like they don't care now, that can always change. Copyrights last a long time. Please don't risk the well-being of an open-source project by surreptitiously submitting code that your company owns.
    - bitL 10y ago
      Everybody should have an anonymous shell corp in Caribbean and release spare time work via those...
      - cookiecaper 10y ago
        Seriously not a bad idea.
      - eumoria 10y ago
        you're not part of the cabal so you'll just get insta-arrested
      - eumoria 10y ago
        you're not part of the cabal so you'll just get insta-arrested

funkysquid 10y ago

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.

gaius 10y ago

Why does she care what anyone does in their free time? That corporate attitude that a company owns any IP you create, is the REAL problem.

nkrisc 10y ago
I think you're misinterpreting it. She's saying a person who rewrites (implied: and implements) a core process without informing other developers or product teams.
- brazzledazzle 10y ago
  It would have been nice if they had been more specific. Judging by the comments that implication isn't obvious to everyone.
  - nkrisc 10y ago
    Yes, it could be more clear. As that interpretation seemed illogical and unrelated to the topic, I assumed that wasn't the intended meaning, however.

balls187 10y ago

> That guy who decides to rewrite an entire system in his off-hours in a new language without telling anyone else? I had a boss who came back from vacation that was so threatened by the automated testing harness myself and another coworker created, that she rewrote the entire system herself. It was very demoralizing.

sqldba 10y ago
I've seen this. Automated a bunch in well documented PowerShell modules which I trained staff on and was all taken out when I left. Because the PM said, "If it can be in a script it should be in C#!" Of course the C# programmers didn't like being taken off of productive work to build infrastructure tooling which was working perfectly well in PowerShell where it belonged. So they quit. So did the remaining DBA staff. All of them. So the company told their customers this feature was broken and would not be updated in the foreseeable future. That was a year or two ago. They could just run the script. But they refuse to on principle. So they suffer and the customers suffer. Companies are great!

tmaly 10y ago

I worked with that guy too, he left the company 4 years ago, and I am still maintaining his homebrew ORM that has no documentation or working tests.

krisdol 10y ago
Why didn't you rewrite it?
- zilean 10y ago
  Writing documentation and tests would be a better way to address the pain point.
  - pm24601 10y ago
    This is victim-blaming. It would have been better yet if the person hadn't created work for others with this homebrewed ORM.
- sqldba 10y ago
  Replacing a home brew ORM in an application of any scale is a massive time and bug investment. It will be tied into every single aspect of everything, and even into the build and database deploy processes. It often has its own classes with their own internal behaviour which get passed around raw - so you can't just upgrade one price of code and test and move on, you'll have to rewrite the entire product at once. Having seen it done I can understand very easily how someone could not just remove it.
  - tmaly 10y ago
    I have no choice but to replace it as the databases it accesses are changing. But as you said, it is a massive sink of time to change a core part of your system that some many other parts depend on.

coldtea 10y ago

>That guy who decides to rewrite an entire system in his off-hours in a new language without telling anyone else? Damn! I was thinking about doing that right today for a subsystem we use at work... trying to gauge its performance in the new language and eventually "sell" it to replace the existing one...

cloverich 10y ago
Its been a bit over generalized -- sometimes its a nice surprise. If that subsystem at work is a source of constant pain and annoyance, it may be welcomed with open arms. I think the case she's intending to illustrate is something like someone going rogue and re-writing a working system. In another language. Maybe a language that nobody really wants to use. They could have at least discussed it with their colleagues. Two (mostly) different scenarios!

wglb 10y ago

A couple of instances of this come to mind. One is Paul Graham's story of Trevor Blackwell rewriting the viaweb code in Smalltalk. Paul said No. Reddit was written originally in Lisp, but they rewrote it in Python. That stuck. I think that attributing resistance to the off-hours rewrite just because of minimizing risk is oversimplifying the issue.