Depends on the language and platform as well as how asynchronous things are. For example, lots of platforms have little to no debugging for scripting languages. I write a lot of Groovy on a platform that has a debugger that is mostly too much trouble to connect my IDE to since the platform can’t run locally. But even then it doesn’t debug the Groovy code at all.

And with asynchronous stuff it’s often difficult to tell what something isn’t running in the right order without some kind of debug logging. Though in most cases I use the logger rather than printing directly to the console so that it can be left in and just configured to only print if the logging level is set to debug which can be configured based on the environment.

I see this a lot less with developers whose companies actually provide decent IDEs. Especially front end devs or older devs who still use text editors.

Yeah, and contracting is weird, too. I worked for a company that built a product to regression test that upgrades to major components that our systems integrated with didn’t change some functionality that would cause incorrect pricing or other issues. The testers at the companies that bought it loved it, but it was an annual fee and they couldn’t justify the cost without a specific upgrade planned in advance. Instead, they all went back to spending up to 100x as much hiring contractors to manually create test data and analyze the results. Worst part is the divisions of the companies that purchased the software could easily have convinced the other divisions to use the software and there would have been plenty of projects every year even if one division only had one project every two years or so.

But nope. Can’t collaborate and share expenses or they’ll lose their funding. Better to have big spikes in spending so that they could look like they were saving money all the rest of the time. Otherwise, they would lose all of their permanent staff to budget cuts.

Yeah. I get it if it was a market where things change quickly, so all you need is a quick and dirty product to get your foot in the door with customers. And sometimes it’s easier to build something that is more targeted rather than collaborating to make a more generic solution.

I don’t work in that kind of industry, really. And the kinds of things I’m talking about aren’t things that take years to develop. For example, just in the last two months I built a solution that will make literally hundreds of small upcoming projects spread across four teams take a single two week sprint to implement for one to two people depending on complexity. Previously each of these were taking 3 to 4 people 2-3 months to implement. Plus tying down people from working on maintaining the existing system, so they were going to need to ramp up on engineers pretty quickly.

Plus this solution doesn’t require code deployments to onboard new customers, only to implement the new functionality that each of these small projects are adding. The old solution would have meant possibly having to wait months for a window to deploy code just to onboard a new customer because so many things were hard coded. Our system is extremely high volume and downtime can mean not just losing money, but fines from not meeting timeliness regulations, so deployments are heavily controlled.

And of the two months I spent on this it only was about a week of research and development. The rest was winning the trust of the other tech leads, gathering their requirements, and getting them all to agree on things like naming conventions. Both because they’d been burned too many times and because I’ve only been there for 2 years and wasn’t even a tech lead of my team yet when I started this, though I was about to be because the lead was moving to a newly formed team. And sure, if you had joined one of those meetings in that first week or two, it might have seemed like a waste of time with the bickering and nitpicking. But that’s just because they didn’t believe it was possible to collaborate and get things done, too.

The company was happily going to hire a bunch of contractors to build these things in order to maintain the silos and “competition”. It’s only because of a new manager, that I built trust with over the last year, that no one interfered when I started pulling people together and “wasting time” to collaborate. It’s not even that the middle management is doing these things maliciously in most of the places I’ve worked. They’ve just been brainwashed to believe that making people compete makes them more productive than making them collaborate. But it’s only the worst engineers that need that threat of losing. And only the worst ones that will stick around to play the game since good engineers just want to build stuff.

And this is how you end up with five different parts of the company building pretty much the same thing, because if there was a central team creating shared components, they wouldn’t bring in any profit to justify their existence. But hey, at least there are no dependencies. And competition between teams drives innovation, right?

So tired of this line. The first thing I do in any team I’m on is start building bridges, sharing information, and collaborating on shared components that have the features that all the teams need, so we’re not all wasting everyone’s time building ten crappy, buggy versions of something we all need with slight variation. And instead build a single, well designed and well tested version that suits us all. But it’s always an uphill battle. Experienced engineers are always hesitant to trust, even if it’s exactly what they all want. They get burned or even punished by management policy for collaboration.