I agree with this. This reminds me of another Einstein quote:

"If you can't explain it to a six year old, you don't understand it yourself."

I find this particularly problematic in certain problem domains. Authentication/authorization springs to mind. Now maybe I have some kind of mental defect but every time I read anything about OAuth or pretty much any similar scheme I come away thinking "WTF?"

The conclusion I come to is that those who come up with such things or those who write about them either:

a) don't understand what they're doing; or

b) they're so far removed from everyone else that they're speaking a different language.

Occasionally you'll see a well-written post about something that makes it brutally simple to understand (I seem to recall a reddit comment about general relativity that falls into this category), which demonstrates the vast difference between those who know something (and can articulate it) and those who don't.

I get similar reactions to a post I wrote on Big O [1], a post I've received many (positive) comments on (and a few pedants who nitpick at a few minor and largely irrelevant technical inaccuracies).

Anyway, back to programming. One habit I find myself doing that I don't see used prevalently (which baffles me) is what I like to call semantic programming. I'll see unit tests written like this:

public void testSaveProject() {
Project project = Project.newInstance()
.setName("Test Project")
.setOwner("foo@example.com")
.setStatus(ProjectStatus.ACTIVE)
.build();
expect(someObject.doStuff()).andReturn(...);
// more expect lines
assetEquals("some value", someService.createPboject(project));
}

whereas I will write:

public void testCreateProject_validProject_returnsNewId() {
Project project = createActiveProject("Test Project #1", "foo@example");
expectSaveToDatabase(project);
assertProjectReturnsId(expectedId, project);
}

where all of these are functions defined elsewhere, typically within the same class. The point of this is to:

a) make the test code shorter;

b) reduce the repetitive code changes required when a change happens (eg the structure of the Project protobuf changes and the way you construct them changes); and

c) to read the why and how of what you're doing rather than the constituent parts (this is the "semantic" part).

Yet I don't see many do this. Am I weird? I don't know.

I learnt to program procedurally (with GW-Basic then Turbo Pascal then C) rather than an OO fashion and I find that in such code functional decomposition is incredibly important (and now an ingrained habit). Perhaps this is a product of that?

I see such things as going a huge way to reducing complexity as you should be able to read why code is doing what it's doing. Reading setUrgentBit(flags) is far more useful than flags |= 0x00f0, even if the function definition is a single short line.

The way I'd describe it is this: there are certain programmers who care abou their audience and there are other who don't. Your audience is your users, team members and other maintainers. This means making tradeoffs and shipping something that makes pragmatic tradeoffs at the cost of "technical purity".

The other kind of programmer can be witnessed by looking at the Twitter Bootstrap JS code, with it's idiotic hipsterish reliance on JS ASI as some kind of mental masturbation or simply showboating to other likeminded hipsters.

I see one of the comments here amends the statement to "unnecessary" complexity and thus the self-interested distortion begins (everyone views their own complexity as necessary).

[1]: http://stackoverflow.com/questions/487258/plain-english-expl...