I am a Developer Advocate for Security in Mobile Apps and APIs at approov.io.
Another passion is the Elixir programming language that was designed to be concurrent, distributed and fault tolerant.
Location
Scotland
Education
Self teached Developer
Work
Developer Advocate for Mobile and API Security at approov.io
Sorry but I completely disagree here... a merge request with the code review are necessary for each task, otherwise technical debt will grow out of control easily, because you will not get back to it later as you told yourself you would... you know the business always have a huge backlog waiting for you, and once you tell them that the task is done, is done, no time to go back to make SOLID and Clean Code.
Technical debt will occur whether you do pull requests or not. It's unlikely you will get code perfect the first time no matter how many people check it because the correct abstraction today is the wrong one tomorrow.
I will fix technical debt as I see it and in order for teams to go fast the business has to trust the technical team.
And as the post implies, in order to go fast you don't have a huge backlog waiting for you. You have short term goals that you iterate on over time and the team is empowered to make whatever technical choices they need to keep moving fast.
If you're in conflict with 'the business', if they're refusing to rely on your expertise, if you can't work collaboratively with 'them', if you're not in control of your own working methods and backlog... you've got bigger problems than can be fixed with code review and pull request fetishism.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think code reviews are great! Having them as a weekly thing with the whole team to talk about technical issues is lovely.
I dont think it's necessary to check the work of 2 developers who have worked on a task.
Sorry but I completely disagree here... a merge request with the code review are necessary for each task, otherwise technical debt will grow out of control easily, because you will not get back to it later as you told yourself you would... you know the business always have a huge backlog waiting for you, and once you tell them that the task is done, is done, no time to go back to make SOLID and Clean Code.
Technical debt will occur whether you do pull requests or not. It's unlikely you will get code perfect the first time no matter how many people check it because the correct abstraction today is the wrong one tomorrow.
I will fix technical debt as I see it and in order for teams to go fast the business has to trust the technical team.
And as the post implies, in order to go fast you don't have a huge backlog waiting for you. You have short term goals that you iterate on over time and the team is empowered to make whatever technical choices they need to keep moving fast.
If you're in conflict with 'the business', if they're refusing to rely on your expertise, if you can't work collaboratively with 'them', if you're not in control of your own working methods and backlog... you've got bigger problems than can be fixed with code review and pull request fetishism.