3 ms·
The counterpoint to this is that if you are they type of boss who would nit pick a candidate over something like this, he probably wouldn't want to work for you
by angrycoder 16y ago
The counterpoint to this is that if you are they type of boss who would nit pick a candidate over something like this, he probably wouldn't want to work for you anyway. Especially when you take a quirky/cute spelling and try to expand it into inferring all sorts of other traits.
It reminds me of people who say they would never hire a developer who doesn't write comments. Really? Writing comments is a precious skill that takes years to develop? You just tell someone, if you work here, you need to write comments. Problem solved in one sentence. Same with variable names. Its a standards issue, nothing more, nothing less.
- btilly 16y agoDo you really think that ordering someone to write comments and use good variable names is sufficient to get good results? The relevant chapters in Code Complete may help you understand how much more complicated the subject is than that. (It may also fix your apparent belief that comments are necessarily a good thing.)
- tptacek 16y agoIf you want to narrow your shop down to the programmers who can quote chapter and verse from _Code Complete_ and who are inclined to care a lot about how people choose to abbreviate or mangle their variable names, that's totally fine. The rest of us can chop up the pool of developers who actually get stuff done. This isn't just snark; the Venn diagram we're dancing around here favors businesses that hire in my (implied) style.
- btilly 16y agoI wasn't making a recommendation about who to hire. I was telling someone where they had room to learn more about an important topic. In any case I don't care whether people can quote from Code Complete. What I care about is that they have good enough instincts that they can wind up writing reasonable code that I'd like to maintain. If you don't understand why people would want function names that describe what a function actually does, I don't want to maintain your code. Nor, in the long run, are you likely to be productive. But it is a bar to meet, not a standard to judge by. Once you've met that bar, I don't care about the difference between OK, and best in the world. I'm on to caring about other things. Like productivity. Code quality and productivity isn't either/or. It is an and. (I've had to clean up enough after the super-productive producer of crap, and don't want to do it again.)
- nickelplate 16y agoExcept this is not a standards issue. It is a problem that can be solved in one sentence only if the programmer groks code construction to begin with. A lot of otherwise smart programmers - some of them very experienced - do not understand this stuff and do not develop good programming habits of the Code Complete kind. I probably exaggerated a little in my previous comment. Still, I always test for code construction "instincts" when I am interviewing a candidate. I may give the candidate a take home assignment - nothing difficult, as I really only want to see what the code looks like. Or I may ask the candidate to bring a sample of great code, and ask him why he thinks it is great. But I will always test for good habits, as they are too often taken for granted.