Whilst improvements shouldn't be done ad-hoc without consideration, I think the concept of "left alone" applies more easily to the concept of natural spaces. In code it is really stretching the metaphor to do much more than very basic tasks like renaming or code formatting (e.g. picking up trash). Adding a test doesn't feel like "left alone".
One of the examples in the article is upgrading a dependency. This could easily fall into the category you mention if the upgrade itself is not properly tested. A considered approach would be:
"I want to make a small improvement, oh I see this dependency is out of date and has some minor vulnerabilities or perf issues, or is missing a feature that could come in handy for XYZ. Hmm, there are no tests confirming our assumptions about the current library version, nor are then any tests are our code / systems that use it. I guess my improvement should be to add those tests, then next time someone has the same idea it'll be an easier upgrade"
I am unsure but I also interpret from your first sentence that you may have seen people use this rule as a defence for gold plating (the opposite of KISS or YAGNI). Similarly this should fall under the heading of changes made without proper discussion, thought or consideration.
Otherwise I think we're really stuck, if team members cannot be trusted to properly interpret the boy scout rule without messing up a codebase then how on earth can they be trusted to build the foundation of their company / team / system?
"left alone" corresponds to how it was designed. Your task is to push the code a little closer to the design, which always has compromises in implementation.
The big fights come in (as seen in comments in this post already) when there was no original design, and it's mess vs possibly dubious attempts to clean up the mess.
I think another possibility in addition to what you mentioned is that the original design was incorrect, or even just not very optimal. Just as an aside.
However this is all becoming a wide ranging statement about the entire job of a dev team. So far removed from the extremely innocuous advice of the article around "make small improvements regularly". Whilst you can apply caveats to that around "test your improvements", "check your improvement with others more familiar with that code" etc etc, these are all things that should be expected of a professional. At the risk of talking about no-true-scotsman.
If someone cannot be trusted with the advice "make small improvements regularly" then what the f* can they be trusted with?
This sounds very different to the process described in post. Are you raising this anecdote as an argument against the boy scout rule?
I don't think you would find many people who would consider his actions a reasonable interpretation of it. I think this person would cause damage regardless of their motto or underlying intent.
Taking a leaf from the guidelines for person-to-person,discussion on this forum about arguing against the strongest version of your opponents argument: I think there is great value to lots of small improvements over a long period of time (no silver bullet etc). Certainly it should be tempered with the knowledge that the change is indeed an improvement. That can usually only be decided by the person who originally wrote it OR a consesus of the team involved.
The problem is that there is no objective measure of "better". The consultant did think he was leaving the code better than he found it.
I've worked on codebases where the whole team agrees a certain part of the codebase needs to be refactored, but we all also agree it is way too dangerous. Which is better? Working but hard to maintain spaghetti code, or clean, new, and broken code?
I think the all or nothing view may be the problem 'maintain spaghetti code' vs 'clean/new code'. When one inherits a code base like that one should start small. Write an automated test that tests a single scenario, add a comment that explains something particularly difficult that a developer spent a lot of time on finding out. Rename one single variable somewhere. Then gradually as one gains more knowledge start doing bigger refactors and bring more of the code under tests. It sounds like what has happened here is that a big bang rewrite was undertaken. This is almost always ill-advised.
I like to use the model that humans can only grasp so much, and that only increases slowly if at all, so on a mature project you have to try to keep the amount of stuff to remember constant. New code that adds new concepts needs to be counterbalanced by simplifying things elsewhere. As the inherent complexity increases, chip away at the accidental.
I sweeten the pot with management by pointing out that if you do this, it’s easier to ramp up new people. If you can ramp up new people, you can absorb new customers without making a fool of yourself in the process. We should want to be able to take on big new customers, right?
So for the consultant: Yes he did, clearly this consultant was an absolute disaster. An excellent cautionary tale of arrogance combined with lack of ability and design thinking. Changes made without thought / design or discussion with the team are unlikely to be "improvements", unless they're being made by someone intimately familar with the codebase (which an outside consultant cannot be).
For your second point, I don't really see the applicability of this specific concept of the boy scout rule to the situation of "business critical code that is in such a bad state the whole team agrees it should be rewritten".
However, were I to try to apply the concept to your situation, the first question to ask is "why are people afraid to change the code?". There's usually 2 reasons for this. Firstly, the code and the problem are super complex and hard to understand, this just takes a lot of time, to develop the knowledge and intuition around the code. Secondly, the code lacks tests (unit / intergration / functional / manual spreadsheet of test cases) that assert the behaviour you expect. Therefore my (unasked for and probably already known to you) suggestions for "leaving it cleaner than you found it" would be to make a start on understanding the code better through a series of very very very small refactorings. Pick one tiny function that is a mess and clean it up. At the same time, ensure your changes are correct by asserting all expected behaviour of that function.
If you are now saying "duh of course" well thats the point. I do not think a single reasonable person would suggest that a full rewrite of a complex business critical system that is either poorly understood, poorly tested or both is a charitable interpretation of what the article is talking about.
At the end of the day it is super easy to shoot down any idea or concept in programming, because we have so much power to abuse and ruin anything day to day if we're not careful. It's the easiest thing in the world to take a machete to a codebase without thought. But the problem there is the person holding the machete, they can't be trusted with it. I cannot think of a single thing that wouldn't be misinterpreted or done badly by some of the terrible coders I've met during my career.
I am currently learning mandarin and my wife is chinese. This word, Na Ge (sometimes pronounced Ney Guh), can be said in rapid succession with little to no pauses between syllables, like an english speaker saying "um-um-um-um" or "yeah-yeah-yeah". Difficult to find a spoken version of this online, but please have a listen to this song [0] timestamped to the appropriate point.
A course on business communication in a segment apparently about "filler words" seems completely appropriate.
What concerns can these students have beyond "I am unable to handle foreign languages spoken in my presence"? These people better not visit a macdonalds in china because all the children around them will be shouting na ge whilst pointing at the menus.
I believe conditionals is referring to if statements (and their ilk, switch/case/cond etc). Rules is referring to rule systems and/or more generally declarative knowledge systems. Things like core.logic in clojure (or prolog, datalog and minikanren in the wider world).
Stuff like this is not specific to clojure, however it would be harder to have an embedded rules system in your language if its not a lisp. You'd probably have have to resort to a string based DSL (something like drools in java).
TFA appears to address this, the automated system is used to help identify comments for human moderators. The human is the one responsible. And according to stack overflow they plan to use this system only to help the human moderators.
If you don't believe them and suspect they will have a fully AI flagging system in the future (in direct contradiction of this post) thats fine but it might be better stated as such, since human judgement is currently still paramount.
A language with no built-in multi-threading capabilities is unlikely to suit every backend. Running multiple copies of the same lightweight process works quite well for stateless http interaction (request -> database -> response), but it's a lot of overhead to cross process boundaries every time you want to run something in another thread.
I also have a question about the loss of mindshare. What new technologies are unaccessible from Java, but are accessible from at least 2 other languages (one of which is TypeScript / JavaScript)? A loss of mindshare would likely mean smart people aren't around to build libraries / integrations to the latest hotness.
My background: Originally a Java developer, now mostly Clojure. Also a Javascript (mostly react) developer.
One of the examples in the article is upgrading a dependency. This could easily fall into the category you mention if the upgrade itself is not properly tested. A considered approach would be:
"I want to make a small improvement, oh I see this dependency is out of date and has some minor vulnerabilities or perf issues, or is missing a feature that could come in handy for XYZ. Hmm, there are no tests confirming our assumptions about the current library version, nor are then any tests are our code / systems that use it. I guess my improvement should be to add those tests, then next time someone has the same idea it'll be an easier upgrade"
I am unsure but I also interpret from your first sentence that you may have seen people use this rule as a defence for gold plating (the opposite of KISS or YAGNI). Similarly this should fall under the heading of changes made without proper discussion, thought or consideration.
Otherwise I think we're really stuck, if team members cannot be trusted to properly interpret the boy scout rule without messing up a codebase then how on earth can they be trusted to build the foundation of their company / team / system?