NOT OP but there's very little I would not sell or change my mind for $5bn.
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)
I don't see the promise impacting an employee's decision at all:
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).
Not the person you're responding to, but those comments are not saying the same thing at all.
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.
I read the comments and I agree but I would describe that in my way:
Car mechanic buying bolts needs to know thread and sizes of bolts, he does not care about "our bolts are best bolts in the world", if he would spend an hour with sales rep that feeds him marketing and in the end it turns out they don't sell what that mechanic needs, it will make him angry.
IT people or "nerds" know what they need and they have specifications to meet. Making it an "ego" thing is silly :).
Car mechanics care about the standard. A grade 5 bolt is different from grade 8, even though grade 8 is objectively stronger there are many places where they are too strong and so you need to use the objectively worse bolt. I don't remember the terms metric uses for the above, but there are metric equivalents for the same reasons.
That's a misinterpretation.
Best bolts in the world doesn't mean strongest, that's where we'd use the word strongest. Best bolts is an opinion.
A max strength before shearing/failure is just another req. for the task the mechanic wants to know, it doesn't make them objectively worse unless they were used in a situation where they needed to be stronger.
This comment helpfully explains many of the reasons Rich had for choosing immutable, persistent, generic data structures as the core information model in clojure (instead of concrete objects / classes): https://news.ycombinator.com/item?id=28041219
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)
TFA and the person you're replying are not suggesting you can never complain (at least I don't think they are).
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.
Was the game free? And did the people working on the game contribute a lot of their time to it for free?
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 REPL restarts: You don't need to use stuff like component. There are far lighter weight alternatives with no requirements for app structure. I use "mount" [0] for this. You define "start" and optionally "stop" code for anything in your app that you consider stateful and would like to reboot (like db conn pools, config loaded from files / env etc). No interfaces / protocols, easy app restarts within the same repl, no enforced structure in your app. You just use the resources as if they were def'd vars in a namespace (because they are).
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).
Your article was very clear. Thank you for writing it.
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.
I'm not entirely clear what you mean. Are you referring to the disaster artist consultant mentioned in another comment? I don't think anything can stop someone like that from wrecking things short of not hiring them.
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.
Please may you specify what consultant you're referring to here so I can answer more thoroughly.
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?
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)