I was part of ThoughtWorks interview process sometime back. In one of the rounds called Pair Programming, a senior developer worked with me on the given problem statement. I arrived at right solution, but he wasn't happy with the solution just because he didn't like the way I solved it. I came back and discussed the same solution with another senior developer and he liked the approach. However ThoughtWorks rejected me in the interview process.
I often wonder how pair programming is good (or even bad) in this context. How they can assume or think that two programmers going to solve the problem in "same" (or even ThoughtWorks "expected") way!
It takes a lot of restraint and stepping back from being in "first-person developer mode" to understand that someone else's unique approach is quite likely valid. I purport to be able to do so but I still find it incredibly difficult to ignore my brain's initial instinct to start pointing out the supposed flaws in someone else's structure, when the simple fact is my own code for the same problem would probably be filled with the same holes - just in a different form.
Honestly, there are only a few metrics that really matter when it comes to quality code:
1. Does the code accomplish the task it's supposed to? I mean really, this is practically the only thing that really matters in most cases. Simply: if deployed, will it work?
2. Are there no glaring security problems with the implementation?
3. Does the code not excessively overuse resources (cpu, memory, network/system calls, etc.)? Real excess beyond what is reasonable, not micro-optimizing.
4. Is the code not a complete mess? No serial use of copy/paste, crazy spaghetti mess, or inability or blatant refusal to follow basic coding standards?
That's it. Deploy that shit, and move on to the next problem. ;)
I always start with reading test cases rather than source code directly. Thats the way it should be (IMHO).
One person we were interviewing solved a problem pretty much exactly opposite to the way that we (and every other candidate) had solved it.
At first glance it simply looked wrong, but after a discussion with the candidate the strengths of the solution became apparent.
Happy to say they got the job, and ultimately turned out to be one of our best hires.
> There is a finite amount you can learn by reading other people's code. You might find specific idioms you admire and adopt, but you will not - and probably should not - try to conform to other developers' methods
From my own experience I disagree with this since reading other people's code has helped me improve a lot. I've noticed that I am so much more creative and intuitive about good software design when I go to write code now and I believe it is credit to reading code everyday
The vast majority are just shit though. That was a hard lesson to learn. You want to give people the benefit of the doubt, but the industry is full of people who have learned nearly nothing in their careers compared to a really good grad who has never worked anywhere but has raw talent and good problem solving skills.
>> They need to understand other styles so they can form their own
After 15 years of working professionally, I kindly have to disagree to a fair extent. It turns out that most - if not all - developers are not very good at writing clean code. Including (especially?) seniors who think they write the best code on their team. The code you're having the juniors dig through to tweak/maintain is probably terrible code that should not be used as a shining example of anything good. They're more likely to pick up someone else's bad habits than learn something useful.
It took me a very, very long time to realize that it's simply a matter of fact that no two developers think alike, and that any set of developers could argue all day as to why each other's code is ugly, unmaintainable, etc. There are extremely few instances where one implementation of any problem is "better" or "worse" than another - we simply think differently. My code will always be "smelly" to you, and your code will always be "smelly" to me.
Junior developers must be permitted to write new code from scratch. Whether it hits production as-is, or goes through weeks of refactoring, it's a must. No developer ever improved by only reading and maintaining other people's code. I have never met a developer who feels at home maintaining someone else's rushed garbage. And 80%+ of the code we write is rushed garbage to attain the 3 week mandatory deadline handed down by management even though we told them it would take 3 months.
There is a finite amount you can learn by reading other people's code. You might find specific idioms you admire and adopt, but you will not - and probably should not - try to conform to other developers' methods.
Not to mention, forcing new recruits to deal with everyone's legacy garbage is a surefire way to turn them off the industry before they've even begun. Let them code a small new feature; then sit down and find out what they did well and what needs improvement; truly tangible issues, not the typical "that's not how it's done" - which really only means "that's not how I would have done it".