It’s important to remember that your development and deployment infrastructure uses programs, written by programmers. Because of that, sometimes things will break, and while that’s not fun, it’s still just programming – report bugs, try to figure out fixes and workarounds, discuss, and contribute, just like you would with any other programming situation.
Of course, if you encounter bugs and refuse to report them or try to fix them or even document them, I’d say you’re working against your own best interests. You’re far better off participating, even if it’s as shallow a participation as “Hey, I found a bug when I …” because that at least helps track the number of people affected by a problem.
And in the end, it’s a programming problem – it’s likely to get fixed, because we, as programmers, like things to work. It’s pointless to just throw shade at systems, regardless of what they are or even if they deserve it.
Problems are just problems. There are solutions.
In May of 2016, a programmer removed left-pad from the the Javascript ecosystem. In the process, he broke thousands of dependent projects that used left-pad.
This was a big problem. (Thank you, Captain Obvious!)
But why is it such a problem, in the grand sense of things? I’d say it was a serious failure, to be sure. But triaging the issue realistically, there were workarounds in very little time (namely, replacements for left-pad) – and it also highlighted the importance of redundancy and licensing in the Javascript ecosystem. Two problems, one fairly limited (the dependency on left-pad) and one broader in scope but normally something people were able to ignore (the availability).
Both ended up being addressed, one way or the other. People learned. People moved on. Sure, there was a lot of griping about a brittle ecosystem, and maybe it was deserved to some degree, but … truthfully, the only comments that would have been worth paying attention to were the ones that tried to fix the problem, or at least acknowledged that it was only a problem.
More closely to home, some of my infrastructure tooling at work failed thanks to a Docker upgrade; Docker itself didn’t fail, but a tool that used the Docker daemon to build images started failing.
One of the comments from a fellow coder: “This is why I don’t like the JVM.”
My response – kept to myself, I hope – was not entirely positive, let’s say. That’s a dumb response. That’s a knee-jerk response; it doesn’t acknowledge that infrastructure tools are programmed, too, and things happen.
Docker changed; the tooling is changing, too; it just takes time. The timing’s inconvenient, sure (I changed the build process to avoid that mechanism), but it’s just a problem. It will be fixed. The bug was reported. Information is being exchanged. The tooling will be fixed, because there’s no way I’m the only person who’s encountering this bug (and I’m not; others have reported it as well.)
But the proper reaction is definitely not to decide that the entire ecosystem associated with what you’re working with is broken; after all, other ecosystems are going to have their own bugs, too.
The solution is to communicate and participate; use a workaround (like I did) if you have to, and sometimes you do, but don’t abandon the process. Report. Heck, patch if you can.