There is another very strong bias that goes on when hiring, though. Take 9 competent developers who tend to get offers and 1 that can't code their way out of a box. That 1 could very easily do more interviews than the other 9 combined before landing a job (and will be back on the market sooner to boot) and interviewers might conclude them typical and the other 9 atypical even though the reverse is true.

I worked with someone once who had a really sloppy/inconsistent code style, but the code he wrote was rock solid.

His subsequent (and current) job is now as a very well-known expert as as developer advocate for one of the big four tech companies.

You'd be surprised at what you find developers out there doing, the only good metric on a person being a good developer is writing fundamentally sound code. Literally nothing else matters.

In Zen and the Art of Motorcycle Maintenance the author puts forward two types of welders. One is the type that excels at really complex and difficult welds, but isn't very good at making simple welds in repetition. The other might get tunnel vision when trying to figure out an unusual weld, but has the discipline to produce consistent, flawless welds in great quantity.

It might be explained by what is know as Yerkes–Dodson law[1], which describes how performance increases with mental arousal up to a certain point then decreases. If different types of tasks correspond with different arousal for different people, then the type of welder or developer one is is orthogonal to their fundamental skill. Instead it would mean that the first type needs to cast the problem as something novel in order to gin up the necessary level of concentration to get the problem done, hence the rock solid code that has sloppy/inconsistent style.

It makes sense that a good advocate would be highly skilled, but the type who has difficulty with necessary work that seems mundane. In other workplaces this might be the person who seems to have low output, but gets their coworkers past their roadblocks.

[1] https://en.wikipedia.org/wiki/Yerkes–Dodson_law

I hadn't heard of the term "big four" tech companies - does that denote Google, Facebook, Apple, and Microsoft? (just my guesses)

The term Big Four originates in accounting where there actually are a specific set of four large, established companies.

For tech, I usually remember it as AmaGooBookSoft - Amazon, Google, Facebook and Microsoft. Apple is sort of a hardware company so sometimes it is included and sometimes it is not.

I've always heard it as Google, Facebook, Apple and Amazon. Microsoft isn't very sexy to the typical developers that participate in the startup/Silicon Valley "scene" and its accompanying communities (HNews included).

Big four almost always includes google and facebook but the other two slots seem to vary a bit based on who is saying it. I've even seen companies like yahoo and twitter thrown in there.

Indentation! Not much in this world upsets me as much as inconsistent indentation. Ruins my day any time I have to actually read 500 lines of it.

You should automate that issue and have an autoformatter on every commit. Everything else is a waste of time

Honestly, I feel like we should have gone further and decoupled display and serialisation formats of code a long time ago. (Although I understand why we haven't.)

A lot of people without much programming experience seem to really struggle with nesting. We take it for granted, but I suppose it actually involves some reasoning about evaluation order of arguments.

For those people, persuading them to indent can be the difference between them having a chance of learning the knack or just flailing randomly, getting frustrated, and giving up.

(The other lesson is: if you're building a DSL for non-programmers, try to avoid putting in nesting and make everything really flat instead.)

Beautify for Brackets/atom works great. Should be a standard thing in editors really.

Some older books are the worst with indentation. Instead of learning to code you spend most of the time figuring out where the code block ends.

Wouldn't it be nice if all languages made indentation significant?

Or at least included a tool to fix it.

Vim has a nice command to fix indentation from the beginning to end of file: "gg==G (include the dblquotes)

Emacs does the same with C-x h TAB, or you can mark a region manually and reindent its contents with TAB.

As with vim, this depends on being in the right major mode for the language you're working with, which should be automatic for most languages (except Perl, which is screwy, because of course it is), and depends also on that major mode knowing how to cope with the code and being configured the way you want, which should be reasonably trivial for most languages (except Perl, which is screwy, because of course it is).

(Assuming that vim knows how to indent the language you're editing and in the way that you want)

Just don't uncritically apply this to all files without thinking twice and also consult with your team. :-/

Messing up indentation deliberately in few places is a good way to gauge their reaction and would you like to work with them.

Please don't do that sort of thing -- unless you give the candidate a piece of code and specifically ask what could be improved.

But don't expect candidates to spontaneously criticize the interviewer's code. Yeah, I know, you want to work with people who can think critically etc, but at the time of interview you aren't coworkers and aren't on equal footing. Personally, if I as a candidate see you writing code with bad indentation I will conclude either (a) you were making a point about e.g. correctness or efficiency and didn't bother to indent because it's literally throwaway code, so mentioning the indentation would be a distraction; or (b) you and your team don't care about indentation at all.

i just create an editorconfig file <http://editorconfig.org> in root directory of projects, saves having to remember to switch tab settings across them (there might be another plugin with more functionality but it does what i need it to)

This is half a solution at best. It doesn't specify whether to put the curly brace on a new line for instance, and a dozen other formatting options.

yeah, i meant for the tab issues specifically since others arent as easy to miss

hopefully someone will get around to adding more functionality to the plugin so i don't have to edit my visual studio formatting settings for parentheses/comma spacing whenever i switch projects :p

I make constraint based short term implementation decisions

You sometimes resort to short cuts to meet deadlines.

They, are hacks who don't know how to code.

But yeah I never consider myself to be a great developer until interacting with other developers.

The other selection bias here is that bad programmers have to interview a lot more than good ones.