Doing code reviews is mostly a decision of the team. If you value your team mates and strive to have a maintainable code base, you better let someone else revi

Doing code reviews is mostly a decision of the team. If you value your team mates and strive to have a maintainable code base, you better let someone else review your code. And for me it doesn't end with looking for typos. I actually want someone else to critically read my code. Sometimes there is a comment missing, or variables and function names could be improved upon, default values should be different, and documentation could be improved. So many things can be improved when you show what you got to your team mates and they comment with questions and suggestions. I actually love the code suggestion feature in Gitlab. Some Git hosting tools are set up the way that you need approvement by N other people (N >0) and I'm not sure if this is a good thing. For some very simple changes this might be too much bureaucracy, for larger changes (maybe in multiple repositories or some larger architecture change) you might want to involve more than N developers. So I think it should be a cultural thing that is driven by the team.