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".
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.
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.
It's completely OK to have such a rule, your behavior is much more disturbing. It doesn't really matter if you use UK or US english, but you should use one and that must be pressured from above. If project standard is UK you use UK, not what you like.
Quitting because of that is just stupid. In my company CS rules are almost opposite to my preferences (and to common style for that language community of course). I use every opportunity to grumble about it, but it would be much worse if everybody (me included) shaped the code based on personal preferences, not style guide.
Because the spelling wasn't the root cause it was a symptom of a culture that had gone so badly wrong that people engaged in petty arguments just as a way to score points.
To be fair, a search and replace for "dialog" would also match patterns like, y'know, "dialogue" too, at least in all the naive replace-all algos I've seen in IDEs.
So, the traditional CTRL+F, or :%s/dialog/dialogue/g would have resulted in at least some instances of 'dialoguegue' as a result. Yeah, the obvious remedy there is :%s/guegue/gue/g, but that too could lead to unintended results, etc.
Not that I don't agree with the intent of your statement, search and replace across 20k lines of code, over however many files, is likely a more involved process than it sounds like.
"dialog" as part of a variable name with underscores:
:%s/dialog_/dialogue_/g
"dialog" as part of a variable name with CamelCase:
:%s/\([dD]\)ialog\([A-Z][A-z]*\)/\1ialogue\2/g
You don't need to capture every case in a single regex substitution, you can use a handful to cover pretty much every case though. This sort of change should not take more than a few minutes max of developer time.
I don't have experience with them, but I imagine an IDE with refactoring support should make these sort of changes trivial.
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.
Heh, you've basically avoided fully answering this question twice, possibly because it wasn't properly phrased. Let me give it one more shot.
What was _your_ reasoning for losing a job over a completely semantic argument?
Did the illogicality of it all really irk you so much that you couldn't stand to change it? What do you mean by saying that you couldn't 'comprehend' why variables should be written in UK English? It seems pretty clear that they should be in UK English because that's what you were told to write them in... at your job...
If this happened as described then I would have loved to be a coworker watching this hilariously petty feud unfold.
> What was _your_ reasoning for losing a job over a completely semantic argument?
I wanted a reasonable work environment that was delivering product to the customers, for the business.
The work in question was 20k lines and involved the whole stack. As it bled into web page stuff that actually had calls to browser open "dialog" commands, no find and replace was going to safely work to now make it comply with the clarification on the coding standards (UK English var names). We would spend weeks changing it and re-testing, weeks in which we were not delivering it.
I felt we were no longer working for either the customer or business, when we were willing to hold back an improvement that would immediately create revenue, for a petty argument.
It wasn't the first time I'd seen this architect do that to others, but I never thought it would happen to me so long as the product was good, the code was good, deadlines were met.
I was no longer convinced it was possible to create work that wouldn't fall foul of some rule or other. And the architect had managed to position himself on the org structure outside of a chain of command, so there was no-one to appeal to.
There are too many good jobs, and good companies, that want to ship product to their customers and build a great business to even consider staying somewhere that doesn't.
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?
Maybe he figured the work was done and wanted to move on to something else. It should have been a trivial issue, either way, and he wasn't the one making it a non-trivial issue. But the architect's propensity for blowing it out of proportion was a good signal that his working relationship with that architect was never going to be good, if something as simple as that was a problem.
I would have done the same thing. If someone is hanging your job over your head over spelling in source code, then the issue is no longer about spelling in source code. It's about dick wagging.
given that the complaint is how inflexible the senior tech was on the issue, why were you just as inflexible?"
Software engineers are a stubborn bunch. It's kind of necessary given the nature of programming. However, if promoted to an architect, stubbornness is a real problem, with little to no upside.
Architects will usually stick mostly to design and not do a lot of debugging. So that stubbornness is not useful. But it sure can rear its ugly head when it comes to pointless conflicts like this one. And the problem is, all the junior developers are also stubborn.
Welcome to software development. What you want in in a software architect is primarily a diplomat. Not someone who is stubborn.
I disagree. Before I went back to academia, I had both job titles at various times. The whole point of having someone in one of these "architect" roles is that they're supposed to be there to exercise judgment they have demonstrated to you as a company to be reliable.
If there's a disagreement that can't be resolved between the two of them, the architect is the one whose stubbornness I value more. You have managers to be diplomats. You have technical leadership to say, "they pay me more than you because they trust my judgment more than yours. I've heard your argument; I found it not compelling enough to overrule my own experience and judgment, and the decision has been made."
Ideally you have more than one such person to help surface the cases where the architect was wrong, but if you're routinely treating them as though they're no more reliable than junior developers, why are you paying them so much?
As an architect myself, I'm sure that some of the decisions I make look like bikeshedding - and maybe they are, but they're born out of a desire to make our services easier to implement and manage at scale. I do try to avoid arguments over trivia, but it's a fine line to walk. When you have a small system, the kinds of convention, indirection, and abstraction you'd see in large ones don't make a lot of sense, except when it comes time to scale out.
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.
I once worked at a company that made code to be owned by the gov't of Canada. I'm not sure if the government imposed the rules, but we did have strict rules to use Canadian word versions. Though this was like 1999 so I'd be shocked if that's still the case.
Edit: not to imply a reason for the noted situation, just an example to lend some credence/reasoning elsewhere
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.
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.
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").
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".