4 ms·

> Your 'senior' engineer is likely right: they are trying to get some kind of process going and you are actively sabotaging that Why? Because it's a "good prac

> Your 'senior' engineer is likely right: they are trying to get some kind of process going and you are actively sabotaging that Why? Because it's a "good practice"? They have 12 people and no customers, they can almost certainly adopt a very aggressive developer cycle that optimizes almost exclusively for happy-path velocity. You'd never do that at 50+ engineers with customers but for 12 engineers who have no customers? It's fine, in fact it's ideal. > with massive downtime as a result. They have no customers, downtime literally does not exist for them. You are following a dogmatic practice that is optimizing for a situation that literally does not exist within their company.

jacquesm 3y ago
You establish a process before you need it, and code review, especially when starting up is a fantastic way to make sure that everybody is on the same page and that you don't end up with a bunch of latent issues further down the line. The fact that they have no customers today doesn't mean that they won't have any in the future and mistakes made today can cause downtime further down the line. If you're wondering why software is crap: it is because every new generation of coders insists on making all the same mistakes all over again. Learn from the past, understand that 'good practice' has been established over many years of very expensive mistakes. 12 engineers is already a nice little recipe for pulling in 12 directions at once and even if they're all perfect they can still learn from looking at each others code and it will ensure that there are no critical dependencies on single individuals (which can bite you hard if one of them decides to leave, not unheard of in a startup) and that if need be labor can be re-divided without too much hassle.
- insanitybit 3y ago
  I'm not advocating for having no processes, I'm advocating for a process that matches their situation. A company with no customers should not be worrying about causing a production outage, they should be worried about getting a demoable product out. Dogmatic adherence to a process that limits developer velocity and optimizes for correct code is very likely the wrong call when you have no customers.
  - jacquesm 3y ago
    If it is dogmatic, then yes: but you have no knowledge of that and besides there are always people who believe there is too much process and there are people that there is too little. If you want to challenge the process you do that by talking about it not by breaking the process on purpose. That's an excellent way to get fired. I don't know the context and I don't know the particular business the OP is talking about. What I do know is that if you feel that your management is cargo culting development methodology (which really does happen) you can either engage them constructively or you can leave for a better company. Going in with a confrontational mindset isn't going to be a good experience for anybody involved. Case in point: the OP is still upset enough that he feels it necessary to vent about this in an online forum. Note that this is the same person who in another comment wrote: "On the flip side I’m trying to convince my CTO to fire half our engineering team - a group of jokers he hired during the run-up who are now wildly overpaid and massively under-delivering. With all the tech talent out there I’m convinced we’d replace them all within a week."
    - vrosas 3y ago
      Heh, both can be true. Process doesn't make good engineers any better. Bad code gets approved and merged every day. I'd rather have a team I could trust to merge and steward their code to production on their own instead of bureaucracy giving people a false sense of security. > Case in point: the OP is still upset enough that he feels it necessary to vent about this in an online forum. I apologize for the conversation starter.
nevinera 3y ago
With no customers, one of the purposes of code-review is removed, but it's the lesser one anyway. The primary goal of code-review should _not_ be to "catch mistakes" in a well-functioning engineering team - that's a thing that happens, but mostly your CI handles that. Code-review is about unifying approaches, cross-pollinating strategies and techniques, and helping each other to improve as engineers. Your attitude towards code-review on the other hand is one I've seen before several times, and I was glad when each of those people were fired.
- withinboredom 3y ago
  We did post-merge code reviews. But half our team was on the other side of the planet from the other half (4 people on the team, US, EU. APAC, and AU). If we waited for reviews before merging, we’d be waiting weeks to merge a single PR. Thus, you wrote your code, opened a PR, did a self-review, then deployed it. We had millions of customers, downtime was a real possibility. So you’d watch metrics and revert if anything looked slightly off. You would wake up to your PR being reviewed. Sometimes there would be mistakes pointed out, suggestions to improve it, etc. Sometimes it was just a thumbs up emoji. The point is, there are many ways to skin this cat and to “ream” someone for merging without deploying is incredibly immature and uncreative. You can still review a merged PR.
  - nevinera 3y ago
    That process sounds fine to me, especially in a context with either good integration coverage or low downtime cost. > to “ream” someone for merging without deploying is incredibly immature and uncreative. I'd agree, but I _highly_ doubt that description was an accurate one. Read through the other comments by the same person and you'll get a picture of their personality pretty quickly. It's likely that there was already an ongoing conflict either in general or specifically between them about this issue. They probably got a moderately harsh comment to the effect of "hey, you're expected to wait for code-reviews now, knock it off"
    - vrosas 3y ago
      I suggested it's possible to write, commit and own code without others' approval to increase productivity and people get _extremely_ defensive about it. It's so odd. It happened in real life and it's happening in this thread now, too. They even attack your character over it.
OJFord 3y ago
No, because you're not infallible, you'll merge some crap, some things that are outright wrong, that your reviewer might have caught and that slight delay is less painful than dealing with that commited mistake - whether it be an incident in production or 'just' confusion when the next person in that area has to work out if your bug was for some reason intentional and what might break if they fix it.

jacquesm 3y ago

You establish a process before you need it, and code review, especially when starting up is a fantastic way to make sure that everybody is on the same page and that you don't end up with a bunch of latent issues further down the line. The fact that they have no customers today doesn't mean that they won't have any in the future and mistakes made today can cause downtime further down the line. If you're wondering why software is crap: it is because every new generation of coders insists on making all the same mistakes all over again. Learn from the past, understand that 'good practice' has been established over many years of very expensive mistakes. 12 engineers is already a nice little recipe for pulling in 12 directions at once and even if they're all perfect they can still learn from looking at each others code and it will ensure that there are no critical dependencies on single individuals (which can bite you hard if one of them decides to leave, not unheard of in a startup) and that if need be labor can be re-divided without too much hassle.

insanitybit 3y ago
I'm not advocating for having no processes, I'm advocating for a process that matches their situation. A company with no customers should not be worrying about causing a production outage, they should be worried about getting a demoable product out. Dogmatic adherence to a process that limits developer velocity and optimizes for correct code is very likely the wrong call when you have no customers.
- jacquesm 3y ago
  If it is dogmatic, then yes: but you have no knowledge of that and besides there are always people who believe there is too much process and there are people that there is too little. If you want to challenge the process you do that by talking about it not by breaking the process on purpose. That's an excellent way to get fired. I don't know the context and I don't know the particular business the OP is talking about. What I do know is that if you feel that your management is cargo culting development methodology (which really does happen) you can either engage them constructively or you can leave for a better company. Going in with a confrontational mindset isn't going to be a good experience for anybody involved. Case in point: the OP is still upset enough that he feels it necessary to vent about this in an online forum. Note that this is the same person who in another comment wrote: "On the flip side I’m trying to convince my CTO to fire half our engineering team - a group of jokers he hired during the run-up who are now wildly overpaid and massively under-delivering. With all the tech talent out there I’m convinced we’d replace them all within a week."
  - vrosas 3y ago
    Heh, both can be true. Process doesn't make good engineers any better. Bad code gets approved and merged every day. I'd rather have a team I could trust to merge and steward their code to production on their own instead of bureaucracy giving people a false sense of security. > Case in point: the OP is still upset enough that he feels it necessary to vent about this in an online forum. I apologize for the conversation starter.

nevinera 3y ago

With no customers, one of the purposes of code-review is removed, but it's the lesser one anyway. The primary goal of code-review should _not_ be to "catch mistakes" in a well-functioning engineering team - that's a thing that happens, but mostly your CI handles that. Code-review is about unifying approaches, cross-pollinating strategies and techniques, and helping each other to improve as engineers. Your attitude towards code-review on the other hand is one I've seen before several times, and I was glad when each of those people were fired.

withinboredom 3y ago
We did post-merge code reviews. But half our team was on the other side of the planet from the other half (4 people on the team, US, EU. APAC, and AU). If we waited for reviews before merging, we’d be waiting weeks to merge a single PR. Thus, you wrote your code, opened a PR, did a self-review, then deployed it. We had millions of customers, downtime was a real possibility. So you’d watch metrics and revert if anything looked slightly off. You would wake up to your PR being reviewed. Sometimes there would be mistakes pointed out, suggestions to improve it, etc. Sometimes it was just a thumbs up emoji. The point is, there are many ways to skin this cat and to “ream” someone for merging without deploying is incredibly immature and uncreative. You can still review a merged PR.
- nevinera 3y ago
  That process sounds fine to me, especially in a context with either good integration coverage or low downtime cost. > to “ream” someone for merging without deploying is incredibly immature and uncreative. I'd agree, but I _highly_ doubt that description was an accurate one. Read through the other comments by the same person and you'll get a picture of their personality pretty quickly. It's likely that there was already an ongoing conflict either in general or specifically between them about this issue. They probably got a moderately harsh comment to the effect of "hey, you're expected to wait for code-reviews now, knock it off"
  - vrosas 3y ago
    I suggested it's possible to write, commit and own code without others' approval to increase productivity and people get _extremely_ defensive about it. It's so odd. It happened in real life and it's happening in this thread now, too. They even attack your character over it.

OJFord 3y ago

No, because you're not infallible, you'll merge some crap, some things that are outright wrong, that your reviewer might have caught and that slight delay is less painful than dealing with that commited mistake - whether it be an incident in production or 'just' confusion when the next person in that area has to work out if your bug was for some reason intentional and what might break if they fix it.