5 ms·

Well, here is one way to read your comment: "A feature not making it into a sprint" is your problem. You will get in trouble for that, it will make you look ba

by azov 4y ago

Well, here is one way to read your comment: "A feature not making it into a sprint" is your problem. You will get in trouble for that, it will make you look bad in front of your boss, etc. "Not following best practices" is not your problem. If the code turns into a mess, it's not you who will have to deal with the consequences, at least not you directly. As a manager you will demand that your senior developers fix that (while still shipping features, of course). After all, that's what expected of senior developers. So, the incentives for you and for your senior engineers are not aligned. Of course I don't know if that's even remotely close to your reasoning. I don't know you or your project or your priorities, I have no idea what "best practices" we're talking about and how reasonable it is to follow or not follow them in a given situation. I might be totally wrong, you may have all the right reasons to be mad about those reviews. But the comment makes it sound like your senior engineers are idiots who block PRs for no reason, and that can't be good for your team.

Ensorceled 4y ago
> But the comment makes it sound like your senior engineers are idiots who block PRs for no reason, and that can't be good for your team. Ah, I see, you think this is a general problem I have. No, in general my senior engineers are excellent and all the current ones I work with are. I've seen enough of the other, especially while contracting.
projectazorian 4y ago
> "A feature not making it into a sprint" is your problem. You will get in trouble for that, it will make you look bad in front of your boss, etc. "Not following best practices" is not your problem. Hmm, almost like this concept of “sprints” is unhelpful. It’s rare that delaying a PR by 24 hours to get it right has any relevance to business outcomes, in fact it is often better for everyone in the long run. But with artificial deadlines and fake metrics imposed by scrum, when this happens managers will often freak out because something didn’t “make it into the sprint,” or an engineer’s velocity dropped.
- klardotsh 4y ago
  Yep. At this point "scrum" (or "daily standups", but that's a separate issue), "sprints", or "burndown charts" are all run-for-the-hills red flags to hear about when chatting with companies, IMO. It shows a lean towards process for the sake of process, artificial deadlines and artificially subdividing work to fit within said deadlines, and sometimes a "we do this because everyone else does, without questioning it" cargo-cult mentality that often extends into the tech itself. There's exceptions, clearly. And the process does work for some folks. I'm glad those people are happy. It has rarely worked for me, or for teams I've been on.

by azov 4y ago

Ensorceled 4y ago

> But the comment makes it sound like your senior engineers are idiots who block PRs for no reason, and that can't be good for your team. Ah, I see, you think this is a general problem I have. No, in general my senior engineers are excellent and all the current ones I work with are. I've seen enough of the other, especially while contracting.

projectazorian 4y ago

> "A feature not making it into a sprint" is your problem. You will get in trouble for that, it will make you look bad in front of your boss, etc. "Not following best practices" is not your problem. Hmm, almost like this concept of “sprints” is unhelpful. It’s rare that delaying a PR by 24 hours to get it right has any relevance to business outcomes, in fact it is often better for everyone in the long run. But with artificial deadlines and fake metrics imposed by scrum, when this happens managers will often freak out because something didn’t “make it into the sprint,” or an engineer’s velocity dropped.

klardotsh 4y ago
Yep. At this point "scrum" (or "daily standups", but that's a separate issue), "sprints", or "burndown charts" are all run-for-the-hills red flags to hear about when chatting with companies, IMO. It shows a lean towards process for the sake of process, artificial deadlines and artificially subdividing work to fit within said deadlines, and sometimes a "we do this because everyone else does, without questioning it" cargo-cult mentality that often extends into the tech itself. There's exceptions, clearly. And the process does work for some folks. I'm glad those people are happy. It has rarely worked for me, or for teams I've been on.