If the plurality are bad at their job, maybe the role itself needs at the very least a hard look.

Any time you find yourself saying "It's not the field that's fundamentally broken, it's that (almost) every individual in it just happens to suck (at it)," you need to take a step back and realize that that's the same problem.

If you have to be exceptionally skilled at something to do it in a way that's net positive, and that field doesn't reasonable filter for the exceptionally competent, then the field is setting individuals up for failure, and needs to be restructured.

And if most people in the role suck at it, you by definition have to be exceptionally skilled to succeed. Even if from the outside it looks like the people just tend to suck and the field is easy.

Agreed, I used to believe the same until I worked with a good project manager. But in hindsight they went way beyond their responsibilities and actually served as a mix of product/project/engineering manager. So maybe author's point stands in the sense most "project managers" think their job is moving jira tickets from one state to other

My experience has been that a good project manager is critical at defending against other teams' (bad) project managers. The other PM's can cause a lot of trouble if they're politically saavy.

This applies to business analysts, scrum/agile people, communications people, and other non-technical project staff, too.

I've observed an arms race at play in my department. Our team used to be 4-to-1 developers to business people. But we've increasingly needed to hire more business people just to defend ourselves against political scheming.

I can think of many more that were completely worthless.

But the question is why? I spent a decade of my career in civil engineering, and on the whole every project manager I dealt with there was both at least OK at their job and important to the success of the project. None were useless. If other technical fields can reliably produce competent project manager, why can't software?

> Developers are absolutely terrible at balancing business and customer priorities with technical ones

True, but project managers are even worse! (There are always exceptions)

I completely agree. Even seniors who have just joined your org need a buddy to help get up to speed and pick their brain. Standup isn't the place to learn how to do your job.

The problem is that many linters are excessively pedantic, require workarounds that are just silly, and if we ask "does it actually improve things?" then ... often not really, not in a substantial way. Once you agree on the "big basics" like brace style or whatever makes sense for your language, you quickly get diminishing (often miniscule) returns.

This also ties in to what I call the "linter fallacy"; which goes something like:

"This code passes 56 linters"

"Therefore, it's good code"

And the related:

"Our code is a mess"

"I spent a week adding 56 linters and rewriting it all to pass"

"Therefore, now our code is good"

What really matters is "can I read this code naturally?" And if the answer to that is "yes" then it may be good code. Obsessing over whether it should be written with some small differences that don't really matter is just not useful for anyone.

To be fair, those who become uncomfortable from words are equally insane weirdos.

I am one of those weirdos that like to work on "un-sexy" things behind the scenes which hopefully makes the life of my colleagues a bit better with every attempt. I don't think it is necessary for small teams, and may even be considered a waste of time, but once a team is sufficiently big and spread out, I think a few people working in the background, keeping watch of things, cleaning up after people, proactively improving stuff, creating and enforcing rules and standards is very beneficial and necessary for a team's next growth spurt.

Everyone uses the same formatter & options (which really should have no options, but that ins't the reality for most languages). The formatter rules - move on.

Primarily it's protecting yourself from those weirdos by pre-empting them, though.

> I don't blame recruiters for the calls they make (e.g. ghosting,

False. This is not Tinder: if you don't want to move forward, an email stating as much is super cheap.

> How do you know whether the person actually worked at $FAANG_COMPANY for 3 years?

In the United States of America, you call the company. In Germany, employees get a certificate.

If you get 100 applications for an opening, your HR tool can automatically send emails to declined candidates. You do track which ones you’ve rejected in the past and which ones you go forward with, right?

And on and on. It’s not hard.

You're really speaking about documentation quality, though. The most horribly written code ever written can still do a good job of documenting what the "if" does.

I think the real takeaway here is that code quality doesn't really matter. The most horribly written code is still quite fine to work with if well documented.

You actually brought to my attention a metric that I hadn't previously considered but now desperately want: branch coverage. I don't need 90% of lines covered, because one cannot measure coverage of missing lines

  /* BadImpl.java */
  if (theFile.exists()) {
      doTheAwesome(theFile);
  }
  // uh, and else ... what?

  /* BadImplTest.java */
  @Test
  public void looksGoodTestCoverage() {
    theFile.create();
    instance.runIt();
    println("hurray, 100% coverage");
  }

  if (theFile.exists()) {
    ...
  } else {
  }

> should include only project managers and/or team leaders

The daily standup comes from XP, which has no real concept of project managers or team leaders. Under XP, everyone is considered to be the project manager and team leader, so to speak. Thus, that isn't technically possible in the strictest sense.

If you have a "standup" in name only for the benefit of distinct project managers and/or team leaders, then I suppose you can just not show up. If that raises alarm in the organization, you're the newbie and just don't realize it.

It's really bad when standups last for half an hour. A standup must include 5-7 people at most and last no longer than 15 mins. Preferably 5-10. Anything else should be discussed outside of standup between specific team members only.

[dead]