[255kb]

My take on this is that devs, in general, are managed by people who are still completely clueless about technology in 2024. There are surely exceptions (FAANG, etc.), but I've worked with my fair share of managers who couldn't fathom the work required to add a feature. It's always "just a button". Sales are easier to understand. You can describe it with words. Us devs use gibberish that nobody understands.

Scrum gives them tools to understand if there is progress or not: Is the burndown chart nicely on a downward trend? Are tickets closed? Is the sprint "green" or not? I won't blame them. They are clueless. But I hate it!

[nine_zeros]

> My take on this is that devs, in general, are managed by people who are still completely clueless about technology in 2024. There are surely exceptions (FAANG, etc.), but I've worked with my fair share of managers who couldn't fathom the work required to add a feature. It's always "just a button". Sales are easier to understand. You can describe it with words. Us devs use gibberish that nobody understands.

This is truth. A lot of "managers" in engineering just can't fathom the complexity. Even if they have an engineering background, even if they coded for 10 years, they can't fathom the complexity.

Some of the reasons I have discovered are

- They think of every project as "greenfield" with a clean slate, whereas 99% of the projects are built on old tech debt accumulated over years and increasing in complexity. Remember their old tech debt decision from Q4 of 2021? Yeah they don't remember it and can't fathom how that decision led to today's problems.

- They think every "headcount" at all the immense rungs of the ladder are the same. Remember that guy they fired in Q2 of 2022? Yeah they don't remember it and can't fathom how firing a person with context cannot be backfilled to the same level of context, even with an ex-faang label.

Ultimately, management does not see the pile of garbage their decisions have made. That pile is left to the garbage pickers (engineers) while they themselves just think about how to look good to execs.

[taftster]

I consider all of these "complexities" to be failures on our part. Our primary job as a software developer or technology specialist should be to reduce complexity, not add to it.

So the problem is that the one button is buried under stacks and frameworks multiple layers deep. Is it a failure of management to consider a single button change an easy task when it should, in fact, be an easy task?

And the guy that they fired (possibly for good cause). Did we take the time to train and/or learn the items that were handled by this person? Granted, maybe we didn't have management that prioritized passing that person's work off to the next candidate.

I think software developers are as just as much to blame as management for these types of problems. I am one of them, so I'm pointing at myself here too. There are problems to be addressed going in both directions, from my take.

[nine_zeros]

> So the problem is that the one button is buried under stacks and frameworks multiple layers deep. Is it a failure of management to consider a single button change an easy task when it should, in fact, be an easy task?

This is a great example. Why? Because you called out complexity. Specifically, that an engineering org should try to minimize complexity. And yet, the framework for adding a button is immensely complex. Why? Because management wanted a "complexity" aspect for the button framework project. Without the "complexity" aspect, the engineer on it wouldn't get a promo and management wouldn't get additional headcount for their own promo.

> And the guy that they fired (possibly for good cause)

Likely fired to serve a stack rank. Someone had to fall at the bottom in Q2 2022. Unfortunately their exact context and expertise is required in Q2 2024 and the backfill just doesn't have 5 years with our complex button framework yet.

I am sorry. Devs cannot be blamed for poor management practices such as "complexity" and "stack ranking".

[dk8996]

This is incorrect. Clearly defining tasks not only aids in tracking and reporting but also helps developers stay organized. It promotes transparency and effective communication, especially for remote teams working across different time zones. At all times everyone knows what they are working on.