>> It took me a very, very long time to realize that it's simply a matter of fact that no two developers think alike, . .
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!
>> How they can assume or think that two programmers going to solve the problem in "same" ... 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. ;)
This is exactly what I was thinking! The points that were written is just as what I had in mind. But I guess still your missing one important point on testing. The code should work if deployed, but at the same time, we need to have through testing for the same.
I always start with reading test cases rather than source code directly. Thats the way it should be (IMHO).
After experience with several junior developers I plan to do the following to train the next one. First, let them solve an isolated problem in our code base. At pull request step comment excessively (this is what inevitably happens with all junior developers, the PR is so huge that GitHub chokes on it). Finally, pair them with a senior developer to solve the issues raised in the PR, rather than letting them fix them alone and engage in an endless loop of commits and comments.
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!