aarch64 has cntvct_el0 status register that can be read from userspace.

Is it clean? Not always, it gets messy. On the other hand it is deterministic and traceable to specifications. Specifications as state machines can be easier understood and shared than raw code or raw prose.

I also think more effort is needed to synthesize a clean set of state machines with hierarchy for a system at scale and I'm sure there are times when that effort is not warranted.

Although i do wonder what my son's 国語 text books teach if Japanese is not the official 国語.

Comments URL: https://news.ycombinator.com/item?id=47255123

Points: 1

# Comments: 1

Kaizen and JIT are not good for revolutionary change. So I expect by bootstrapping different options early enough they can act on real market pressure once the condition to accurately assess the evidence is available.

For hydrogen getting to that point was a multi decade lead time.

I suspect most western commentary on this topic comes from people not understanding both how numerical/empirical based Toyota are, how self aware of their potential weaknesses they are, plus the ability of a Japanese business to hold to a multi decade hedging initiative.

The strategy clearly stated by Akio Toyoda is multiple power train technology. You can listen to his interviews on the subject, some are in Japanese, but as you have stated a clear and unambiguous interpretation of Toyota's policy I will assume you have that fluency.

(Automotive OEMs are assemblers, the parts come from the supply chain starting with Tier 1 suppliers. In that sense TMC does not do "making engines", but possibly the nuance and consequences here of whether not it "wraps it's head" to "makes things", vs if it has the capability to specify, manufacture distribute something at scale with a globally localized supply chain AND adjust to consumer demand/resource availability changes 5 years after the design start - in this context i ask you, can you "wrap your head" around the latest models that are coming out in every power train technology fcev, (p)hev to bev)

(I still remember the excitement of EDA tools _starting_ to support TCL and replacing the custom scripting engines they used to have)

I suspect the author has failed to explain enough to get readers outside of their preconceptions based on their experience.

In particular I think management and leadership have been conflated in most interpretations - his inaction is a form of leadership to promote personal growth for line manager and IC. The absence of management is the application of this leadership.

(But who really knows...)

exactly! my frame of reference...

the "obviousness" in the first is seen by everyone, the "obviousness" in the second is seen only by people able to break out of a collective mindset and unground their thought processes.

in the first the "wolf" is missing some obvious things, in particular the negative externality of their action. in the second the "wolf" is generally working on maximising the positive externality by generalizing problem space and solution space outside of the conventional fitting.

What the original article described is an engineer who could not stand by and let a painful problem with an obvious solution not be solved. the key point of the so called wolf is the obviousness of the solution. it was. ot obvious to anyone else, and to anyone else it would have been a major investment. the 10x does not come from frantic coding, it comes from a comprehensive and unique understanding that translates to code quickly due to motivation and understanding.

Process does not make an org more efficient. it makes it more consistent. if the baseline efficiency is low, the consistency of an improved set of work practices will ofcourse improve efficiency.

What a process often does is overfitting. Overfitting to the most common buiness need, sometimes overfitting to the noisiest patholgies seen.

The problem with process overfitting is that it excludes efficient solutions for problems that don't fit the previous set of business needs, or are not at risk of the previous set of pathologies. sometimes the process has a good pressure valve for this, pull the andon cord. do some kaizen, fire up the CMM level 5 KPAs. but sometimes just applying bespoke judgment is better.

I have been the wolf he describes. I also have been the manager he describes who lets the wolf have space and stand up for themselves. i have also been the manager who creates process and worflows and alignment and blah blah to dampen the noise of individual agency.

tech debt is an orthogonal concern.

You assume "lone wolf" types are "one trick ponies" who can't learn. You also assume the only interesting problem space for these people is technical/code.

The lone wolf has a big limitations in transitioning to scale: 1. managers do what the article suggested, and stay out their way. The lone wolf never gets the experience of being managed, so it is difficult to transition to manage others. 2. they don't get why others don't "get it". e,g the solution is clear , the code can be done in a day, the comprehensive system model in their head should be shared by everyone.... it takes time to understand that the average engineer works slow and steady on a small scale understanding.

I will suggest there is a lone wolf type manager too. This is not a productivity skill, but an adaptivity and mobility skill.

Whether or not the natural world has such wolves, its a fictional archetype.

It is a particularly common theme in Japanese fiction, where the deviation from the social hierarchy requires a stong force of individual will. Interesting it is also common in Japanese technology breakthrough documentaries.

Ogami Itto - Lone wolf and cub is the first thing that comes to mind when the author says wolf.