From reading the article, I think the author of the post has ego issues: "we are actually seeking satisfaction from the looks of envy and admiration that we draw from others"

Admiration maybe from someone close to me, but envy?

I do not want to create any envy in other people's mind:

- either I like/love someone, and I don't want they feel bad

- or I am indifferent, and I don't really care

About prioritizing, I want to share a story:

We were a small and good team developping hardware/software combos. We ruined a demo to a client by promising some hard to do feature, and during the demo, the said feature had not been well tested for a particular environment.

The debriefing of that failure was memorable. The big boss was yelling at us, saying we should do better, work harder, longer, whatever was required to succeed.

When this calmed down, I only asked one question: when going back to my desk, should I work on this new feature promised to some other customer, or test this old one for any combination of inputs/environments? The response was: "You do both" I insisted that I will do both, but which one first? He responded with some blabla I do not remember, but no response to my question.

To any manager which cannot decide between feature and stability: If you cannot prioritize, the dev will do it, with whatever information/incentive they have. You may not be happy of the result.

Eventually customers will demand stablity as a feature.

Or, say, your Samsung washing machine detects on your home network your Bosh fridge and try to use any vulnerability to brick it (and the fridge tries to brick the washing machine too). Appliance war...

If people know this, it would be a incentive for consumer to buy all from the same brand. If all manufactures knows this, they would need to pay more attention to security (or at least resilience).

Not sure what/who wins in the end

They'll be hacking each other and fighting with knives and silverware when your back is turned.

Imagine having to discipline your appliances after they blame each other for starting it.

the black mirror we deserve

Well, put too much inconvenience and some "smart" guy will circumvent it anyway.

I have not personnaly worked in industrial environment, but from people I know, security wise, it is very scary at some places. Here is one such example of a "smart guy":

The IT crew of a factory have a sane policy of deny all traffic, except some well thought out rules.

A supplier would like to open a remote connection for maintenance of the equipment. Since the process for opening some traffic for a short duration is so convoluted, they finally install a 3G card inside the equipment (without telling their customer, and they even make it a habit for future install) so that they can do maintenance whenever they want.

The IT crew still thinks all is safe from outside...

That's pretty much sabotage.

Did someone in this story report it to the company management? This sounds like a clear lawsuit (or at the very least, contract termination) waiting to happen, and one that would scare other vendors away from such "clever" workarounds.

I don't know about management, but the guys on the factory floor were aware and happy with it. It made their job more convenient too, and the supplier was marketing its solutions as secure, so don't worry ;-)

> the guys on the factory floor were aware and happy with it. It made their job more convenient too,

Oh, I don't doubt that :).

> the supplier was marketing its solutions as secure

... but I very much doubt the truth of that marketing :).

I think it's still a ticking liability timebomb. At some point some external auditor will discover the backdoor to the plant and heads will roll.

The 3G thing is extremely common. Even with HUGE suppliers. Including Siemens Energy. Their steam turbine systems come with a 3g connection as standard. I even think they won't do 24h/7d support without it.

"they don't have a good idea of who's benefiting and who's losing"

This reminds me of a poker analogy: if you sit at a table and do not recognize the idiot at the table, it's you

I am the first to ask for quick feedback loops, which makes the dev environment so much enjoyable. But I have also seen some detrimental long term effect of this.

I have seen developpers "coding to the test". By that I mean they are modifying a piece of code they do not know well, and assume that if test pass, that must be good. Without understanding that test will never cover all possible inputs/states of the system. This "coding to the test" can appear very fast with a quick feedback loop, making possible to "monkey code" something until it passes. If you do not have careful review, by people knowing the system, this will end badly, with race conditions only appearing in production, integration failing randomly.

"Teach your employees that if you don’t want to be interrupted you better write good documentation."

And reward them for doing it.

If your company do "360 degree" evaluations where your peers praise you for your quick answers to their questions, you are effectively incentivised to NOT document and instead be interrupted...

One does not preclude the other. Your quick answers can come in form of sending them links to the relevant parts of the documentation you wrote earlier.

And if their question is not something that can be answered that way, you can improve your documentation so that next time the question is asked, you do not have that problem.

It is never too late, but do not let that be an excuse to delay any decision.

42 here, already two major career changes. And I am glad I made both changes.

> It is never too late, but do not let that be an excuse to delay any decision.

Beautiful, this is the explanation I was looking for because whenever I'd hear that "it's never too late," I just felt like that enabled procrastination, but your explanation solidified that life is not long, but rather it is short indeed. It's true that it's not too late for many of your future opportunities, but eventually, time will run out.

The differential (ignoring locking ones) applies the same force (approximately) to both wheels. If you remember your physics course about lever and force, see the video at 5:00, you can see that the lever is pushed by its center, hence both sides have the same length. So the same force is applied to both wheels. But the speed can be different.

Hence, if one wheel is stuck, it still receives the same force as the other, only speed is lower.

What is more annoying is when one wheel is freely slipping (like on ice), the other will have nearly no force applied to it and the car is stuck.

> What is more annoying is when one wheel is freely slipping (like on ice), the other will have nearly no force applied to it and the car is stuck.

i've learned about this the hard way about ten years ago: started my car, put it in first gear (manual), stepped outside and marveled at the freely spinning wheel on a patch of ice.

fortunately got a push from a stranger who happened to pass by.

> you can see that the lever is pushed by its center, hence both sides have the same length. So the same force is applied to both wheels.

This is not necessarily true. Imagine a similar symmetric lever with a weight on one side, and a force on the axis that accelerates rotation. The acceleration of both ends of the lever are equal, but the force is not equal (since the weight is 0 on the other end).

Anyway, the point of my comment was that a thorough analysis of this configuration is more involved than this video of which it was claimed that it "perfectly" explains how this works.

Sorry I do not understand your weight/force analogy. I assume that in a car, both sides have equal weight/inertia.

Anyway, I did write "approximately" to avoid discussing acceleration/inertia of the differential itself. I should have written "in steady state" or something like that. It is true that a complete discussion can be more involved

I did that for Richard Burns Rally