Justin Etheredge is a Senior Consultant for Dominion Digital in Richmond, Virginia - United States. He likes to blog quite a bit at http://www.codethinked.com with hopes that someone out there might read it. When he isn't writing software or working on his computer... wait, he is always doing that. Anyways, Justin likes programming, a lot. Justin has posted 24 posts at DZone. View Full User Profile

Always Assume That You're the Problem

  • submit to reddit

If you are as much of a fan of the book “The Pragmatic Programmer” as I am, then you might remember the phase:

“Select” Isn’t Broken

You can find this nugget, along with others, on pragmatic press’ site. In the book though they go in further detail to lay out a story where a programmer was convinced that he had found a bug in the “select” Solaris API call. Obviously after wasted time, hilariousness, and much chicanery, the programmer was forced to analyze the problem and discovered that, alas, it was in his own code.

If this sounds familiar to you, then shame on you, but you may be sitting there saying “Pssssshhhhhaaaaaa, I always assume that my code is the problem. And then I fix that junk and release some killer builds.” And if you are saying that, then why are you speaking like that? But seriously, I applaud you for being so humble. It is good to look at your own work with a cautious eye, and sometimes it can keep you from getting seriously embarrassed.

Read the rest of this post at CodeThinked.com

Published at DZone with permission of its author, Justin Etheredge. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Soylent Green replied on Sat, 2009/03/28 - 1:06pm

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.

Roland Carlsson replied on Sat, 2009/03/28 - 4:26pm

When I read this post I start to think about one of the seminars at Sweden Developer Conference 2009 earlier last week where a guy talked about The four stages of competence. The first step is "Unconscious incompetence" and that is what I belive that you are seeing among most of the people that has not looked into all the new things out there.

To be able to be open to new knowleadge they have to get into step 2, "Conscious incompetence" where you are aware that you have something to learn. If you are at step 1 you simple think that you are good the way you are. 


Jeroen Wenting replied on Sun, 2009/03/29 - 12:43am

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).

Zviki Cohen replied on Sun, 2009/03/29 - 4:21am

...a billion developers out there singing the glories of GIT...

One point to remember is not to confuse noisy with popular. Very loud small group may seem much larger. Also, keep in mind that there's a huge corporate market which is much slower in adopting new technologies.  

Michal Rembiszewski replied on Sun, 2009/03/29 - 6:23am

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?

Roland Carlsson replied on Sun, 2009/03/29 - 12:49pm in response to: Jeroen Wenting

Jeroen, I acctually wrote about the problem of what paths that actually leads to success but i didn't really get the thoughts out to understandable text so I removed it before submit.

But I somewhat agree to what the original writer says. If there are a large fuzz about a new thing perhaps one should take the time to evaluate it. I might not be something useful but you might learn something when trying it. A knowleadge that might be useful in another context.

 Sometimes you will find a gem you can't live without.



Jeroen Wenting replied on Sun, 2009/03/29 - 12:55pm

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.

Martijn Verburg replied on Mon, 2009/03/30 - 3:28am

Ah good old Charlie, _love_ that video I always wondered what hte creators were on when they made that clip :)

Sarah Smith replied on Mon, 2009/04/20 - 2:11pm

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.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.