Clif Notes — New Blood Part 3
If it looks like a duck, walks like a duck, and quacks like a duck, it must be a duck. Right? If it looks like a dinosaur, waddles like a dinosaur, and grunts like a dinosaur, it must be a dinosaur. Stands to reason? If it looks like an obsolete programming language, is coded using obsolete tools, and is tested using archaic methods, MultiValue must be obsolete. Make sense?
I am always surprised, when I talk about the topic of uppercase-only coding, how angry and defensive people get. I really don't understand it. It would seem to me that if something as simple as changing the appearance of our coding style would help make us more acceptable to the Millennial developer cohort we're seeking to entice into our MultiValue ranks, that would be a no-brainer. But the resistance I get when I venture into this topic is, to me, astounding. It's all the way from, "Really? You think uppercase versus mixed case is important?" to, "THAT'S BULL!!" and they effectively stick their fingers in their ears.
Well, fine. I really don't care one way or the other what you think about uppercase-only code. Frankly, you don't have to give a whit about what I think about uppercase code.
Remember, the premise of this series is that MultiValue either is — or is in danger of — declining. In order to prevent this and grow the MultiValue space, we need new developers to both replace those who are leaving, and to provide an expanding pool of talent that will make MultiValue a viable business option for years to come. That means attracting developers from the Millennial generation.
Do Millennial developers care about which case code is written in? You bet they do. Don't take my word for it. Ask some of them. I did. In an International Spectrum magazine interview in 2011, I had an opportunity to ask a bright, young, promising developer who had just accepted a position with a MultiValue shop about his initial impressions < http://intl-spectrum.com/mag/MAYJUN.2011/default.aspx >. In his words:
Me: As a younger professional with a computer degree which is fairly recent (within the last five years), what was your reaction when you first walked in and saw everybody sitting here using green screens?
Him: Well, to be honest, at first, before I started learning anything about the language, I probably thought for a split second, what did I get myself into? It wasn't so much the green screens that worried me, but the everything being in ALL CAPS — which I found out since then, is not an actual requirement. That's more of a holdover from when it used to be a requirement. I know a lot of developers my age and probably younger now are more accustomed to using camelCase in our development. And IDE's are handy.
Did you get that?
"What did I get myself into?"
"Hold-over" (From the Old Days)
"My age and younger." (The developers we are supposedly interested in attracting.)
"camelCase" (C++, Java, C#, etc.)
"IDE" (Like Visual Studio, Eclipse, and others)
Here's an exercise for you. Go to the bookstore this weekend and browse the computer section. See how many of the books give their programming examples in all upper case.
Remember, first appearances are important. We are trying to sell these folks on coming into our environment. As many salespeople will tell you, you are selling feelings about your product and how it would feel using your product just as much (some might claim more) as the product's actual capabilities. You sell the sizzle, not the steak.
Want to put the nail in this coffin? Take them on a tour of the development area and let them see developers not just coding in uppercase, but doing so using the ED line editor. (I'm not making that up; I know several of them.)
If I can get this through to people, you would think that would pretty much be the end of the discussion, wouldn't you? But no. Now the arguments about the nature of reality start.
"Well, (Huff) It Shouldn't Matter!"
Excuse me? Shouldn't matter? I thought we just established that it did matter? To come back with the argument, "Well, it shouldn't," isn't valid. It has nothing to do with reality. It's just an opinion about the way the world ought to work, even though it doesn't.
I'm not going to argue with you on that. Who can? That's as valid as someone who, when told, "smoking cigarettes increases the chance of developing lung cancer" immediately replies with the brilliant counter-argument, "Uh, uh. I don't believe that!" and lights up. You simply cannot have a rational discussion with an irrational person. Don't try. Just move on.
The Users Don't Care; They Don't Look At Our Code. They Just Want It To Work.
True. But that's not the group we're discussing. We are talking about the people who will be looking at our code and are in that Millennial group we are trying to attract. Besides, you're right. They don't care. And they won't care - they won't care if it is written in mixed case, in MultiValue Basic, in SQL Server, Oracle, .NET, Java, Python, whatever.
The C-levels, VPs, Upper Managers, Etc. Don't Look At Our Code.
You are, in most cases, correct again. So where are these decision makers and check writers getting the idea that MultiValue is obsolete?
From their subordinates. Who also don't look at your code. So why are they saying we're obsolete? Where are they getting their information?
From their subordinates. And they get it from…
Follow the chain and you will eventually find a group of IT Millennials somewhere who have seen your code, your dictionary listings, etc. They see all uppercase and pronounce, "This is obsolete," and proclaim that up the chain to their supervisors and so forth. I've seen this several times. Somewhere, there is a group, maybe on the data warehouse project, maybe in the online commerce and web store team, who starts spreading the word that, "that old MultiValue is obsolete." And even if you don't have that in your organization, your CIO will hear it from their CIO colleagues at other companies.
Why Should I Have To Change The Way I Code? / I Can Code Faster In Uppercase Only. / I Don't See Any Reason…
Interesting what all of the objections in this category have in common. Think about that. In the meantime, let me share an experience I had with you, and see if you can see how I also got myself caught in this trap.
When I first started learning Python, I quickly grew very fond of the language. But I hated the style of coding they used. All lowercase with words separated by, for Pete's sake, underscore. Like this:
lines_left = lines_per_page - lines_printed
One of the things I like about camelCase is that I don't have to use another character to separate words, like a period that has a certain meaning to many having worked with various object-oriented languages. Underscore? Awkward. A shift AND a reach for the top row with the ring finger. That will slow me down.
Did you see what I just did there? I fell smack into the trap I tease other developers about when they say, "The shift key slows me down." (Tell that to typists who burn past you and me both going 75 WPM.)
Then, and I'm not making this up, I decided "I don't have to change the way I code just because a group of fanatics insists that their style manual, called PEP 8, says that's the Right Way to do it. And who crowned Guido the King, anyway?"
And I started using my beloved camelCase naming conventions and the Python compiler was still my friend. End of discussion. Until the next day…
I was looking at what I had written before and thought, "May not look like Python, but it works." Why should I care if it isn't "Pythonic?" So it doesn't make me one of the "Pythonistas." What difference does that make?
Oh. My. I suddenly realized that I was doing exactly what I'm saying we shouldn't do. Major blush !
I decided I needed to back down and re-think this. I'm a professional. I want to be viewed as such. If I want to be taken seriously by the existing professional Python crowd, I need to conform to those standards. I don't want "Pythonistas" looking at my code and laughing. It's a profession pride thing. (And as a consultant, it's a $ thing, too.) So I re-wrote that program and have been coding PEP 8 style ever since. It didn't take long for that ring finger to find the _ key as quickly as my little fingers find the shift key.
So I do understand these objections to changing the way most of us were taught to (and had to) code MultiValue. But it doesn't matter. If we keep doing what we've been doing, we'll keep getting what we've got — declining numbers, no respect from "mainstream" professionals, and no New Blood.
It's time for us to change and move along. It's a matter of survival, folks.
Of course, it doesn't do a bit of good for us to change and use a modern-looking coding style if there are people in the shop telling others in the department, "MultiValue doesn't do XML." "MultiValue can only exchange data by dropping CSV files in a directory." And other "Can't Do" claims.
We'll take that up in Part 4.
