... Wait
329 karma · joined June 20, 2018
... Wait
That being said, I wholeheartedly agree on your points regarding Japan not being a multi-cultural country. And this, indeed, is rarely (if ever) mentioned in articles such as the one posted here.
Japan is an island. It has always been and not just from a geographical perspective. Its very culture and history are ones of isolation. The restrictions are not new, the perspective "Japan first" is not new - these have always been there, they are at the very core of the nation.
To the author: thank you, you made my day. It had been a very, very long time since I last read an article on the Internet that felt written by a human being - with humor, some poetry, and science.
We won't own games anymore, we won't be able to sell/acquire used games, we won't be able to play disconnected.
I'm curious whether Nintendo will be following the same path.
I guess we can now call you Mario 'Kart' Idraulico.
Oh wait.
Thank you CERN, that was a smart one.
Or, she stumbled upon some article or the very Wikipedia page about it:
That's something that you learn to do when you have a kid: suddenly, your periods of 4 hours of focus free time (for coding, exploring tech, whatever) during the weekend just _disappear_. You only get max 30 minutes of free time in a day; this is extremely frustrating initially; there is no boss to complain to, no meetings to blame, no solution but to deal with it. Progressively, you learn to switch tasks much more efficiently, by making regular check points, so that you can get interrupted any time and get back to deep work _quickly_.
Ibuprofen is forbidden for pregnant women in the last 4 months in France at least - and by "forbidden", I mean "strongly advised against in a case of self medication".
"The era of 1-bit LLMs"
Representing { -1, 0, 1 } can't be done with 1-bit, I'm sorry -- and sad, please let's all get back to something vaguely sound and rigorous.
Package management, package definition, interface definition, exporting, protecting or hiding components, feel like they were an afterthought, and as if specified by people who had absolutely no prior experience in other languages or actively ignored it.
There is no nesting of packages in Go. There is no selective visibility protection among packages except on the very first level. Exporting is such an afterthought that it is declared by the change of the first letter to uppercase. Local development of cross-modules was only introduced recently (workspaces) and is extremely primitive (no transitive replacement -- so workspaces depending upon other workspaces is not a thing, workspace-vendoring in the next release but will essentially conflict with mod-vendoring). This probably works with skilled and disciplined teams with strict linters and other tooling, and operating in a large mono-repository or on ultra small codebase. For others, it ends up in a large plate of spaghetti code with no help to untangle, and every single newcomer shedding blood, sweat and tears to wrap their head around a codebase which inexorably became monolithic by the invitation of the very language.
All learnings obtained from decades of building very large-scale applications in C++, of managing and publishing packages in Java or C#, was essentially put aside and ignored.
The sad but good news is that it's all being progressively rediscovered, but relearning from decades of nuget and maven for example, will take time, effort, exemplary humility and open mindedness.
As in the 90's https://en.wikipedia.org/wiki/Zip_drive
A loop is a label+goto in disguise. You have to look at what's inside to understand what the loop is doing; you can't get a global sense of how it is impacting data without looking at what it actually does.
In functional programming, loops are replaced by constructs such as foreach, reduce, map or filter, to indicate right away how the body of the loop operate on the data it is scanning. It enables a functional approach to looping, where one first thinks about how data are transformed -- about the functions to apply on items and what is the overall output of the loop.
The perspective of spending 1 or 2 hours playing videogames or watching entertainment (movies, series) became terribly boring to me. I can only think of that as a loss of time: I wouldn't be a better person at the end of it.
Being able to better smash buttons, faster, at the right timing -- watching a story unfold on screen -- these used to be a great source of joy "before". But today, it seems all so dull; my intellect or my body doesn't get any better by doing that. Instead, reading whatever book on ML or even on an obscure programming language or technique, or spending time at the gym, or listening to a lecture on math or physics, sound so much more appealing to me.
I cannot spend time anymore just sitting, it literally upsets me. Anybody feeling the same?
Over the 9 languages mentioned: 5 languages (inc. JVM ones like groovy and kotlin) are using `$`, 1 language (swift) is using `\`.
`\` is a pain to type on many keyboard layouts -- actually most but the US one. It seemed to me that `$` would have been a much more "conventional" choice.
This really makes me sad. It looks like the choice was made on purpose to be different.
It will give you concrete examples on how to broaden your scope out of just your individual contribution, by learning to care for all the rest, and pushing you to realize that to a large extent, the things you see as broken you can actually fix.
Even when they are not inside the codebase you are in charge of. Even if they aren't even on engineering side.
Is/was it? The shortage of qualified engineers have made some employers extra careful/generous, to attract and keep them. Or some others to divert brains away from their own occupations which could have ended up competing with them.
I'm saying that someone who hasn't been doing their job for 6 months, has been told so repeatedly, has been shown and guided through an improvement plan, but still fail to meet the expectations, should not be kept at their position. Whatever the date for whatever bonus, yes.
It doesn't matter if it happens one day, one week, or one month or 6 months prior to that date. What matters is whether everyone was aware of what was happening and the implications of it.
If that is not the case, then yes sure, start now to build that file. In this instance, the date will pass, and in a couple of months from now the contributor will be out. The next instance, act faster.
Vesting is compensation unlocked after a period of time. It is _meant_ to keep people _engaged_. You shouldn't feel bad for having to terminate someone two weeks before vesting, or 1 month before vesting, or 6 months before. No more than you should feel bad for having to stop paying someone that you fired.
Do you have _facts_, undebatable ones, demonstrating that the person is below expectations? Do other team members share the same point of view? Do you have feedback from others, pointing out that this person wasn't pulling its part? Did you share that with the person? Did you share these elements, did the person acknowledged that there was missed expectations? Did you agree on concrete goals to progress and meet expectations? Did you guide that person on this, for like 2~3 months?
If you answered YES to all these questions, but the person is still failing, then let that person go. You've made your job. Whether they are vesting tomorrow or in 6 months or in a year, is _a detail_. They have been failing to meet the bar, you've told them, you explained them how to reach it, you guided them for some time, and they are still failing.
If you didn't, then start right away.
Put vesting in parenthesis. That is not the topic at hand. The topic is meeting expectations or not.