This reads an awful lot like post-how justification of poor business practices.
It’s got a bit of”uhhmm actually, poor management and high turnover is good actually” vibes, which is then (over)extended to a kind of carte-Blanche justification of “why using kms and having no idea of what’s going on” is good-and-desireable.
Which is like, certainly a take, and I can think of at least one “technical skills hating” exec from a past life who’d read this and foam at the mouth to feel justified in their decisions to try and throw all engineering practices out with the proverbial bath water.
I read it more as pointing out the inevitable and accepting the implications. You can not call it the result of poor practice when every business beyond a certain size has this problem.
Perhaps the problem could be mitigated by keeping the company itself small, but that has nothing to do with programming anymore.
Either way it's a cop-out. At least make the effort to have a cleanly built, well-understood system. Sure there will always be poor practices built into a system, but the number of places this happens can be mitigated.
Looking at this blog post, and the history of blog posts from this blog on HN - Goedecke apparently assumes his audience is VP's and CTO's. Goedkecke doesn't quite write the anodyne sound bites that Seth Godin does, but neither does he write anything of engineering use, just vocabulary explainers for people who want to know kind of what their tech leads and line managers are talking about.
I think he is a good example of someone who writes mainly to show he is ready for the next rung of the corporate ladder. That is, his posts are not meant to be useful, but to show higher-ups he is useful to them.
Goedecke seems to me like a Professor Pangloss type character, explaining to executives in prestige tech orgs (like his employer GitHub) why we should trust and respect the decisions of executives in prestige tech orgs
> However, at work you are paid to do a job. In other words, they pay you money to adopt their set of engineering values. It’s hopefully well-understood that however much you might personally care about performance, sometimes you have to write slow code at your job (for instance, to get a project done on time, or to accommodate some awkward requirement). Maintaining a theory of the codebase is the same kind of thing.
Sure, yes, this is basically the difference between a professional and hired goon. And it is true that the majority of software devs operate as hired goons.
For enough money, I will do (almost) anything management tells me to do. Not my circus, not my monkeys.
It’s got a bit of”uhhmm actually, poor management and high turnover is good actually” vibes, which is then (over)extended to a kind of carte-Blanche justification of “why using kms and having no idea of what’s going on” is good-and-desireable.
Which is like, certainly a take, and I can think of at least one “technical skills hating” exec from a past life who’d read this and foam at the mouth to feel justified in their decisions to try and throw all engineering practices out with the proverbial bath water.
Perhaps the problem could be mitigated by keeping the company itself small, but that has nothing to do with programming anymore.
We can choose human-comprehensible scopes and do that all the time with modules, packages,services, APIs.
In nobody understands it all , "it" is doing a lot of heavy lifting and given the choises we can make is wrong and should be resisted.
Deferring to their experience, but thinking, "Is this what winning is?" And wondering if that is the natural endpoint of progression.
Sure, yes, this is basically the difference between a professional and hired goon. And it is true that the majority of software devs operate as hired goons.
For enough money, I will do (almost) anything management tells me to do. Not my circus, not my monkeys.