patrick dewane gathers wool

Dear Null - Feedback

Wow, almost 5,000 hits and still going strong. I appreciate the feedback, which has surpassed my expectations of none. Page views down this dark alley usually hover around two or three a day, so I'm still not sure whether or not to file a bug report with TypePad (perhaps they forgot to carry the 0).

Anyway, I wanted to take some time to address some comments I've read here.

Missed the point

For those of you who missed the point of the article, let's try this one more time.

A predicate modifies a subject. Check. A predicate asserts some truth about the subject. Check. Without a subject, a predicate has nothing to modify. QED.

Or for you more manly programmers (this is just a joke, keep reading), how about a CFG:

Sentence  => Subject Predicate
Subject    =>  Shirt | NULL
Predicate =>  is blue

Those are your productions. Your non-terminals are bolded and your terminals are not. The language defined by that CFG yields the sentence:

"is blue."

Throw that sentence out in casual conversation.

What I thought was an obvious point went over the heads of most readers. I have to assume I did a terrible job explaining myself. So here is an equation to help:

NULL + Boolean = ambiguity

Now I cannot speak for you, but I have a hard time finding a place for ambiguity at my dinner table of logic. If we modify a null subject with a predicate, we assert some truth that carries ambiguity because the assertion carries an implication regarding the subject. In our blue shirt example we yield false when the shirt is not blue and when we do not have a shirt to modify. This is ambiguity.

Really missed the point

Quite a few comments were made regarding my desire to banish NULL from the universe. I'm not sure what post you were reading, but it surely was not mine.

I stumbled upon this noteworthy comment:

"'NULL makes things messy get rid of null'".

That comment was made as a summary of my post, and what a terrible summary it was! Shame on you.

Funny on accident

Here is my favorite comment by far:

"What happened to programmers being real men? I'm talking about doing things like allocating and freeing memory, doing pointer arithmetic and using multiply linked lists, all before a hearty breakfast of steak, vodka and cigars.

Now, coddled by managed code, generics and closures, we see febrile man-children wetting their pants about something as simple as nulls. Man up for fuck's sake."

Now that is funny! Let's pick this one apart:

1. "What happened to programmers being real men?". What happened to insightful input. As a general rule of thumb, if the first sentence of a comment is an ad-hominem attack then the commenter is more than likely a real man, perhaps even one that wears Old Spice and eats deep fried bacon.
2. "I'm talking about doing things like allocating and freeing memory, doing pointer arithmetic and using multiply linked lists...". Now I know this is a real man! One that throws abstraction and grammar to the wind!
3. "Now, coddled by managed code, generics and closures...". Wow, just wow.
4. "...wetting their pants about something as simple as nulls. Man up for fuck's sake.". Sexism aside, would you mind helping me change my pants?

Monads

I came across several comments suggesting that the venerable Maybe Monad (nullable value type) would solve this particular problem. While it does solve this particular problem, let’s not lose sight of the actual problem.

A nullable Boolean would certainly remove any ambiguity, essentially giving us the third Boolean value “I don’t know”. So now we are asserting the fact that we do not have a subject to modify, which is the actual problem. It may sound like we’re getting closer, but we’re not.

What are our choices for dealing with this new Boolean value? Well I suppose it depends on the context of the program. Perhaps it is OK and we can continue on our merry way. Imagine a customer wanting to purchase blue shirts. The customer applies some type of filter, and this filter removes non-blue shirts.  A non-existent shirt is not blue, so the filter gladly ignores it. We then return all blue shirts and our customer is happy.

But now imagine our customer wants to purchase every non-blue shirt and we use the same filter. Every time our filter returns false, we sell that shirt to our customer. Uh oh. We will attempt to sell a NULL shirt to our customer, which would more than likely result in an exception somewhere down the line.

Remember, our problem is not that the Boolean type is insufficient. So why amplify it? (I’m not making a case against nullable types, I’m just making an observation).

Ignoring the problem

I was surprised to see how many “solutions” were presented which did not directly address the problem. Rather, many solutions targeted the Boolean type as not being meaningful enough.

Perhaps my sense of humor is senseless, but I find all this rather amusing. Look around at all the abstraction and complication we create to deal with such a basic issue. I’m not saying this abstraction and complication is not necessary. I just find humor in our ability to complicate.

Actual insightful commenters

Imagine how happy I was to find how many other programmers saw the problem, laughed a bit, and got involved in meaningful discussions. Thank you to those people, you’ve most definitely taught me a few things.

Would a non-issue has sparked such a debate? I would like to think not, but I am biased.

Wrapping up

I wrote "Dear NULL" in literally an hour. I stumbled upon a block of code that looked very similar to the one posted in that article, and it just made me stop and think for a moment. After thinking about it, it made me laugh a bit.

There are countless ways to deal with NULL, and each language offers new and enlightening abstractions to push the problem further away from its realization.

Monads are an option, namely the Maybe monad. Contracts could work. A change of perspective and/or changing the name of function could help. Building a JK flip-flop with some spare gates and doing some other manly shit would probably just make me wet my pants.

I merely found a block of code that made me giggle.

Observations of a Developer - What's In a Title?

I promise this is technology related, just trust me...

When I was little people would often ask me, "What do you want to be when you grow up?". Depending on my age at the time I would respond with either Lawyer or Doctor. I wanted to be a Lawyer because making interpretations of law meant you had power, and it sounded cool! I wanted to be a Doctor for very different reasons; I wanted to help people, challenge myself, make a difference and be involved in something important. More importantly, being a Doctor always sounded like fun to me, something I would have really enjoyed. This is probably because I love a good challenge and I love to learn something new. Those criteria are vital to being a successful Lawyer as well, but those surely weren't my reasons. 

Earning the title Lawyer or Doctor does not mean you've reached some sort of plateau nor does doing so deserve gloat or pompousness. You have a responsibility that you've earned, and while you have every right to be proud, your title should not be a definition of your abilities. Although the purpose of a title is to define ones abilities, you can't deny the abuse of this practice. Unearned titles lead to a false sense of ability and often to gloat and pompousness. I've often seen pompousness stifle ones ability to learn from their peers, which is the death of learning.

Observations of a Junior Developer

I'm sure others have noticed the growing trend in ridiculous un-earned titles in the tech industry. This may be a problem in other industries, but I cannot speak to those. When I was fresh and green out of university it didn't take me long to appreciate the irrelevance of titles amongst developers that I met. I met Analysts, Specialists, Senior Something-Or-Others and Engineers. Aside from being taken aback at first, I couldn't help but to be curious as to how you earn such prestigious titles and shiny business cards. To further complicate matters, I worked with consultants whose titles propose some sort of Herculean knowledge of all things binary. Not to be deterred, I took on the role of Junior Sponge and prepared to learn everything these people had to teach me.

The only problem was, I didn't know who to listen to. Surely the Senior Something-Or-Other has more to offer me than the Junior Code-Monkey, or so you would think. While working with the Junior developers, I became eager because these people were really smart - and they were only Junior developers! Once the eagerness set aside, the intimidation set in; if the Junior developers are this smart, the Senior developers must bleed genius. The intimidation didn't last long though since I soon met Senior developers and Architects who had no more (and sometimes even less) to offer me than their Junior counterparts. Perhaps their Senior title offered other benefits, such as software discounts before 10am. Maybe one day I will find out if that is true.

There was hope though. The Senior developers and Architects I met were actually consultants. So surely these titles have boundaries in organizations and you shouldn't compare and contrast titles across these boundaries. So what's in a title then? I still did not know. Note: I'm not singling out consultants, this was just an observation.

Okay then, what about within my organization. There has to be some sort of logical reasoning behind these ranks. Although, I came to the same conclusion: the more prestigious title did not necessarily come with a bounty of experience and knowledge. At this time I'm more hunter green than lime green in terms of experience, and thought for certain my observations were limited and shallow. I needed more time to observe.

Then I started meeting people outside of my organization who shared my passion for developing software. I met other Developers (my title at that time) and also people my age who, with a high and pointy chin, announced their Analyst and Senior Developer titles with fervor. Again, the sense of intimidation sank in. Thankfully it didn't take long to notice the passion was in the their title and not their work. Maybe there was a trend here after all.

I like the notion of titles, just not their lack of a substantiated definition in our industry. Perhaps there are organizations following military-like guidelines concerning ranks and titles. I do not know, I have not seen these organizations.

Observations of a Junior Developer

But my real problem here is the fact that titles even matter amongst developers. For those of you familiar with American Psycho, does the business card scene come to mind?

What begets this abuse of titles anyways? I'm not entirely sure, but I have a notion. Take for instance, the world of consulting (Note: I'm not singling out consulting, the following examples are just observations). You submit an RFP to a few local consulting companies to deliver a new order fulfillment system. Both companies seem qualified, but company A promises Senior Level Developers to complete your project on time and on budget. Lured in by the notion of a successful IT project, you take the bait only to find these Senior Level Developers have no more experience or know-how than your Junior Level Code-Monkeys. You ask yourself, "Are my developers just that much better or did I just get sold?" I'll let you answer that question, but here is a formula to help you decide:

you = just_got_sold

Other than just confusing me, are titles all that bad in our industry? Let's assume the answer is "yes" and limit their use to designating pay grades. If you think otherwise, take for instance the word of E.W. Dijkstra:

"...A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyze what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."

Although in a different context than this post, its still relevant and enlightening. What other job titles are contradictory or eyewash? Surely there are others.

If you're still with me, even barely, this is opinion and I encourage you to disagree. Although my opinion is based on observation, perhaps my observations are too shallow and maybe I'm just too green. In the event I am too green, I will be thankful if the following observation ends the same way. Note: if your title has Senior in it, the following is just an observation.

There may exist a relationship between pompousness and title buy-in, I'm not sure. But a relationship does seem to exist between ones willingness to learn from others and their rank amongst their peers, perhaps due to pompousness, but again I'm not sure. This attitude can stifle even the most Senior developers' ability to learn, and is most certainly devastating to the well being of their peers. Unless of course the Seniors do get software discounts before 10am, that may help their peers.

Of course there is a bit of satire in this article, and there most certainly is truth as well. I can only hope my observations are limited and shallow. If not, try not to let your title affect your ability to be an asset to your peers. After all, once you're no longer a part of the solution, you're part of the problem.