I don't understand your viewpoint at all.
The best part about coding for me is getting a review with a lot of interesting comments about how it could be done differently. It jogs my brain down paths I would never have seen by myself.
It's like living in a house: as long as it doesn't fall down and doesn't cost unreasonable amounts to maintain, I don't really care about how well-formed the mortar is, or that the drywall is hung perfectly according to company standards. I just want to live in the house and not worry about it.
* 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.
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.
> writing code is having it solve real business problems
Sure, but writing good code is about solving future problem the business is going to have too. A problem has more than a single dimension.
If your code will never evolve, if it's a definitive solution to their problems, the structure doesn't matter that's true, but sadly, that's almost never the case.
The structure matters to the outcome; but the outcome problems of bad structure tend to manifest after paid-by-engagement contractors have left.
* defects - The application has certain defects or it doesn't and you can prove it with tests. If there is a defect I will prioritize it, or solve it immediately, or mark it as won't fix.
* performance - Does the application execute fast enough in all stages and interactions? This is a simple yes or no, but performance testing is often volatile so this needs to be tested and measured as well so that it can be observed over time keeping slippage in mind.
* ease of use - Does the application work out of the box? If not its broken. If it requires a bunch of manual configuration then nobody will use unless its forced on them. For this I take all my frustrations with corporate software from my past jobs and I intentionally design against that when I write software and encourage my users to complain to me.
* documentation - Does the documentation stand on its own? Is it complete, well organized, and simple enough that a high school freshman can read it? If you cannot write you aren't as great a developer as you think you are.
There are minor code style preferences and others that affect maintainability. Just because it works now it doesn’t mean the code is done.
I’ve found all kind of bugs just refactoring code because poor code obfuscates them.
Your way of building things will lead to debt and bug reports
Why create a function that shortens/clarifies nothing and is used once? If you want to explain some code, use a comment, don’t make spaghetti
Other programmers care. A one/two man workshop doesn't need order or processes to get things done. A ten man workshop cannot function without it. The same is true with coding - it becomes a tool for programmers to communicate intent, it's becomes important to be ordered, clean and understandable by every other dev.
> it's becomes important to be ordered, clean and understandable by every other dev
Code style is the wrong tool for that job. Better are code reviews and written documentation.
I did work somewhere during the dot-com years and we had an entire meeting about double spacing. Whether we press enter TWICE after an if-statement bracket, or once. I hated every second of it.
Is it true? If I read book or blog, I improve my skills. Sure, feedback helps but I don't think that it's a hard requirement.
I didn't quite realize this until, after 5 years of building things on my own, I had a co-founder. I feel like I gained 10 years of experience just from working with him and having to explain my solutions or why I didn't consider this other one, or having to realize that I was in fact wrong. That's a hard pill to swallow when you've only worked with books.
Craftsmanship is more than just learning new things. Sometimes you need to have your entire model of what's best swapped out for new ideas, like society realizing a republic is better than feudalism, than never evolving past your original position.
That said, I think the person you're responding to meant outside feedback as in opinions from peers, which I agree is very powerful, but not strictly necessary.
2) standard practices, idioms, consistency.
You can't use tabs if the entire company uses spaces or use Python if it's a Java shop.
3) Because in most cases, an extra set of eyes can help provide real, material constructive feedback.
I have little trust that any standalone developer is going to just write 'solid code'. Who has that level of self-awareness to recognize they are 'that good', let alone actually be good without help?
It's a basic matter of professionalism to work with others and to be good team members, without it, we're not going to get much done.
For smaller projects with very clear requirements, it matters less.
It'd be like telling a construction worker taking a water break: "That's the nice thing about the office jobs. No need to worry about hydration because I'm not out in the hot sun all day." I have a feeling this kind of observation would not be well received.