The really sad part is all the missed positive externalities. Think about what could happen if a few companies owned up to it and said "hey we'll let you have one day a week helping children with their homework or working on a shared vegetable garden or... or... because [insert outreachy marketing speech]"
Companies would never do it because of competition. Only a token company might do it, when it doesn't need to compete as much (e.g. has a niche, sells luxury stuff with a secure market, where the positive work balance they sell as part of the brand). If many did it, then this good-will gesture would lose the marketing value for the company (since it would be common).
Instead, companies need to be forced to do it, by law -- like they were forced to stop child labor, to have safety laws, to 8 hours workday, etc.
How do you enforce the use of a formatter in a project -- pre-commit hook? pre-receive hook? both? And is there a convention to put a specific dotfile at the project root to hint at your IDE/editor that it should use a certain tool for automatic formatting?
We are using a pre-commit hook but I also have an on-save hook in my editor. Further, we also have a CI job that runs `black --check` which returns 1 (failing the build) if the files weren't completely formatted with black. In Go, the convention is that everyone's editor runs gofmt on change, and because the convention is so strong, that's usually enough (although many larger projects also have a CI job similar to the one described above).
Having used both extensively, my biggest grievances (in order) are that there aren't more editors that with good on-save support, that black is relatively slow (compared to gofmt), and that black isn't more opinionated and less configurable.
We use pre-commit.com – configure your project with dotfiles for various tools so things like editor auto-format & lint, pre-commit, etc. can pick them up, and then have a Git pre-commit hook which is also run by your CI tool for consistency.
The first one shows you what's different (so you have logs in your build job), the second one fails your job if there are any diffs. You could just do the second one if you're a fan of the whole brevity thing.
One, that shouldn't matter on CI anyway. Two, you can tell black to just print the difference with --diff and tell it to just check the files with --check.
The French École Normale Supérieure will pay you around 1200 euros per month to study there. There are strings attached though (10 yrs public service commitment).
10 years but the 4 years of studying there are included in the 10 years. Most continue with a PhD (at least 3 years in France).
And then it is allowed to do research abroad, not for the French governement, for instance in an US university. Working for a private company entails to have to give back just part of the money.
And there are 4 ENS (écoles normales supérieures) in France so even more opportunities!
No engineering track though... Also you need to pass a highly competitive exam to get in and it's really somewhat a graduate programme, since you're supposed to get in one year before the master starts, not right after high school.
> The "Social security" pays around of 10% of most usual costs, the mutual fund pays the rest...
What? The basic insurance scheme pays at least 60% of a set of reasonable, negotiated fees and the "mutuelle" covers the rest. There are a few corner cases (complicated dental work, optics) but these are being addressed. Usually the out-of-pocket expense is minimal to nil (a "forfait moderateur" of around 1 euro per doctor's appointment for instance)
Not sure. An ariane 4 rocket exploded due to a leftover cleaning rag in a water line. I would guess the launcher + payload price would top the price of an F16?
It only diminishes debt if your ability to service that debt outstrips the rate of inflation. If your ability to service debt does not grow in line with inflation, you are in no better state.
Yes except that it is not black and white, working or not working. There could be a real case made for working less and directing efforts towards technology improvements that result in less environmental damage. To me, it does not make any sense to think in absolutes.
That's been debunked by examples where hiring (literal) team players that are not shining on their own enhances a team above the level of an 'all-star' team. So why do we keep repeating this nonsense?
It'd guess it's because a) it lets us all think we are in the "rockstar" category, which is pleasing, and b) it lets us avoid all sorts of difficult thinking about the system that actually produces the work, and c) justifies unequal rewards, which is entirely useful to the people receiving the rewards.
It's the same reason the myth of the 10x engineer is so popular. I've worked with some people who certainly thought they were the 10x engineer. As far as I could tell, they were just showboats who did highly visible work, leaving little things like technical debt for others. Or the "brilliant" engineer who make things that require high cognitive load to understand, instead of doing the extra work to make them clear. [1] Or who shirk the work of supporting colleagues and building strong teams.
So basically I think these are the people who optimize for the visible success metric, not the ones creating the most value.
[1] Just this week a friend took over responsibility for an internal build system. The previous author had written it in JavaScript. Except that he was really excited about functional languages, so he wrote it in a highly functional style incomprehensible to anybody not used to it. Now this either needs to be mostly rewritten or anybody who wants to work on the build system needs to spend 6 months learning Haskell first. I'm sure this guy looked productive and got to sound brilliant in meetings, but a better productivity analysis would include the significant costs he imposed on others.
Your question is a good one. The zeitgeist in the US has been for years that we at are all the same and "rockstars" just try harder. In reality, not everyone wants to be that, and not every team needs that.
