7 ms·

It really surprises me that somebody can get away with such destructive behaviour as reverting someone else's commits without reasonable cause. What justificati

It really surprises me that somebody can get away with such destructive behaviour as reverting someone else's commits without reasonable cause. What justification is there for not firing on the spot anybody who puts their own personal vendettas over the good of the project?

buro9 13y ago
I once quit a senior dev role as the tech architect at the company had veto power on all code and blocked my work because I'd spelled the word dialog the US way, rather than the UK way (dialogue). This was not in a public interface, this was in variable names. Ignoring that every word in programming is in US English: color, gray, program. We were deadlocked for weeks, with him refusing to ship working code that fulfilled the business goals over this single issue. Quitting resolved the deadlock, and I learned afterwards that he really did go through the work and change it all to "dialogue".
- Allan_Smithee 13y ago
  "Ignoring that every word in programming is in US English: color, gray, program." The parochialism of the wannabe "hacker" (entreprenerd) here used to be cute.
- logicchains 13y ago
  What did senior management think of this? I can't imagine them taking kindly to the architect delaying shipping for weeks over such a trivial thing.
  - buro9 13y ago
    At the time he was viewed as critical to the project. They indulged him. A very steady stream of very good devs leaving the company occurred because of such invented rules and irrational behaviour. He was a truly great dev, but a fairly insane architect and gatekeeper.
    - logicchains 13y ago
      I wonder if they financial benefit they gained from keeping him around was greater than the financial loss due to continuously losing good devs...
- Pacabel 13y ago
  Why was it so critical to spell it "dialog", rather than "dialogue", as the higher-ups in the project apparently preferred?
  - buro9 13y ago
    It wasn't, there was no business justification for it at all. He just invented a rule "all names and variables must be in UK English".
    - cunac 13y ago
      did you know about rule before start writing piece of code in question ? If yes, I really don't see how you can say in good faith that it wasn't your mistake to be fixed.
    - gphilip 13y ago
      GP asked the converse.
      - buro9 13y ago
        Good spot (I missed it). I spelled it in consistency with everything else in the source code at that time... US English. It was a British company, and I understood that the UI should be UK English, but did not comprehend/believe that variables should be too. Especially as one can't force CSS to stop calling it color.
        deong 13y ago
        I still don't think that's actually the question that was being asked. It's not, "why do you think your spelling was preferred?" but rather "given that the complaint is how inflexible the senior tech was on the issue, why were you just as inflexible?" Particularly given that it's a UK company, the request may be arguably wrong, but it's at least semi-reasonable. Why make such a huge deal over it from either side?
        13y ago
- 005-18 13y ago
  Sounds like two stubborn people. Unless you were taking a "stand" to make a point about a larger issue I don't see that you did anything better to fulfill the business goals.
- asdkl234890 13y ago
  It's a good thing for hackers/programmers/engineers to be stubborn.... up to a point, but the one thing an architect should not be is stubborn. And yet architects usually originate from promoted engineers. And that means they are stubborn, and the result is all kinds pointless conflicts with all the other developers.
  - d4nt 13y ago
    The fact that the tech architect spent any time at all contemplating this issue is a massive red flag to me. Technical Architecture should be about making the right set of trade offs given the business goals of the system being developed. That involves spending a lot of time talking to people both inside and outside of dev team about what the goals are and how the decisions that devs are making are impacting everyone else in the company. That stuff is time consuming, but if there's any time left you should really be keeping up with the latest frameworks and tools. If you're spending your time reviewing commits and enforcing coding standards, you're doing it wrong.
    - deleted 13y ago
      [deleted]
- leephillips 13y ago
  Since these were variable names they didn't have to be real words. So you should have explained that your "dialog" was not the American spelling of "dialogue", but a nonsense non-word that you made up (that happened to be spelled the same way as the American version of "dialogue").
jessaustin 13y ago
If Evil Coder sends an email to Noble Coder describing the vendetta-motivated reversions, then sure, something might happen. When would it ever be so obvious, however? If this is done quietly, and Noble happens to work in different parts of the codebase every cycle, she might not even realize the reversions have occurred for a few cycles. Even then, many people would assume there was some fair-minded rationale the first few times. After it is clear that something is going on, Noble can make a stink, but she might also just want to cut her losses and make a lateral move.
- logicchains 13y ago
  Hmm. I suppose that's a disadvantage of having a less formal code-review process, compared to one in which the reverter would have to specify a reason for each reversion, making it easier to detect spurious reversions.
  - greenrd 13y ago
    You'd think that a site like GitHub would have mandated code review for all commits by now. Especially after that time a few years ago when they managed to accidentally delete all the pull requests in the entire site, or something like that! Wait, they're a ruby shop, they don't even believe in letting the compiler help you avoid making basic mistakes. dons flame-retardant suit
    - couchand 13y ago
      It should be obvious that that's a false equality.
einhverfr 13y ago
> It really surprises me that somebody can get away with such destructive behaviour as reverting someone else's commits without reasonable cause. What justification is there for not firing on the spot anybody who puts their own personal vendettas over the good of the project? And yet it happens everywhere. The question is what narratives can be told about it more than what actually happened.
- acjohnson55 13y ago
  I've never been anywhere where this sort of behavior happened. If management can't nip things like that in the bud, they aren't doing their jobs.
  - einhverfr 13y ago
    I have seen vendettas handled in crazy ways in a few different places. People figure out what they can get away with.
ChuckMcM 13y ago
At Sun, where there was a structured management chain, there was a time when one of the folks in my group reverted a big chunk of changes I had committed, and I went to our common manager and demanded satisfaction. The response was 'if we left them in he threatened to quit, there isn't anything we can do', and the only conclusion from that statement was that if one of us quit, the manager would rather it were me than this other person. Needless to say it was really annoying.
- danielweber 13y ago
  And thus "threatening to quit" becomes the way for the crazy dudes to get whatever they want.
  - teacup50 13y ago
    They're not crazy, and it only works if they have more political capital than you do. If I was forced to accept substandard work, and had no other choice but either maintain that bad code, or quit, I'd threaten to quit too.
    - dmur 13y ago
      No, they are crazy. Reverting someone else's changes without explaining why is crazy. No one is telling these people they can't explain their actions. If any of these people has a disagreement with a co-worker over the co-worker's changes, it's their duty as a fellow employee to explain to the co-worker why they disagree, or at least explain to the manager why they disagree with the change, so that the manager can explain it to the co-worker. But just making the change and then threatening to quit... that is most definitely crazy.
      - cbsmith 13y ago
        Just want to clarify that my response here is not related to the GitHub story. I have no knowledge of the circumstances that aren't in the story. > No, they are crazy. That may be. > Reverting someone else's changes without explaining why is crazy. Not necessarily. There are times when you are so wrong you aren't even wrong. > If any of these people has a disagreement with a co-worker over the co-worker's changes, it's their duty as a fellow employee to explain to the co-worker why they disagree, or at least explain to the manager why they disagree with the change, so that the manager can explain it to the co-worker. Let's imagine a scenario where they had done this, and yet nothing had corrected the problem. At that point, it would be quite reasonable to revert someone's changes without explaining why, and threatening to quit if one wasn't allowed to.

buro9 13y ago

I once quit a senior dev role as the tech architect at the company had veto power on all code and blocked my work because I'd spelled the word dialog the US way, rather than the UK way (dialogue). This was not in a public interface, this was in variable names. Ignoring that every word in programming is in US English: color, gray, program. We were deadlocked for weeks, with him refusing to ship working code that fulfilled the business goals over this single issue. Quitting resolved the deadlock, and I learned afterwards that he really did go through the work and change it all to "dialogue".

Allan_Smithee 13y ago
"Ignoring that every word in programming is in US English: color, gray, program." The parochialism of the wannabe "hacker" (entreprenerd) here used to be cute.
logicchains 13y ago
What did senior management think of this? I can't imagine them taking kindly to the architect delaying shipping for weeks over such a trivial thing.
- buro9 13y ago
  At the time he was viewed as critical to the project. They indulged him. A very steady stream of very good devs leaving the company occurred because of such invented rules and irrational behaviour. He was a truly great dev, but a fairly insane architect and gatekeeper.
  - logicchains 13y ago
    I wonder if they financial benefit they gained from keeping him around was greater than the financial loss due to continuously losing good devs...
Pacabel 13y ago
Why was it so critical to spell it "dialog", rather than "dialogue", as the higher-ups in the project apparently preferred?
- buro9 13y ago
  It wasn't, there was no business justification for it at all. He just invented a rule "all names and variables must be in UK English".
  - cunac 13y ago
    did you know about rule before start writing piece of code in question ? If yes, I really don't see how you can say in good faith that it wasn't your mistake to be fixed.
  - gphilip 13y ago
    GP asked the converse.
    - buro9 13y ago
      Good spot (I missed it). I spelled it in consistency with everything else in the source code at that time... US English. It was a British company, and I understood that the UI should be UK English, but did not comprehend/believe that variables should be too. Especially as one can't force CSS to stop calling it color.
      - deong 13y ago
        I still don't think that's actually the question that was being asked. It's not, "why do you think your spelling was preferred?" but rather "given that the complaint is how inflexible the senior tech was on the issue, why were you just as inflexible?" Particularly given that it's a UK company, the request may be arguably wrong, but it's at least semi-reasonable. Why make such a huge deal over it from either side?
        13y ago
005-18 13y ago
Sounds like two stubborn people. Unless you were taking a "stand" to make a point about a larger issue I don't see that you did anything better to fulfill the business goals.
asdkl234890 13y ago
It's a good thing for hackers/programmers/engineers to be stubborn.... up to a point, but the one thing an architect should not be is stubborn. And yet architects usually originate from promoted engineers. And that means they are stubborn, and the result is all kinds pointless conflicts with all the other developers.
- d4nt 13y ago
  The fact that the tech architect spent any time at all contemplating this issue is a massive red flag to me. Technical Architecture should be about making the right set of trade offs given the business goals of the system being developed. That involves spending a lot of time talking to people both inside and outside of dev team about what the goals are and how the decisions that devs are making are impacting everyone else in the company. That stuff is time consuming, but if there's any time left you should really be keeping up with the latest frameworks and tools. If you're spending your time reviewing commits and enforcing coding standards, you're doing it wrong.
  - deleted 13y ago
    [deleted]
leephillips 13y ago
Since these were variable names they didn't have to be real words. So you should have explained that your "dialog" was not the American spelling of "dialogue", but a nonsense non-word that you made up (that happened to be spelled the same way as the American version of "dialogue").

jessaustin 13y ago

If Evil Coder sends an email to Noble Coder describing the vendetta-motivated reversions, then sure, something might happen. When would it ever be so obvious, however? If this is done quietly, and Noble happens to work in different parts of the codebase every cycle, she might not even realize the reversions have occurred for a few cycles. Even then, many people would assume there was some fair-minded rationale the first few times. After it is clear that something is going on, Noble can make a stink, but she might also just want to cut her losses and make a lateral move.

logicchains 13y ago
Hmm. I suppose that's a disadvantage of having a less formal code-review process, compared to one in which the reverter would have to specify a reason for each reversion, making it easier to detect spurious reversions.
- greenrd 13y ago
  You'd think that a site like GitHub would have mandated code review for all commits by now. Especially after that time a few years ago when they managed to accidentally delete all the pull requests in the entire site, or something like that! Wait, they're a ruby shop, they don't even believe in letting the compiler help you avoid making basic mistakes. dons flame-retardant suit
  - couchand 13y ago
    It should be obvious that that's a false equality.

einhverfr 13y ago

> It really surprises me that somebody can get away with such destructive behaviour as reverting someone else's commits without reasonable cause. What justification is there for not firing on the spot anybody who puts their own personal vendettas over the good of the project? And yet it happens everywhere. The question is what narratives can be told about it more than what actually happened.

acjohnson55 13y ago
I've never been anywhere where this sort of behavior happened. If management can't nip things like that in the bud, they aren't doing their jobs.
- einhverfr 13y ago
  I have seen vendettas handled in crazy ways in a few different places. People figure out what they can get away with.

ChuckMcM 13y ago

At Sun, where there was a structured management chain, there was a time when one of the folks in my group reverted a big chunk of changes I had committed, and I went to our common manager and demanded satisfaction. The response was 'if we left them in he threatened to quit, there isn't anything we can do', and the only conclusion from that statement was that if one of us quit, the manager would rather it were me than this other person. Needless to say it was really annoying.

danielweber 13y ago
And thus "threatening to quit" becomes the way for the crazy dudes to get whatever they want.
- teacup50 13y ago
  They're not crazy, and it only works if they have more political capital than you do. If I was forced to accept substandard work, and had no other choice but either maintain that bad code, or quit, I'd threaten to quit too.
  - dmur 13y ago
    No, they are crazy. Reverting someone else's changes without explaining why is crazy. No one is telling these people they can't explain their actions. If any of these people has a disagreement with a co-worker over the co-worker's changes, it's their duty as a fellow employee to explain to the co-worker why they disagree, or at least explain to the manager why they disagree with the change, so that the manager can explain it to the co-worker. But just making the change and then threatening to quit... that is most definitely crazy.
    - cbsmith 13y ago
      Just want to clarify that my response here is not related to the GitHub story. I have no knowledge of the circumstances that aren't in the story. > No, they are crazy. That may be. > Reverting someone else's changes without explaining why is crazy. Not necessarily. There are times when you are so wrong you aren't even wrong. > If any of these people has a disagreement with a co-worker over the co-worker's changes, it's their duty as a fellow employee to explain to the co-worker why they disagree, or at least explain to the manager why they disagree with the change, so that the manager can explain it to the co-worker. Let's imagine a scenario where they had done this, and yet nothing had corrected the problem. At that point, it would be quite reasonable to revert someone's changes without explaining why, and threatening to quit if one wasn't allowed to.