[dennisgorelik]

The answer to your problem of "large commit" is this:

1) Create "research prototype" of your solution. But do not commit it or commit it into separate branch (not master).

2) Create a plan how to split that code into smaller steps. Separate refactorings that will support your new feature - from your actual feature (that changes functionality).

3) Commit refactorings separately from your main feature commit. Keep every refactoring commit as small as possible).

4) At the end commit your functionality changing feature. If possible, split it into multiple commits too.

That should help with code review.

Remember, your team will have to code review your code multiple times:

1) When you are making your commits.

2) When your code reviewer reviews it.

3) In the future, when you or other team members maintain your code and try to understand why you created code that way.

So - optimize your commit to reduce code review time (even if it increases initial code writing time).

[danmaz74]

Thank you for your answer, but I don't think that would have been feasible - our employer called me exactly because the team was very slow, and adding so many additional steps would make me very slow too.

I'm now changing contract, hopefully with the new team it will be possible to find a better compromise. For example, I offered to walk the reviewer through my code, which I think would have helped a lot, but this was refused...

[dennisgorelik]

> additional steps would make me very slow too

Your real choices are: "fast and buggy" vs "slow and correct".

What is your preference?

> I offered to walk the reviewer through my code

Walking reviewer through your code is a good exercise. Code review of complex change should be done in interactive session (code reviewer + coder). There is so much to learn for both sides in such session.

https://dennisgorelik.dreamwidth.org/161605.html

[danmaz74]

> Your real choices are: "fast and buggy" vs "slow and correct".

It's not a binary choice, it's a dial. And anyway, after more than 30 years of programming experience, I can tell you that I can write mostly correct code by applying diligently the pyramid of tests. In my experience, code reviews catch very few bugs that weren't revealed by testing, if any.

Much more than correctness, I find them useful to verify and improve the readability and maintainability of code - which are important goals, but as always the cost needs to be measured against time and cost constraints. Depending on the project, being twice as slow to accomodate the reviewer can or can't make sense. What I'm looking for is more of a 80/20 solution: can I be 20% slower, and still get 80% of the benefits of code reviews?