Well, then I guess Germany's example is not too bad.

"CDU/CSU + SPD coalition won a majority" ... well, no. That's not how it works at all.

CDU and SPD did not win a majority together, since they were opponents in the election, and fought tooth and nail over, for example, immigration issues. They did not, at all, campaign together.

They both failed to win over half of the parliament seats. In simplified terms, they both lost. Everyone lost, if you will, because the system is not designed for anyone to easily win over half of the parliament seats.

That's why they had compromise and form a coalition. Thus no-one rules completely over the other and, in theory, the compromises of coalitions have a better societal outcome than the extreme views one party or the other might hold on a certain issue.

I'm not sure why the popular vote is an issue here. Every democracy has a system for aggregating votes to parliament seats and the transmission is never 1:1.

In this case: Votes for parties that don’t enter the Bundestag (e.g., those below the 5 % threshold) are not counted in seat allocation, making the share of seats for CDU + SPD higher than their raw vote share. Seats are redistributed proportionally among the parties that did enter parliament.

I don't see much of a problem. The claim that a fragmented territory with a multitude of small democracies is a good thing is a libertarian pipe dream. This view is quite frankly absurd considering that every government task is subject to economies of scale: defense, police, health insurance, social security, pension systems, roads, you name it. This is a scenario for winner-takes-all situations between nations, which is a much much worse outcome than even a winner-takes-all situation between political parties.

Quite a few countries have more or less successful parlamentary democracies, where winner-takes-all situations are avoided by design. In these, a party rarely has the upper hand and coalitions are the only means of reaching power. The agreements these coalitions forge to govern are a proxy of the compromises all societies have to agree on to function.

No worries. I want to help him, not fire him. I guess the team's situation is a bit odd at the moment.

It's the sheer 'randomness' and 'creativity' of the ways typos can mess up things and the frequency that set some people off.

I am sometimes even a bit baffled.

I definitely agree, that's why I wouldn't tell him that.

The json stuff was just an example.

I see your point about the positive side of it. I guess communicating this view within the team is important.

A string value in a json config needed to be updated.

On one prod instance, typo while updating the config by hand. Config validation of the software caught it, software stopped with the appropriate error message, a few minutes later we were up and running again.

We introduced work reviews on prod instances (similar to code reviews) after that.

Later, he then wrote a patch script to avoid making that mistake again.

In the json schema definition used in the script, the name of the property had a typo (how it came to be... no clue, copy paste should have taken care of that).

The script was part of a MR, the reviewer missed the typo. We noticed it in staging.

We introduced tests for config editing scripts after that.

And so it went on and on... The problem is not that it happens and we then refine our processes. It is the frequency.

The mentioned problems took an emotional toll, I suspect.

Maybe we should formalize the process around this.

Thanks for your insight!

Weird question but here goes.

My colleague has a strong work ethic, works hard, learns fast, goes out of his way to increase test coverage etc. I would say his contribution is net-positive but some of his work causes problems, especially when it comes to config files, shell scripting etc., so everything that is not directly caught by a linter or spell-checker.

His typo rate is quite high. I suspect an undiagnosed dyslexia.

Mistakes are often caught very late, mostly in staging, making it cumbersome. It led to a few production outages.

We have code reviews, a solid test suite etc. but typos are slipping through - once you make them, it's just harder for others to catch them.

I feel bad for him because it already led to a blame game within the team, with some asking how one can be so sloppy. I don't suspect sloppiness because he is otherwise thorough. On the other hand, it escalated because the subject is very touchy with him.

I suspect he is weirdly aware of the problem and in denial at the same time, and therefore extremely defensive.

His take is that we should increase test coverage. It is part of the answer. However, once he's involved in writing the tests, the problem is shifted to writing correct tests.

What I'm thinking about:

- engineer the problem away: adjust our tooling and config mechanisms, less strings in our configs, less dynamically-typed scripting etc.

- asking him to let AI review his code specifically for potential typos

- increasing test coverage, with other people than him writing the tests

What I am not considering:

- Telling him I suspect he has dyslexia. I'm not a doctor.

I'm trying to broaden my horizon on this issue, maybe I am missing something. What would you do?

Edit:

Example:

A string value in a json config needed to be updated.

On one prod instance, typo while updating the config by hand. Config validation of the software caught it, software stopped with the appropriate error message, a few minutes later we were up and running again.

We introduced work reviews on prod instances (similar to code reviews) after that.

Later, he then wrote a patch script to avoid making that mistake again.

In the json schema definition used in the script, the name of the property had a typo (how it came to be... no clue, copy paste should have taken care of that).

The script was part of a MR, the reviewer missed the typo. We noticed it in staging.

We introduced tests for config editing scripts after that.

And so it went on and on... The problem is not that it happens and we then refine our processes. It is the frequency.

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

Points: 14

# Comments: 49