I've lived in Japan for a few months. I was about halfway through the article, thinking about how it seemed to be a counter-example, before the author called out Japan specifically.
For all the other differences in culture, the attribute of "People Actually Care" seems to have a huge impact on how pleasant a place it is to visit or live.
I don't know why it seems to be the case there. I don't know how to replicate it. I don't think it's magic. I've heard people bandy about the theory of cultural homogeneity. That might be a _factor_, but I doubt it's the full story.
I suspect if you dig into it, differences in economics are a major factor. In the US, it feels like caring is actively punished, economically. Caring is nice, but someone can only _afford_ to care if their other needs are met.
I also wonder if density is a major factor - not so much for the difference in economy of scale, but the difference of "if my physical space is incredibly constrained, I'm both more incentivized to keep it looking nice, and there's less of it to keep looking nice."
And, of course, it's not like Japan is some kind of otherworldly utopia. There's serious tradeoffs and differences, there's negatives compared to other countries. But it does seem like almost everyone, everywhere, just... puts in a bit more effort. Takes a little bit more time.
> There's serious tradeoffs and differences, there's negatives compared to other countries.
The collectivism of the society which both gives them a public sense of ownership of the whole country (thus, the caring), also yields crazy bullying in school and work, a high suicide rate, and lots of racist and xenophobic attitudes.
Maybe it's changing. It's been a long time since I spent any real time in Japan. My buddy who grew up in Tokushima also is out of touch with how things are there now. Who knows?
This is still pretty true. The xenophobia is waning as Japan's economy stagnates and there's a general vibe that Japan did something wrong economically. But otherwise, these all continue to be real issues in Japan.
These days there's also huge problems with infidelity, marriage rates, and divorce.
The suicide rate in the United States is higher than it is in Japan if you believe official government figures of Japan and the United States. The talking point about suicide in Japan is one of those that's 30 years out of date.
For what it's worth, it seems like "lego spike prime" is effectively equivalent to mindstorms, in that it includes a programmable brick that can connect to multiple motors, sensors, and can be programmed in a scratch-like environment.
I don't know why there was a branding change, but the capabilities seem pretty similar to the RCX I had as a child. Though programming over bluetooth is likely to be more reliable than the IR adapter.
Another approach I've found useful for this - turn off your monitor, or turn your brightness down to 0.
You can often do this pretty easily, with keyboard shortcuts or hardware buttons, and it does a lot to limit your temptation to re-read your draft while you're still writing, and makes editing (temporarily) impossible.
The examples of Dropbox and iPod being criticized on tech sites, but going on to become very successful, seems practically a part of the mythology at this point - but it seems to be _always_ those two examples.
Are there legitimately multiple good examples of "Criticized on HN pre-launch, yet became surprisingly successful"? I'm curious if the lesson to learn from Dropbox & iPod is more of "believe in a product, despite the criticism" or "sometimes, even accurate predictions are wrong"
California's Proposition 13 law (https://en.wikipedia.org/wiki/1978_California_Proposition_13) "locks in" property taxes on homes at the time you purchase it. Most other states do not do this, the value of your home is re-assessed annually, and your property taxes are based on the current value of your home.
In general, home values have consistently increased, year-over-year, in California. This means that many people pay less property taxes than they would if California didn't have its unique Prop 13.
Many people feel that this is an unfair law, as it largely benefits people who are _already_ financially established.
This article satirizes the situation, by framing the law as an intentional 'welfare program', rather than a tax break with unintended consequences. Part of the humor is that this 'welfare program' benefits the wealthy at the expense of the poor, contrary to how we typically think of philanthropy.
Many localities apportion property tax out of the budget, so if everyone’s property doubled in price but the budget only went up 2% - property taxes would increase 2%.
In fact, we had a reappraisal recently and my value went up and total tax went down.
> "locks in" property taxes on homes at the time you purchase it.
All real estate whether a 1200 sqft house owned by a 90 year old widow, a foreign owned apartment building, or an oil refinery owned by a multinational.
Note, for historical perspective, California hasn't always been a solid Democratic state, most trace the recent Democrat domination back to a Trump-like nativist politician that pissed enough people off that the Republicans made themselves irrelevant in the state
Property tax is regressive and nobody should be forced out of their own home because of rising property taxes that might only be due to a housing bubble. I don't see the problem.
Capping property tax increases is similar in effect to rent control; it benefits people that were already there at a given point in time and hurts everyone who moves in afterward (proportionally).
Freezing property tax ends up being wealth redistribution from the entire rest of society to landlords as the article walks through. Second order effects also end up locking up the housing market as a whole and pushing prices ever higher making everyone worse off in the long run.
Then read the article. The problem is that in reality the money flows from low income to high income households. So it works the opposite of how you think it does.
If you don't drink alcohol - don't be afraid to ask for a non-alcoholic pairing!
Worst they can say is "no can do".
The one time I asked, it turned out that our server was ~30 years sober himself, and asked their bartender what they could do.
What they could do was, a variety of alcohol-substitute drinks, mixes of spices that didn't replace wine, but achieved the same culinary role, and custom dry cocktails. Drinks that, given the description, I never would have ordered. Drinks that, by themselves, didn't do what I thought a beverage did. It was amazing.
I've also wanted a better shell scripting experience, and have bashed [no pun intended] my head against this several times. I think some of the major pain points that resist adoption of a language like Python or Ruby for in-line shell scripting or simple automation is:
* These languages prefer to operate on structured data. If it parses from json, you have a much easier time. But, most commands you'd invoke from the shell emit unstructured text by default. You can deal with this, but it's a pain point, and it means any serious scripting starts off with a "here's how you parse the output of <foo>", and several rounds of debugging.
* The shell's first and foremost usage is a user-facing interactive interface to the computer. Most of what you do is invoking other programs and seeing their output, and doing this is very easy. While python & ruby have REPLs, these are mostly focused on trying out language features or testing code, not invoking other programs, nor navigating a file tree. A lot of shell scripts start as 1-liners that grow and grow.
* Invoking other programs: In sh, invoking other programs is the primary activity, and it's relatively straightforward - you type the name of that program, press enter, and hope that it's on your path. In Python or Ruby, it requires importing the proper library, choosing the correct command, wrapping it and arguments, and ensuring everything escaped correctly. [Ruby _does_ have the backticks operator, which does actually make a lot of 1-off scripts easy, but this is not a panacea]
* In sh, a lot of the 'utility' programs like cut, sed, awk, grep, head, tail, etc., are standing in for the capabilities of the language itself. In pure Python or Ruby, you'd do these kinds of things with language built-ins. But, that's a learning curve, and perhaps a bit more error-prone than "| head".
* On top of all that, yes, momentum. If tomorrow you showed me a shell replacement for nix that was unambiguously* improved in every way, had excellent documentation, community support, and was actually pre-installed on every machine, it would still take a decade or more before it was really a default.
-----
I want it to happen, so I'd never discourage anyone from taking a swing. IMO, some of the top-level considerations that are necessary for making a successful sh alternative are:
* minimize the additional # of characters required to invoke a program with arguments, compared to bash.
* Decide which suite of typical utilities should actually be built-ins (i.e., things like cd, ls, cp, grep, curl), and make those standard library, built-in, without additional import or namespacing.
* Focus on an append-style workflow. Functional programing styles can kind of help here. Wrapping things in loops or blocks is a point of friction.
* An additional highly-desired feature which just isn't in sh by default, to overcome momentum. I have no idea what this would be. More reliability and better workflow are _nice_, but sh is sticky.
On the topic of "who wrote this shit", I'd really like to plug the idea that some of the most high-impact documentation you can write is a good commit message.
Say you track down a bug, find a line of code that makes no sense, and `git blame` it, to discover that you wrote it yourself, 2 years ago. If the commit message is "bugfix flaky builds", good luck figuring it out.
If the commit subject rather, is "bugfix flaky builds", followed by a message that explains what the flakiness was, why you think the change will fix it, what other bugs or limitations you were working around, and what upstream changes you might be waiting on that prevented further work, you're in a much better position. Suddenly you have a lot more context on what you were doing, why you were doing it, why you didn't do it better at the time, and in some cases it can even catch you from making an obvious but subtly-wrong mis-step.
Similarly, if someone's confused by your code during code review, that's a great opportunity for either in-line comments, or commit messages, as appropriate.
Unlike PR discussions, tickets, emails, slack threads, wiki pages, or photos of whiteboards, commit messages + git blame has an uncanny ability to be exactly the documentation you need exactly when you need it. Good git history practice can be one of the highest returning investments.
What has gotten me the most value is having either the branch or the commit message tie back to a ticket somewhere. -That- has the original bug, the comment thread that led to the decision around why this particular fix, any additional comments around tradeoffs we were aware of, and what other options we dispensed with, etc.
A well written commit message might explain what the issue was, but it won't have anywhere near the context the ticket and resulting comment thread should have.
> What has gotten me the most value is having either the branch or the commit message tie back to a ticket somewhere. -That- has the original bug, the comment thread that led to the decision around why this particular fix, any additional comments around tradeoffs we were aware of, and what other options we dispensed with, etc.
That works until the bug tracker goes down or the company decides to use a different bug tracker and the import doesn't preserve information, or the link in the commit message doesn't resolve to the corresponding ticket in the new bug tracker. This is far less likely to happen to the git history given that it's distributed.
That being said, adding information to the merge commit message linking to the discussion or actually summarizing it in the commit message itself would definitely be an improvement. The merge commit has references to the commit the branch is based off of and the head commit of the branch, so you can limit git log output to just commits in the branch long after it has been merged.
These two aren't mutually exclusive. Tickets, however, have lower long-term survivability (in my experience). Outsourcing, migrations, there are many scenarios in which the original tickets become inaccessible over time - and some codebases do last for years and years. Meanwhile the repository content (and thus the complete version history) usually survives as-is.
I didn't mean to imply they were mutually exclusive; just that in terms of "most high-impact documentation you can write", I find ensuring I link the ticket higher than making sure I have a thoughtful commit message, for the reasons listed.
Fair that it can disappear eventually if you change ticket trackers or whatever; that's a risk of changing ticket trackers. Hopefully you maintain both for a bit, and once you're six months out or whatever and retire the old, you don't need as much context since things have moved on (and there's a generational effect in tickets akin to that in garbage collection; you tend to need recent things more often than old things, and the older, the less likely you are to need it).
But just in terms of "what would I rather have", a link to the ticket every time. And in terms of "what am I more likely to provide", a link to the ticket every time as well (since all the communication on the ticket came about out of need; writing a thorough commit message is out of preparation, and I, and everyone else, am WAY better at consistently doing things that I need to do than preparing for possible future things)
> But just in terms of "what would I rather have", a link to the ticket every time
In practice over the past 20+ years, I've had to rely on commit messages far more than tickets, but a well-written ticket is defnitely awesome to have. When I ran Engineering for a startup, one of the things we invested a lot of time in was making sure commits had good messages, tickets had good writeups, and the two were linked. We required a pull request to close a ticket, and our CI system would automatically append a link to the ticket to the PR when it was merged. It was such a level of awesomesauce.
Obviously my experience is my own, but in many cases it was the ticket system that changed vs. the version control system, which is why history wasn't always there. A lot of my early experience was at startups and I think I saw a version control migration only happen once (VSS to Git). I've even seen a couple places that didn't even have a ticket system. Unsurprisingly, those no longer exist.
In any case, I think the "correct" answer is proper commit messages AND solid issue tracking. My preference for commit when looking in the past was more around trying to understand particular changes to specific files or lines of code, which are more easily navigated in source control. A good commit message helps narrow down things when there is a long history, but a link in that message to the actual ticket would be a dream since that would likely have the larger context.
All that said, I have spent some time at a FAANG and neither commit messages nor tickets were useful at all there. Commit messages were usually along the lines of "fix a bug" or "add a feature" and the tickets rarely had more detail than "fix X" or "add Y". That was more of a symptom of the "go forward" culture there. Little time was spent making it easier for the next person since that wasn't really rewarded in the performance process.
The commit message idea always felt a little strange/off to me. It's a string that you can't (generally) fix/extend later for those who may seek this information. Also nobody except the committer can write them. (Imagine an explicit @docsguy role for documenting commits along with writing ticket-based documentation.)
What if VCSs used a single file or a folder, like .gitcommits, where anyone could append any sort of info in the same commit, so it could be a part of it. Then, when you commit a feature, you add to this file(-s):
@@ @@
+---
+added websocket support to the server
+ /ws - main socket
+ /ws-events - events socket
And few commits later you decide to extend it, editing the same record:
@@ @@
+---
+added json-rpc over websockets
+ /ws-json-rpc
And VCS would then extract these records at `git log`:
...
4509812 added websocket support to the server
0732691 <no .gitcommits message>
8712389 added json-rpc over websockets
Few commits later @docsguy expand on json-rpc:
@@ @@
---
-added json-rpc over websockets
+added lifetime-related json-rpc over websockets
+task: ./tasks/1873.md
+supports 'start' and 'stop' methods: ./doc/ws-lifetime.md
/ws-json-rpc
@@ @@
+---
+enhanced commit descriptions
A tasks/1873.md
A doc/ws-lifetime.md
4509812 added websocket support to the server
0732691 <no .gitcommits message>
8712389 added lifetime-related json-rpc over websockets
6034007 enhanced commit descriptions
Full commit messages would then be just diffs. Also, one could write a commit message gradually, with the sources they are modifying. Or write two commit messages at once (because we all do commit two+ changes sometimes):
@@ @@
+---
+refactored foo bar heavily, @docsguy please expand
+---
+fixed a bug in baz, didn't care to backport
...
0923423 refactored foo bar heavily, @docsguy please expand
fixed a bug in baz, didn't care to backport
A well-written commit message should explain "why", this may partially consist of linking to external things (bug tickets, whatever). Although it is probably important to have enough of a "why" that the reviewer can make an informed decision if they need to go check the external reference or can continue with the review as-is.
Code review discussions are precious context. Unfortunately, git does not keep them. This is a major shortcoming of git. We need a new source code management tool that stores code review comments. It can lower the cost of software maintenance.
> If the commit subject rather, is "bugfix flaky builds", followed by a message that explains what the flakiness was, why you think the change will fix it, what other bugs or limitations you were working around, and what upstream changes you might be waiting on that prevented further work, you're in a much better position.
Those are very different needs.
"Why?" belongs in code as a comment. "How?" only sometimes belongs in a comment--generally if the code is "clever".
"What?" generally belongs in the commit message as it can touch multiple files and subsystems.
"Who?" and "When?" generally belong in your ticketing system.
For all the other differences in culture, the attribute of "People Actually Care" seems to have a huge impact on how pleasant a place it is to visit or live.
I don't know why it seems to be the case there. I don't know how to replicate it. I don't think it's magic. I've heard people bandy about the theory of cultural homogeneity. That might be a _factor_, but I doubt it's the full story.
I suspect if you dig into it, differences in economics are a major factor. In the US, it feels like caring is actively punished, economically. Caring is nice, but someone can only _afford_ to care if their other needs are met.
I also wonder if density is a major factor - not so much for the difference in economy of scale, but the difference of "if my physical space is incredibly constrained, I'm both more incentivized to keep it looking nice, and there's less of it to keep looking nice."
And, of course, it's not like Japan is some kind of otherworldly utopia. There's serious tradeoffs and differences, there's negatives compared to other countries. But it does seem like almost everyone, everywhere, just... puts in a bit more effort. Takes a little bit more time.