• 0 Posts
  • 18 Comments
Joined 8 months ago
cake
Cake day: August 20th, 2024

help-circle






  • A skightly different view, but when I started a lot of companies did give back. I have worked with, hired, managed and led at least a half dozen teams with the explicit mission to make an already existing open source project do what we want by contributing functionality upstream, or by forking the project. I actually wrote a “open source engineering management” curriculum back when I was still teaching.

    Unfortunately these efforts often sttuggle in a similar way - some developer who is not affiliated with us starts creating friction, and blowing up internal schedules, sometimes seemingly on purpose. Management starts to ask why so many of our features are dependent on SkankTopia6969 approving PRs and awkward conversations ensue. And then the project slowly becomes the process of educating an increasingly detached internal hierarchy on the realities of open source development, and people inevitability start asking why this is even in-house tooling in the first place.

    Despite that, I’ve fielded a bunch of products like this, though always at fairly small scale (like $10M/yr revenue). The only time I’ve really done it big league the project got canned during a technical reorg.


  • Best i can imagine, this is what happens if you are terrified of smart pointers, but also want to make all object pointers scope specific. So at every layer of hierarchy, you have a unique reference to some partial implementation above and below it.

    Honestly I struggle to imagine any real scenario where this would make sense… except maybe like some kind of insane recursive factory.









  • Right, the entire issue is that it basically acts as a massive layer of insulation between reality and bad management. The whole thing is like a fucking paradox - any time you make a change to workflows or procedures there’s this stupid period where you need to “wait for buy in” where it doesn’t matter how outwardly idiotic the change is, you can’t actually call it obviously fucking stupid for like several weeks, or you are seen as being contrarian, or causing trouble. And the real bullshit is that the “better” the tools are, the more this effect is amplified. So as an engineer, I have paradoxically come to appreciate bad management tools simply because when someone does something stupid with them, I can call it out more easily.


  • The issue is more that all of these planning tools enable bad managers to implement bad management practices and workflows without any actual tracking for what constitutes bad management. Almost without fail, every manager I’ve worked with who is very attached to these products ends up using them for the sake of using them. And then when that produces shit results it’s all about “engineering buy in” and “process learning curves” and they end up doing real damage to products before someone notices that Jira actions are not correlated with protective management.

    The biggest issue is that good, effective management tools actually end up being a double edged sword because of how they shield bad managers the illusion of legitimacy.