Oh my poor business logic

That said, for those who do good work and develop long-term trust with long-term colleagues, addressing technical debt is often “poke at this while I sip coffee” work that get chipped away at gradually and without a lot of paperwork, or that gets quietly slipped in alongside other feature work.

When you’re having to pitch the work to someone, you’ve often already failed the pitch. The debt payment is already due.

But if your peers come to trust you, then they learn not to reject a PR that cleaned up this module a little more than strictly necessary or that included a commit that revisited an adjacent abstraction.

To get there, though, you need to work on healthy, stable teams with experienced colleagues rather than in the mad churn that seems to dominate a lot of work cultures these days.

I think this is a bit uncharitable. Yes, nominally everyone is trying to do this, but in practice this comes down to a lot of tradeoffs in terms of timeframes, team sizes, and maintainability/scalability. Even if you have balanced perspectives, what usually ends up happening in larger corporations is some group has a louder voice and more power, and ends up influencing decisions in a way that is globally suboptimal because executives are too busy, and local managers are too focused on their own silos/perf evaluation.

For example, complexity is often built into the product and systems according to the resourcing allocated to a particular problem at a certain point without a full understanding of the implications over time. However, when that complexity is found to have a poor ROI there is then a natural aversion to removing it because at that point it's hard to quantify how exactly the business depends on it. This creates a tax on the entire org, which many can observe, but structuring incentives to fix is fiendishly difficult, especially in comparison to new growth opportunities that get executives, board members and investors excited.

I was amazed. The Scrum master wasn't just some busy body manager who only ran stand-ups, he was constantly floating around throughout the day helping people out. We had 4 developers and 4 consultants, so we mostly paired up and that was super productive. Pivotal tracker was better than Jira. They had a strong focus on getting something working and collaborating. It was eye-opening.

Unfortunately, the company was picking 4 random employee developers from across the organization each week. Most of the organization was contractors, including everyone on my team aside from me. My team used Jira and had no option to use something else. Back on my team, the contractor Scrum master and contractor product owner continued to run the team incredibly ineffectively.

I can't tell if those few consultants I worked with were representative of Pivotal as a whole, but I will say that that week was a bright spot in an otherwise dismal part of my career.

I've heard some horror stories about Pivotal as well. Not everyone or every project was perfect. Their pricing is also insane. I'm sure your company paid through the roof for what you got.

But overall, the general education that I got there for how to run projects and build products is hands down the best thing I've ever learned in software engineering. It is funny, they don't teach that sort of stuff in schools as much as they focus on just teaching you how to code.

Oh and PT is hands down better than Jira, but that is a low bar since Jira is really shit. That said, it isn't necessarily about the tool, but how you use it. PT can be used for good as well as evil and knowing how to write stories, point them properly and manage them, is a learned skill.

I'm not sure when Kafka was last considered hip. Probably 2015?

Also, Celery is arse to maintain, so if you're already using Kafka, make the change.

If you're not, then don't.