Always Assume That You're the Problem

Well Justin,

-- just stop reading right away if you don't like to read a lengthy rant. plong me and feed me a fish --

if I've read your posting right and understood the message then you say, it's allways me that is wrong and that I'd better listen carefully to the (so called) experts or the sheer mass of developers and do what they do? Right?

On the one hand this is some sort of cool because it spares me a lot of thinking and opinion-of-my-own-building...I could get my brain out, it hurts. nurse! nurse! (monty python brain surgeon sketch, where is my damn handkerchief and the gumboots)

But on the other hand I have some trouble following your arguments. Let me ask some pathetic questions: How far would humankind have come with that sort of reasoning. Would Einstein ever have found the relativity theorie if he'd followed the physicists main stream believing the established experts?

First of all I'm one of those guys you have most probably trouble with, because I have matured from a follow-every-hype addict to a developer who evaluates hypes carefully, even if the mass has just adopted it following the so called experts like a flok of sheep. It's like I want to do the hard work of evaluating things on my own and I like the option to say "Yes that's great", ""No, that is wrong, I don't like it" or even "I was wrong lately but I'm able to change my mind". Ah, just wait, usually I use sentences that are less generalizing, e.g. "It's wrong to use this-and-that in situation XYZ but valid in situation ABC". I guess that makes the headline "Always Assume That You're the Problem" to a invalid generalization in my eyes (be sure that I know that you've deliberatley used this as provocation/stylistic device).

But let's go on: For instance I like some ORMs (not all of them, but this is another point I will discuss later) but I won't use one if it comes to mass data processing (situation-dependency), I mean really big data sets not the little web shop of the butcher at the corner (where the flok of sheep gets sold). Even in one project there might be good reason to say no to ORM for one use case and embrace it on another. Therefore to say "ORM is always good", thumbs down for that.

Finally I want to discuss lambdas. Yes I like the concept, I've used them back at university programming scheme (a lisp dialect, lambdas are integral part of lisp). But I think your actually adressing closures and the lengthy, resultless discussion in the java community, don't you? To be honest, I'm glad that they didn't made it to JDK 7, because regardless that I like lambda in schema, I would have problems with any of the proposed closure "solutions". It's a similar problem like with parametrized types: They haven't been in Java from the begining, we got them with backward compatibility and guess what - we bought them with type erasure. What would be the price for closures? Even more unreadable code, strange javadoc, confused project teams? And there's really no need for them because there are language constructs that have proved to work well...So we have to carefully seperate the "idea behind" and the "real world implementation" of items in our discussions.

Finally, to answer your question: "Let me just lay out a list of items, and you tell me how they are all related?"

My answer: All items must not be missing in a) any job interview b) any names dropping session.

By the way I would add DCI and MDD but I don't give you a single clue for why I would so, apart from some experts say it's cool ;-) 

Sorry for ranting, but I can't stand certain ways of argumentation.

the problem with that 'conscious incompetence' is that (like Justin seems to do) you assume that everything new is automatically an improvement because someone else thought of it (and, being consciously incompetent, you assume that everyone who dares propose something you don't understand must be competent and know what's best, never thinking that they too may be incompetent). Closures (for example) are a prime example that that's not the case. They have their place for sure, but the language has to be designed from the outset to include them rather than having them retrofitted like people are trying to do with Java.
ORM is another example of something that has a place but shouldn't be used blindly (as is pretty much everything else).

I can tell how referenced Charlie the Unicorn is related to the post and its 'follow the crowd' suggestion, but not necessarily to the other points:) Was it intentional?

there's a difference between looking at things to see if they're worthwhile and blindly following every hype (which is what I was talking about, and what's happening all too often in this industry).
I was also referring to the spade of "me2 features" as I call them that are pumped into the Java platform (and no doubt others as well) for no real reason other than that some other language has them so they must be good (closures are a prime example of that, so are the inclusion of an embedded database and SOAP stack in JSE 6).
There's nothing wrong with closures per se, nor with embedded databases or SOAP stacks, I've used all of them, but their place is not inside the Java language and core platform. Yet the crowd that follows every hype because they're consciously incompetent and think that everyone who proposes something must be right cause such things to make it into the core platform, devalueing it and making it eventually a bloated and useless monstrosity.

Natural language is an example of unconscious competence. Not every native speaker who can understand and be understood in a language is competent to teach it. Distinguishing between unconscious competence for performance-only, versus unconscious competence with the ability to teach, the term "kinesthetic competence" is sometimes used for the ability to perform but not to teach, while "theoretic competence" refers to the ability to do both.

 

scalpmed