Fair point - but then take national eID apps instead.
Take Denmark, for example: most banking apps use eID for login, so that problem translates 1:1. But other apps who do the same include the national school communications platform (which is pretty much mandatory for a huge chunk of the adult population, who need to look at it almost daily). Also: social security card (including health portal/doctor booking/comms), driver's license, bus pass, parking app, used-stuff-marketplace, ... eID is _everywhere_ because it's a good idea.
Sure, all of this can be done on a computer. If you're near one. Or you can have separate and physical cards, like we used to have. That still works, mostly: more and more services (eg. bus pass) are going digital-only.
Really, what we need is a top-down embrace of open-source-based platforms as being _as_ (or more) secure than the established tech giants. From governments down, organisations _should_ move away from locked-down (foreign) commercial interests.
I wonder if this sort of thing belings to a certain kind of organisation, or type of career. I can certainly see the value of "we have all of <brilliant engineer's> technical notes going back 43 years!" but in my experience, it's rare to meet a "brilliant engineer" who'll stay in one position for even a decade.
Personally, I've been in many 2-15 year employments where I made copious notes - but I did so in whatever wiki my department was using. I've never had the opportinity (or, for that matter, much desire) to bring those notes with me to the next position, as they were (a) specific to that place or task, and (b) quite certainly proprietary (if far from high-value industrial secrets). Detailed notes on the inner workings of an in-house framework, or end-to-end credit card processing flow, just aren't that relevant when your next role is steward of a 25-year-old national tax reporting platform.
I've done a few blog posts, but haven't generally felt the need to share my brilliant thoughts with the greater world, those were just my personal musings (as is this piece right here).
Don't get me wrong, I'd love to _be_ in a position where such long-term usefulness was expected.
Send your boss a link to "Negative 2000 Lines of Code"[1] and ask him if he thinks Bill was a shitty coder.
When I was scrum master for two teams I, too, tracked some metrics (for feedback and improvement, not for pay or career (ab)use).
While I did track the number of story points delivered and user stories closed per sprint, one of the things I was more interested in was how accurately the teams managed to hit their estimates (regardless of what they were). In that perspective, delivering too much too quickly was just as undesired as the opposite. We used this to refine the way that we did estimates, story refinement, and sprint planning.
Naturally these were team-based metrics, because software development is a team activity.
> "the antenna on the spacecraft had been pointing two degrees away from the Earth [...] left it without the ability to receive commands or transmit data [...] NASA reckons the situation is temporary [...]"
I wonder how it's temporary. Does the probe have a re-targeting function? The answer is in the original statement:
> "Voyager 2 is programmed to reset its orientation multiple times each year to keep its antenna pointing at Earth; the next reset will occur on Oct. 15, which should enable communication to resume. The mission team expects Voyager 2 to remain on its planned trajectory during the quiet period."
I wonder why the reorientation is so infrequent? Is it a long process or a strain on hardware that you wouldn't want it to happen every day or even every month?
Reorienting requires using a reaction wheel or propellent to move yourself.
Propellent is finite, so you want to use it as rarely as possible.
A reaction wheel is by itself infinite (assuming it doesn't break), but eventually it saturates and you need to desaturate it, which basically means spinning the wheel the other way while spending propellent to maintain position.
All of this is to say, reorientation is an expensive process especially if refueling isn't an option.
>On the timescale of decades, does a 2 week vs a 10 week waiting period make much of a difference?
I agree. It probably doesn’t make much difference now. There are very unlikely to be any important data that will be lost. The mitigation process they already implemented seems prudent and sufficient
During earlier parts of the mission, like planetary encounters, it would make a difference. Even a two week wait could be much too long in those circumstances.
Presumably during encounters the probe was in a different control scheme to keep its instruments pointed at the planet, as opposed to keeping its antenna pointed at Earth.
In addition to the points made by sibling comments, there is always a chance something going wrong in the reorientation, so you do not want to do this more than necessary
The archived Japanese instruction wants to unfold the paper entirely, and then ... what? I'm stumped.
reply