63 karma · joined September 30, 2018
Writing at https://www.bernardosulzbach.com/.
Not only you had a person that already knew much more about your product than the average potential hire, but a person that probably was interested in your product (and maybe knew what users wanted) too.
I've seen people propose things as dubious as a character limit per function body. Most programming languages are so flexible that no matter what guidelines you set for your project, there will still be very bad code that conforms to all of them.
Forcing function splitting by rules is a good example of this. Very large functions are probably doing too much, but where and how you split them matters incomparably more than if you split them at all.
Given that extended attributes are available in most of the filesystems used in Linux today, Dropbox still hasn't answered why they decided to go "ext4-only" for a while.
The article never mentions speed (or performance) again. Is the OS somehow expected to be faster because it is mounted read-only?
Despite these three languages giving far too much freedom to the programmers (which some might even like), high-quality code can be written in all three of them, as long as intelligent and strict coding guidelines are thoroughly followed.
As it is with most big companies that profit from ad revenue. They seem to consider performance indicators to be sufficient to know if a new feature is good or bad, instead of worrying about written customer feedback.
And today, if the big search engines decide something will (no longer) be indexed, they can make it effectively unreachable.
Upper management usually does not seem to care whether the people you manage leave the company eventually or try to change teams to get away from you.
However, even if you were to pay the people behind the journal for their work it should be fairly inexpensive as long as they did as little as Elsevier does.