Yea this seems pretty bizarre, I mean I guess I'd expect it from this site, but the solution seems like it's advocating placing the blame on the engineer(s) (bad at estimations, too technical, not good at explaining repeatedly and in childspeak, write better code).
Not to mention the amazing advice of having telepathy so that you can explain things in line with the (models in her(CEOs) head).
And what if that model is totally wrong? Do we let the models continue to drift so we can keep the CEO happy? Should Scotty be cool with Kirk demanding he wash the sails?
Sometimes it's the graviton stabilizer. Sure, I can say "for technical reasons" to keep the CEO from getting the brain ouchies, but now no one has any idea of what's wrong and the CEO distrusts me because they think I'm making up vague excuses.
The relationship between a software system and the people who build and operate it does not get discussed enough in this industry. This read won't give you answers to the many questions we have yet to answer or discuss, but it presents the topic well enough that I hope it gets some of y'all to think a little more about it.
I'd go so far as to say that configuration details for specific runtime environments should never be the concern of the application/service/program itself. It's almost always a smell to me when I see "dev" "prod" "stage" "local" in code unless it's an abstraction over the configuration for some sort of logical runtime profile.
While this might be decent advice around the internal details of a Django application's settings, what's missing is a mention of who this approach is designed for. It appears geared for developers who work on the project because the internal details (module names like settings.local, settings.production) leak to the command line interface. This might be fine in some cases, but this advice is not universal. All apps have a configuration API and you might consider how that looks depending on who/what is running the application, even if it's people who work on the code.
I applied and had one brief interview with someone over video. Maybe it's just me, but I think it's reasonable to expect a follow up, possibly with some feedback, after an interview. But that didn't happen. Not the end of the world for me, but a detail I think that should matter to a company that touts a strong community horn.
Stop off! Drop a bunch "microservices" into the same network without any access control and you don't have a physical barrier at all! In fact, it becomes even harder to have a clue as to what's interfacing with what unless you can observe your inter process traffic.
This is a completely unrelated issue. Microservices have nothing to do with access control. If anything, they should lend themselves to more fine grained control, but again, microservice architecture says nothing about it.
Unrelated? I' beg to differ. More to the point, all systems have an access control model. It could be explicit or implicit depending on how the system is built. Regardless, it defines the barriers and boundaries between everything in the system.
The comment suggests that just by separating things in the popular sense of microservices results in a barrier to enforce separation of concerns. That's how I read it, at least, and I find that to be is misleading.
This is the crux I see around popular discourse of microservices. It's often presented without a broader context.
This is exactly the point of the original article by Monzo. Microservices don't provide any tool to deal with access control, thus you have to implement it yourself. I rather avoid that when I can.
I've been using this website for years. It's been so long now that I can't even remember when Grant Skinner, the former Flash/ActionScript guru, released it. Nice to see it shared here.
