[seanwilson]

I think for new developers to a team, you shouldn't be letting them commit to master until you've got confidence they're not going to cause problems. I've done this several times in small teams (less than 10) for new members and it's essential for orientation in my opinion so they know what the team is looking for.

[qualsiasi]

I would love to do so, but we're always in a hurry for this or that project. I can't tell how many times I reported to the management that this way we're worsening our codebase and piling up technical debt. But revenue is revenue, and they always tell me "next year"... this is true also for education. I've been here for five years and attended only a mandatory course on workplace safety :)

[seanwilson]

Yeah, I appreciate it's not always easy. Some thoughts: nobody should be telling management "it's done" until code review is complete (which is true, and when you do otherwise management want to push you on to the next task because they won't understand the difference), tasks should be ready for code review a couple of days before deadlines and not on the deadline, and you need to educate management that when they push unrealistic deadlines where code review is skipped then they take on a large part of the responsibility for bugs that appear now and in the future.

In other words, they need to understand that code review isn't some bonus additional task but a vital part of healthy projects.

[qualsiasi]

Problem is that most of our work (90%) has deadlines established before getting most of the specs.

I know management should not be pushing us this way - but even being a team lead I can't change this. Time and resources are always fixed and deadlines are always so short that we can't review code nor do proper test & quality.

Part of my new years resolutions is to either change this mindset, gradually of course or change job, because working like this is not giving me the right professional experience to make the next step.