When the helmsman would yell out "Ready about!", we would check the surroundings and respond "Ready!", then we would listen for "Helms Alee!" and prepare to switch sides and trim the sails. This process made sure that all of the crew were synchronized as to the current step in the process.
It worked well in making sure everyone was on the same page about what I was actually supposed to be doing. I eventually stopped doing it though because people got annoyed and thought I was stupid or just not listening to them, which was ironic because that's exactly the opposite of what was happening.
It's a shame really, because it did minimise errors. There's nothing more annoying for everyone then when someone spends hours doing the wrong task because of poor communication.
But, who knows, it might not have made a difference. In my case, my boss already knows that I like to be extra certain that we're both on the same page.
If you have a poor memory like me, repeating things back is important to help you remember them too. Since I work in office type environment, I try to repeat things back by writing them down where both the requester and I can see them - such as in a job ticket or email. This also helps if a third party joins the task later or if the task gets put on hold.
Especially after the day that a coworker got confused about which truck was which, and drilled a 3.5" hole in the bed of a brand new truck (thinking it was getting a gooseneck hitch). After that, everyone else started repeating verbal instructions as well.
I am only curious because this almost happened to me... and I was so glad when I found out they didn't put in the holes yet.
Makes it much more difficult to make mistakes this way.
"Steer zero nine zero"
"Zero nine zero aye"
My experience with this was relaying a message between the driver and guard, to reverse a train on a main railway line. The guard answered "yes" and there was hell to pay as the train reversed across a section boundary. The "yes" response ensured the guard received a message, but not that he received the correct message.
Seemed to keep spirits up and probably had the side-effect of reducing errors.
Yes, I have seen this. Rail workers are great at it, but in other places, it can get worse. I saw a guy pointing to both sides of the sidewalk - to assure that it was free of people - before letting a truck get into a parking lot. His colleague will barely move the hands. It looked slightly awkward.
> Japanese commentators have theorized that Western employees feel “silly” performing the requisite gestures and calls.
I guess that this is what humans are bad at. We overvalue our awareness, and we put a lot of much weight on any act with social implications.
While I was at Fuji, I saw what it seemed a guy training alongside the train driver. He laughed time to time at his own movements. They both had a great time. So, even for Japanese, seems that the situation is slightly awkward.
I'm going to guess it's because you are doing something unexpected/unusual. Predictability of action is a great thing for social cohesion and safety. Actions that result in one feeling silly might be misinterpreted (are you being aggressive, did you get rabies, or otherwise lost your mind?)
Looking at it this way workplace safety barely mattered until very recently. Before the big killers were the lack of food and vaccinations. It's only since society became as safe as it is today, that these smaller safety goals even seem to matter.
On another note - how strange is it when you learn something new of which you haven't known about your whole life only to several days later see it appear on hn.. is there a name for this sort of thing?
> The considerably catchier sobriquet Baader-Meinhof phenomenon was invented in 1994 by a commenter on the St. Paul Pioneer Press’ online discussion board, who came up with it after hearing the name of the ultra-left-wing German terrorist group twice in 24 hours. The phrase became a meme on the newspaper’s boards, where it still pops up regularly, and has since spread to the wider Internet. It even has its own Facebook page. https://psmag.com/social-justice/theres-a-name-for-that-the-...
Seems like an unusual way for a name to start, via a random comment on some obscure online forum in 1994. Language is weird.
1) You wouldn’t be seeing so many other cool cars and thus be tempted to switch cars all the time as that would distract you from driving where you were going.
2) If you wrecked your vehicle it would be easier to get a new one of the exact same kind.
But I think your explanation makes a lot of sense. They embedded a lot of humor in those games.
It is also conceivable that they initially did it as a joke and then once they had implemented and play tested it they discovered the benefits mentioned above, and made the case stronger for keeping it that way. We may never know :)
James Clear: https://jamesclear.com/articles
Atomic Habits: https://smile.amazon.com/Atomic-Habits-Proven-Build-Break/dp...
Perhaps you mean Atomic Habits?
Before that I occasionally "lost" my keys because the location was never safed to my long term memory. At least that's reproducably the error why I sometimes just couldn't remember.
But I also hooked a USB drive to my wallet, and one time I needed a file from it, so I plugged it into my PC with the rest of the wallet attached to it, placing the wallet on top of the tower, behind the monitor. 20 minutes later I was on the phone with the local supermarket because I couldn't find my wallet at its usual spot, and I knew I had it with me while paying at the supermarket.
So, no, it isn't.
Small times doesn't mean small impact on developer time.
1. Routine makes you much more likely to make errors because you're not fully focused. This error could feed into the next process step which is maybe longer, thus costing you disproportionate amounts of time if it fails.
2. If there are wait times in these short tasks (say 30 seconds to 30 minutes) these can have an inordinate effect on developer time wasted.
Say you have a "30 second task" you do a handful of times a day. You have to do something, then wait a bit, then do something else. If you're not a robot you will not like watching for the time it takes to complete. So you might switch to HN or whatever else you were doing. What happens after the task completes?
* You could have lost your state of flow (very likely) => that's another 15-20 minutes to get back into it.
* You might forget to context switch back. Boom 30 minutes have gone by. Oh it's lunch time now. I'll do that after. Then you come back, and forgot about it again. 2h have gone by in your 30 second task, and it's still not done.
3. The problem could be that you don't do the task often enough. Maybe it would help quality if the task was done every few seconds. If it's arduous or takes some time, you're much less likely to do it as often. The graph in 1205 assumes that the number of times the task is done is not related to the speed of execution or that it is a manual task. I don't think that's true. An extreme example of this would be my previous workplace. Build times were 5h, you needed to execute two steps to trigger a build. One step after the other completed (roughly 15 min).
People would waste a lot of time on finding errors that a compiler could find right away, because compiling took half a day and wasn't something you just wanted to trigger.
russdill> The process described is not only easily scriptable, ...
From the description given you can't know that.
russdill> ... deploying to production should never depend on a series of manual steps except when absolutely necessary.
So you, without knowing exactly what this person is doing, are declaring that it's not absolutely necessary? That's very bold of you.
ETA: I'll add that when pushing production, the amount not just you can waste, but everyone down the line from users, developers, testers, etc, etc, can be huge. Calculating how much time you would save isn't useful.
However, there can also be a number of reasons why builds and deployments could not be automated safely:
- "Production" is not a single environment, but multiple customer environments with multiple deployment version targets based on need/contract. Customer environments might not even be accessible from same network as build/deploy machines.
- Code is for industrial/embedded/non-networked equipment.
- Policies dictated by own company or regulatory body require builds are manually checked and deployed by a human who can validate and sign off.
There really is no way of knowing. Automation can save hundreds and thousands of man-hours and reduce margin of error; but it is not applicable to every scenario. Sometimes manual work reinforced by good habits and processes are the tool for the job. As much as it pains be to say, as my job is automation.
The urban myth that I grew up with was that they were pointing at a hidden camera to show the dispatcher that they're awake, but the article I linked below suggests that it was taken directly from the Japanese railway.
> ... New York City’s MTA subway system, whose conductors have used a modified point-only system since 1996 after then Chief Transportation Officer Nathaniel Ford was fascinated by the point-and-call system during a business trip to Japan. In the MTA’s case, conductors point to a fixed black-and-white “zebra board” to confirm a stopped train is correctly located along the platform.
> According to MTA spokeswoman Amanda Kwan, conductors were quick to adapt to the new system, and within two years of implementation, incidents of incorrectly berthed subways fell 57 percent.
So if you want, you can meet someone on a specific train car if you stand somewhere in relation to the board.
I used to meet up with my wife who worked 2 stations north of me using this technique without either of us disembarking. It was pretty handy.
1. Does the NYC subway as a result have significantly lower incidence of alignment problems than London's Underground? London has had one person operation of all trains across the system for decades, so, if the conductor pointing at stuff matters, logically not having a conductor at all ought to result in significantly more errors... I haven't heard of such errors at all, but presumably they do happen at least sometimes.
2. What do the rates look like in Copenhagen, which is GoA4 and thus there isn't anybody aboard the train with responsibility for the system, there's a control centre with some broad over-all authority, but individual trains drive themselves.
My instinct is that actually this is not a good solution, it's what you might do if all the good solutions are off the table and you have to pay these guys anyway. "Well, might as well try to slightly improve our lousy accuracy".
However not all underground platforms on each line are of uniform length - for example Baker Street's subsurface lines have platforms shorter than the trains that run on them.
It's the opposite of "move fast and break things". Heavy-lift companies and marine salvage companies (there's overlap) are in the business of "move slowly and don't break things". Mammoet, Titan, and Smit all have videos on line of some of their jobs. They are way into overpreparing. They have more gear on site than you'd think was needed, they prepare for as much as a year for some operations, there are detailed, written plans and backup plans which have been rehearsed and talked through by the people involved, and then on the big day, everything goes so smoothly it's dull. Watch some of those videos and you'll see some explicit hand signals.
Previous discussion https://news.ycombinator.com/item?id=14011793
"I'm composing a snarky comment about Japanese rail workers pointing at things." "Done."
"I'm pressing 'add comment' to post a snarky comment about Japanese rail workers pointing at things." Wait, what? No. I know better than that. Abort.
Which is really a bummer, because on some level you tend to think, to buy into a stereotype, that the Japanese have their shit together, and you admire that, but the negative space of these qualities is that they never step out of line, and when they do, it’s the end of the world.
Every time the train guard went through, when he got to the front of the door he'd turn around, do a 180 spin to face the passengers and give them a salute before 180 spinning back and going to the next carriage in front. I know it's a cultural thing but it's a nice touch.
I got the idea after the last time an article about this phenomenon was posted, and it's worked beautifully since.
It sure helped get into the role.
Similarly, Japanese sysadmins must write down -- and get approval for -- every single shell command they intend to execute on prod before actually issuing the command, specifically to reduce the number of 'rm -rf /' oopses (and other breaking changes).
It may look unusual, but I wouldn't call such a thing silly. I've noticed that Japanese workers do just about everything so patently deliberately that there must always be a reason for it being that way.