On being the employee who “needs improvement”

I've worked blue collar jobs where bosses are way more direct, like your Russian managers - and it's better. I remember one who would tell me most mornings, "Try not to fuck up today!" When a boss is angry and direct in giving feedback, we don't become resentful; we get scared for a while, then settle down. It's the natural way of hierarchy. We all need course correction from time to time, and the modern white-collar way sucks.

This guy's bad feelings were increased by his isolation. Compare this to an old school environment where you got yelled at by the boss, then emerged from the office to the jokes of your co-workers who heard the yelling through the door. That's a more natural environment.

(The old school boss sometimes fucked up by abusing an employee in front of co-workers. It should always be done behind closed doors.)

However in many years of corporate work I can rarely figure out what my bosses actually want or what they're thinking. They talk about corporate initiatives and get that uncomfortable "lying" body language, probably because they don't really believe this stuff but have to parrot it.

Getting back to your Russian managers - I think we are wired for hierarchy but we need certain signals to be comfortable with it. We like to work for bosses who are comfortable wielding power. When the boss projects too much weakness, the power relationship becomes very uncomfortable. I'm guessing that the remote bosses in the story didn't give strong course correction early on because they felt uncomfortable. They let the situation escalate, then took this drastic action.

It depends on what the work is like, too. In practice all of the most successful teams I've been on have been highly collaborative (i.e. reachable). The kind of team where everyone goes incommunicado for days on end working on independent deliverables tends to suffer from low velocity, poor team cohesion, and ultimately inferior quality. I'm collaborating with coworkers constantly throughout the day, including occasionally sitting in front of the same computer to work through something. Change latency from seconds to days and everything suffers.

> he thinks being against using goto in C/C++ is dogmatic, and that there is no need to develop a testing framework until the software is developed

The important thing missing here - context. There are perfectly valid situations where your friend could be right.

> he felt like one of those types who are more interested in their career bottomline than in developing good principles and practices of the work they do (something that disappointed me coming from him based on the person I knew for many years).

Maybe he wants to become a manager with good developped principles?

Of course you know your friend much better than we do. It's hard for outsiders to judge the situation.

This largely depends on the company. Once you have been PIPed often transfer options are limited. Personally by the time I get to the point where I am going to PIP someone I have already invested significant time and energy trying to help them through 1 on 1s, getting input from my boss, and trying to work with all tools at my disposal. If I need to get HR involved I have already made up my mind that they will no longer work for me. Once HR is involved in many ways what happens next is out of a managers hands. I view the creation of the PIP as the train leaving the station. The tracks lead to a specific outcome.

All that said I suppose if things really did change I would approach what happened next with an open mind.

In at least one company I worked at having PIP in your file meant that it would be impossible to switch teams ever again. What manager wants the potential liability.

Also if there are is stack ranking with a curve people are going to have to be PIPed just to make the numbers work (not justifying it, just saying it happens). Having watched people be hired on to teams for the sole purpose of being let go it is really important to know what is actually going on.

> There are perfectly valid situations where your friend could be right.

I didn't say he thinks banning goto is dogmatic (and I never heard him say that his team completely disallows any use of it). You could be against goto and still be okay with its occasional use.

He seemed to be of the opinion that there is no reason to be against goto in the first place, because he never felt goto's use hurting his productivity. (and his use of goto, the way he explained it, definitely was more complicated than the rare cases where I think you could let it slide, e.g., the way it's used in the linux kernel code to get to the bottom of a function in case of failure, etc).

And why should we be against goto in the first place? Unfortunately, you cannot answer this question in one sentence, or a paragraph. "Go To Statement Considered Harmful" is not a theorem that has a proof. You have to read about it, and ideally, you have to experience what spaghetti code feels like, and what a goto-free codebase feels like. If you're not willing to take such a dive, you would never find out the answer. And if you have opinions in favor of goto without taking such a dive, don't be surprised if I lower my opinion about you as a scientist/engineer.

> Maybe he wants to become a manager with good developped principles?

And call me a negative nancy but your chances of developing good practices have diminished if your bad coding practices are reinforced through internal awards and the like. And I have no doubt his contributions may have felt significant to the higher ups enough to decide this deserves an award. But only in the short term. If this code gives problems in the next quarter or something, do they go back and review if the hasty implementation in the last quarter and liberal use of goto had anything to do with it? Likely not if your company doesn't even have a coding-conventions document.