3 ms·

Well, what I'd say to that is: * Somebody maintains that code. If it is only you you have a bus-factor of one if none of it is actually reviewed. If it is not

Well, what I'd say to that is: * Somebody maintains that code. If it is only you you have a bus-factor of one if none of it is actually reviewed. If it is not you you are imposing a single persons idea of what the business problem is and how it should be solved on the maintainer, which they might not agree with * Personal development depends on realizing when you are wrong or have used the wrong tool. If nobody challenges your decisions you will probably not realize that as often (or at all) and therefore not improve as much. * Solving business problems means solving problems for a business. Usually businesses evolve over time, so the business problems might change. Who will understand the code in that case? How do you know the code is understandable to other people if nobody else reviewed it? And as for the house example: before buying that house I would definitely hire somebody else to check it, and that is legally required in some countries. I don't trust anyone to rate their own work. In this case the person who hired your consultancy bought the house, and they should definitely have an expert that did not build it check it. --- Just a FYI: I'm also a consultant, but work on a project where we have discussions about how to structure the code and do code reviews and so on.

kareemm 7y ago
Yes yes, I agree with all that. I much prefer to discuss approach with someone senior before tackling hairy problems and have others look at my approach after the fact to improve. But since I often work with clients where I am the dev team, I rely on my professional network to discuss approach. Agree that getting a technical review from a third party isn't a bad idea. FWIW this doesn't change my main point: the business owner cares about outcomes, and not code structure (a good outcome is dependent on the code being good enough to maintain e.g. the house not falling down). There's a simple test for this BTW: write lited, beautiful code that doesn't solve the business problem you were hired to solve and see how popular you are with your client.

kareemm 7y ago

Yes yes, I agree with all that. I much prefer to discuss approach with someone senior before tackling hairy problems and have others look at my approach after the fact to improve. But since I often work with clients where I am the dev team, I rely on my professional network to discuss approach. Agree that getting a technical review from a third party isn't a bad idea. FWIW this doesn't change my main point: the business owner cares about outcomes, and not code structure (a good outcome is dependent on the code being good enough to maintain e.g. the house not falling down). There's a simple test for this BTW: write lited, beautiful code that doesn't solve the business problem you were hired to solve and see how popular you are with your client.