And if your stated goal is to protect people’s off hours, this strategy is likely to sabotage that goal and cause them to waste far more time and get woken up much more often, and it stunts your engineers’ technical development on top of that. But it is a costly and cumbersome bandage for a problem that you would be better served to address directly. There’s nothing morally “wrong” with Friday freezes. So I thought it was clear that this said somewhat tongue in cheek, serious-but-not-really. You don’t get 100x parallel efficiency if you put 100 developers on a single problem. Now obviously, OBVIOUSLY, reassigning all your developer cycles is probably a terrible idea. If you're scared of pushing to production on Fridays, I recommend reassigning all your developer cycles off of feature development and onto your CI/CD process and observability tooling for as long as it takes to ✨fix that✨. So I responded with an equally hyperbolic and indefensible claim: (Much like the fact that you still don’t automatedly restore your db backups and verify them every night. Which is not to say that Friday freezes don’t happen anymore, or even that they shouldn’t I just thought that this was no longer seen as a badge of responsibility and honor, rather a source of mild embarrassment.
I remember saying things like this myself as recently as, oh, 2016, but I thought the zeitgeist had moved on to continuous delivery. I hadn’t seen anyone say something like this in quite a while. How “Engineering-Driven” Leads to “Engineering-Supremacy”.How can you tell if the company you’re interviewing with is rotten on the inside?.Twin Anxieties of the Engineer/Manager Pendulum.Advice for Engineering Managers Who Want to Climb the Ladder.Questionable Advice: Is there a path back from CTO to engineer?.
0 kommentar(er)
