Preferences:

https://www.linkedin.com/mypreferences/d/settings/data-for-a...

Objections:

https://www.linkedin.com/help/linkedin/ask/TS-DPRO

Unfortunately, the curse continues: follow up with how the text gradually coalesces as understanding grows. Realize how much easier it is after completion. Forget what "don't know what one doesn't know" felt like.

At least the beginner perspective captured enthusiasm, empathy (an alternative error condition for a path to a hidden file), and the request for feedback.

They're not necessarily prohibited from asking questions if they're stuck, though. But also search in the chat channels for similar issues.

Updating docs in source control also onboards folks to code review. It would be weird to update docs and get a hostile reception.

While nice to walk through with someone and conduct a usability study, just leave it better for the next person (who could be yourself, if you forget). That has happened before.

Clean design. Couldn't find beef or steak, dishwasher closed, and stove on.

Link to roadmap: https://kitchensvg.com/roadmap

Thanks, adding to the roadmap.

Review implies the requested changes are made by the requestor, not the reviewer. Maybe article meant refactor, rewrite, or otherwise revise.

It may not be about governance at all. Maybe the idea was that everyone consuming xz would also contribute to xz. Rather than pave over for the highway, plant trees along the road instead.

That would more be the model of many individuals though, not many enterprises.

For reducing external dependencies, it would be nice to somehow know every call made to a package, generating the call tree to replace. That becomes the API of the internal, replacement package.

You mean this: https://npmgraph.js.org

Thank-you, that looks pretty useful. Prior attempts involved `git blame' in projects' package.json per package. For example, to find when a project adopted React x+1 in which version, to determine the next minimum upgrade (to React ^x.y).

Consuming a package also means following its development alongside one's own. Multiplied by each dependency, it's a commitment to a particular constellation of dependencies. Migration guides and codemods help, but ultimately maintenance requires active participation.

That takes time--often more than what's available.

Not sure that's possible with JS.

You could theoretically overwrite the public functions of a module, inject some logging code, then execute the originally intended function when it's called with ".apply()" and passing the original arguments in.

That might get you part of the way there.

Yes, some automated instrumentation equivalent of `debugger' at the start of the module's first such function, and stepping into each function down to some depth, then starting over with the next line of the module's implementation.

A partial or semi-automated, tool-assisted approach might be possible, if there were a way to restart Node.js between decisions. Each decision point writes an entry "event" that records the filename, function, caller, line number, etc. Then `debugger' is inserted before the next line, and so on.

I'm thinking eval's and prototype overloading would make this a permanent cat and mouse game.

Frankly, I don't see how the node ecosystem can ever be secure. It's random-libraries all the way down. With half of them being useless frippery.

Imho, WASM compiled from languages that have strong standard libraries are the way forward for security. And, maybe node will get fixed in 5-10 years.

A good example of a language going "this shouldn't be a library."- Net used to only have a third party json parser (newtonsoft) but microsoft created a first party json parser and deprecated newtonsoft from their examples and templates

If mobile came with its own compiler from the beginning, like a general-purpose computer, it might be a different decade.

How do you refute your manager? Not only are they now biased to the answer, but without their own aesthetic (experience), it will cost you double: once to try the AI solution, and then another to try your version.

Suppose you're wrong versus the machine; they will think you are less consistent, even though every problem context carries its own nuance.

Having to, in good faith, try both avenues every time sounds exhausting.

You're assuming the manager will dictate the design/work, without feedback. Maybe I've been lucky, but I've never seen this in a technical setting, unless the manager was actually contributing to the technical work. The sorts of managers that micromanage and dictate like that don't last in technical environments, because they limit the teams technical ability to their own, and their ideas never make it past technical meetings/design reviews when others are involved.

Very lucky.

Wonder if Lucifer would admit Jesus is sort of a loophole, a divine hack of the system. Maybe rebooting Earth is just too expensive.

Job says, "Look at all these bugs," and the architect asks, "Where were you when I designed the hardware?"

Eternal life with obedience, or a stunted one with knowledge of good and evil.