Panel 4:
“But you inspire 6 people to work at peak capacity so that the team is as effective as 9 people, and they all say you give a shit about them, their growth, and doing the work that actually matters with guidance and appropriate comp adjustment. Be a manager.”
If you work with incompetent middle management, move. When you work for a great manager in a great team, you feel bulletproof.
The author’s primary gripe, IMHO, has legs: the question about the oven’s relationship to baking is buried as part of bake() and is weird. But the solution here is not the left-hand code, but rather to port some good, old-fashioned OOP patterns: dependency injection. Pass a reference to an Oven in createPizza() and the problem is solved.
Doing so also addresses the other concern about whether an Oven should be a singleton (yes, that’s good for a reality-oriented contrived code sample) or manufactured new for each pizza (yes, that’s good for a cloud runtime where each shard/node/core will need to factory its own Oven). The logic for cloud-oven (maybe like ghost kitchens?) or singleton-oven is settled outside of the narrative frame of createPizza(). Again, the joy of dependency injection.
To their other point, shouldn’t the internals of preheating be enclosed in the oven’s logic…why yes that’s probably the case as well. And so, for a second time, this code seems to recommend OOP. In Sandi Metz style OOP in Ruby (or pretty much any other OOP language) this would be beautiful and rational. Heck, if the question of to preheat or no is sufficiently complex, then that logic can itself be made a class.
As I write, I thought: “How is golang so bad at abstraction?” I’m not sure that that is the case, but as a writer of engineering education, I think the examples chosen by the Google Testing Blog don’t serve well. Real-world examples work really well with OOP languages, fast execution and “systems thinking” examples work great with golang or C. Perhaps the real problem here is that the contrived example caters to showing off the strengths of OOP, but uses a procedural/imperative-style-loving language. Perhaps the Testing Blog folks assumed that everyone was on-board with the “small factored methods approach is best” as an article of faith and could accept the modeled domain as a hand wave to whatever idea it was they were presenting.
I’ll bite.
So one way of reading this is that you’re surrounded by incompetents. Early in my career I thought this. As a corollary to Chesterton’s Fence, it turns out I wasn’t so special and most weren’t so dumb. In a high-density area, being truly surrounded by bozos is just unlikely. So my advice here wouldn’t seem to be folly. If one tries several roles and every one is just full of bozos, it suggests that the one is in error.
Another way of reading this is that you are not in a high density area and perhaps the monopoly-oligopoly players who offer the work to which you are called are so few that the incompetent middle management is entrenched in these few spots and you’d love to leave but burning bridges / no proof the grass is greener suggest stay put. But with so few businesses, theoretically they have their pick of market and would not hire bozos. So, again, moving seems viable and not folly.
Lastly perhaps the factor is life/circumstances/education for you. Like if these desired roles require retraining or expensive certification. I feel for you if this is the case. But since you see those skills’ value, perhaps current-job learning/practice opportunities on-the-job could level you up to be able to hop to greener pastures. Most companies etc of even meager size have some tuition assistance program. Maybe that’s your way.
Regardless, this is your one precious life. I hope you’ll find access to your truest calling. It might be harder than what I said: “move” (such dismissive tone probably resultant from the ignorant perspective of the comic), but I’m confident your creativity and capability can point you in a path toward your flourishing.