> Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design. This approac

> Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design. This approach probably works out because you have senior engineers laying out a lot of the core structure and architecture for how things built. There's a tendency for newer people to tacitly adopt patterns that already exist and replicate. However, this approach can be really problematic when you have a team that's primarily newer engineers. I've seen it multiple times and it's always the same result - productivity almost grinds to a halt over time because there are so many problems in the code base. The worst example I saw was switching teams and seeing the team velocity. We measured all the work in story points and used the exact same task as a baseline story point. The previous team with mostly senior engineers, a point took .5 days. With the new team that was started by all fresh grad engineers, a story point took a minimum of 3 days and usually bumped up to 4 days. This velocity lasted multiple years, even when the team had a much more balanced spread of senior, mid-level, and fresh grad engineers.