That much money just to go back on a promise to not sell would be a very easy decision (bear in mind that no material harm is done to the employees, no equity was promised, no equity was given, they never had a chance to share in the sale regardless of the founders' promise)

1) Founders promise not to sell. Employee is offered salary without equity.

2) Founders say nothing about selling. Employee is offered salary without equity.

In both cases the employee has lost nothing of value. Someone made the founders a pretty ridiculous offer ($12bn for $700mn revenue company). Why should they refuse? No one is being harmed by the sale apart from some employees incorrectly assuming a broken promise means they deserve a chunk of the sale .... a sale that they would NEVER have benefitted from regardless of the original promise.

Compare this to the usual startup "promise" of low salary but equity and fingers crossed we'll sell. Presumbly mailchimp had to offer higher salaries to compensate for the lack of equity offered. And if they didn't then that was a silly choice by the employee (low salary and no equity).

One asserts that nerds want to know the details for ego reasons.

The other asserts that he (presumbly as a self-proclaimed "nerd" in this situation) wants to know the details because otherwise he has no idea if the product is even useful.

If the product being sold is actually that simple e.g. "trade stocks with a few clicks" thats fine. But for anything that requires customisation, integration or any kind of technical support thats not true. You need to know the details to know if it will work.

This very much matches the stereotypical enterprise sales disaster i.e. buzzwords and flashy things sold to c-suite that are then suffered by those who actually use them and find that it doesn't do what they need

EDIT: also in this context where the article title specifically mentions "technical documentation" we are clearly not looking at the super simple type of product.

Not wanting to misquote the above / Rich himself I would TLDR it to:

- flexibility of data manipulation

- resilience in the face of a changing outside world

- ease of handling partial data or a changing subset of data as it flows through your program

Please note that no one (I hope) is saying that the above things are impossible or even necessarily difficult with static typing / OOP. However myself and other clojurists at least find the tradeoff of dynamic typing + generic maps in clojure to be a net positive especially when doing information heavy programming (e.g. most business applications)

There is a difference between not complaining vs raising issues constructively and valuing the maintainers time at least as much as you value your own time.

If not then I can see the reason for your frustration, however it is not the same as free software being worked on (at least partly) by volunteers receiving the same lack of effort (or in signal's case nastiness) in bug submissions.

Regarding ecosystem and interop, in my experience (using clojure for about a third of the stuff at my job) I've rarely encountered a problem directly interop-ing with a java library, things like "doto" and "reify" do a good job of smoothing the rough java edges off.

More importantly I've usually had the choice of either directly using the using a pure clojure alternative or direct interop with java lib or using a clojure wrapper around the java lib. Incidentally those are my preferred choices in order (assuming the features I'm interested in are supported equally).

Perhaps I have been lucky in my requirements from the clojure / java ecosystems. I find the most important lesson I learned was to only use clojure wrappers if they are of a supremely high quality (either auto generated like cognitects aws lib or with a massive amount of momentum behind them like clj-http (wrapping on java http components)). An average quality or not super actively maintained wrapper is much worse than direct interop (again leaning heavily on the provided macros for interop to sand off the nastiness).

[0] https://github.com/tolitius/mount

In general, I highly doubt anyone would hire a consultant just to "rewrite code". Rewriting code is not a business objective. Improving application performance is, delivering features more efficiently and reliably is. These are some examples of objectives that might involve rewriting code (or not, not every codebase is a swamp in need of draining).

In the context of this article though, the code to be "improved" should be anything you touch. Did you use a function in building some new widget and you noticed it had no tests and no docs so it took you ages to integrate? Then add a test and the minimal doc string.

In terms of who is watching the consultant, I'm unclear why you're asking me, a person who has just said they would never hire a consultant to do anything with code. But if I had to, I would get someone of at least equivalent technical knowledge. However I'm pretty sure thats not how it usually works, which is probably why inept consulting companies rinse big companies for so much money for such lacklustre results.

But overall I really have no idea what you're talking about with regard to consultants and rewriting code. None of which seems to have much relevance to this article about making tiny improvements regularly. Unless your comment was in the wrong thread?

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?

Or do you mean that small incremental improvements shouldn't be attempted because a proper review of whether they are worth it or not will be "wasted effort" if its decided they are not worth it?

Or something else? Not being sassy, genuinely unsure.

As for me personally, I would never hire an outside consultant to improve a codebase. The incentives are all wrong (long term maintenance to be done after they leave) and it's unlikely they'll be working on it for long enough to properly understand either the codebase or the domain.

It is a common refrain against simple mottos or ideologies in programming for people to pick the worst memory they have of a coder or experience as an example of why it cannot work.

As if the problem with a bad team member is that they heard the wrong motto, if only they hadn't started incorrectly following the boy scout rule their contributions would be exemplary.

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.

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?

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.

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.

[0] https://www.youtube.com/watch?v=xNRgHUs17vY&t=15s

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).