Playing By Color

When I was younger we would take our vacations in Arkansas visiting my mom’s family down there.  My grandmother who was quite a good singer and who had quite an intuitive gift for music, had an organ in her living room.  I can still remember sitting there and playing with it.  I couldn’t (still can’t) play music but as with most kids that didn’t stop me from sitting there and making noise.  God bless my grandma–she had to have had the patience of a saint or three to put up with my noodling on her organ.

At one point though I recall finding a colored piece of cardboard in the compartment of the piano bench.  It was something that could be used with a special music book to allow someone who couldn’t read music to pick out a tune by following the colors.  The idea was that you set the colored piece of cardboard on the keyboard at a certain position and then by following the colors in a special songbook one could pick out a tune.  This seems to be an idea that comes up time and again (as evidenced by this) in teaching music to children.

I was so proud of being able to pick out “When The Saints Go Marching In” and have it sound somewhat like the tune should have sounded.

I would never in a million years consider that I learned very much musically.  In fact it’s probably much more akin to some sort of Skinnerian behavior conditioning (“Ooh–I follow the colors and I get pretty music!”) than real music.  But I could pick out a tune.

So this is part of my concern with the whole “everyone should learn to code” school of thought.  While I think it’s a fine idea I’m afraid there are a number of people coming out of these code camps with the software development analog of knowing how to play the organ by following the colors.  That is they can pick out a pleasant tune but without the cardboard they’re lost.

Don’t get me wrong–everyone who writes software has to start with baby steps.  My concern is that we’re not doing enough to encourage new software developers to move beyond the cardboard color guide of software development and truly understand the dynamics of software development.  I’ve seen it more than once or twice–new developers who are utterly lost without intellisense. We need to help people move beyond the rote regurgitation of what they’ve been told to a deeper, richer understanding of the mechanics of what’s going on.  If we’re just teaching people to repeat a series of rote steps then while we’re giving them skills for a career change we’re certainly limiting their future prospects in their new career.  We owe them better than that.

RIP grandma Ruby and thank you for the clarity to sometimes see through the superficial.

Software Development And The False Dilemma

So I started my morning, as I often do, by looking at Twitter. It’s better than a demitasse of espresso in terms of raising my blood pressure.

One thing I see over and over again on Twitter is the rather common false dilemma logical fallacy. And this fallacy seems to be in play a lot in software development.

We Can’t Test All Of It!

This is one of those old saws I’ve heard from multiple developers over multiple years. It goes something like “Well we don’t have time to test thoroughly . . . ” the unstated implication being that if we can’t test “thoroughly” (for whatever definition of thorough that person has in mind) then there’s not much point in testing at all.

This is, of course, a false dilemma. There’s quite a bit of value in testing even 10% of a system because that’s 10% more chance you have of finding bugs before your code gets in to the hands of your customers.

Now testing costs money. It takes time. But that has to be weighed against the loss of time for customers and the loss of trust. I think the loss of trust is an even larger (if much more difficult) cost than the loss of time. Once a customer stops trusting that your software is mostly right, it’s very hard to regain their trust after the fact. The hasty generalization occurs–one crash makes the entire application suspect from there on out.

I Tested And Bugs Still Got By!

This is yet another form of the false dilemma. Developers will, sometimes very grudgingly, write unit tests against their code. Then after several iterations they may find a bug. “Well I guess all those unit tests were useless! They didn’t catch this one bug!” And there’s a great excuse not to do the work of writing unit tests any longer, right?

Of course this is a false dilemma. Unit tests certainly won’t eliminate the possibility of any bugs. For one thing, the code doesn’t stay static after we write our unit tests. For another, it’s human nature to miss details that need to be checked. Neither of these factors mitigate the value of having a good suite of unit tests. If you find bugs after the fact well add another unit test to catch that bug in the future and congratulate yourself on being a tiny bit wiser about potential bugs in your code!

The Comments Lie To You!

Another common false dilemma is the notion that once comments get out of date there’s no point in updating them. “Well,” the reasoning goes, “this one comment is obviously incorrect so I won’t bother to read any of them. And there’s no point in correcting the comment either!”

I guess as I put more miles under my tires, I get more and more to appreciate the developer who rather than leaving garbage does his or her part to spruce up the code. Maybe you can’t fix the entire code base but that doesn’t mean there’s no value to be gained from fixing the part of the code base you’re currently working on.

We Can’t Verify All Of It!

One area I’ve been focusing on lately is the idea of formal verification of software. I’ve been playing with Coq and I have found an excellent tutorial on how to use it to formally proven assertions about code. But this seems to be one of those false dilemmas that developers feed themselves.

“Hey Onorio, you can’t formally verify the correctness of all of your code so why bother with any of it?” And that’s true. For all but the most trivial applications a full formal verification is pretty expensive and time consuming. But that doesn’t mean that there is no case where some formal verification cannot help build stronger software.

Pretend you’re dropped in the middle of landscape you’ve never seen before. You’re offered a map but the map, intentionally, has a lot of details omitted. Would you rather have the incomplete map or nothing? I don’t know about you but I’d consider an incomplete map is still better than absolutely no clue about the landscape.

Of course we can’t formally verify entire large software applications–especially applications that interact with human beings. But that doesn’t mean that we cannot verify parts of the application and have some assurance that some parts of our code are formally, provably correct.

I guess if I wanted you to take anything from this little thought ramble it’s that “I can’t fix everything” is almost never a justification for not trying to fix anything. The single cleanup here and there will eventually add up to a code base that if not perfect is at least a lot more liveable.

Focus And Productivity

So I can recall something that Jeff Atwood said a few years ago about “The Magpie Developer” and it stuck with me. And I’ve heard Robert Martin (aka “Uncle Bob”) discuss “The Churn” which seems to be his feeling of magpie developers constantly seeking shiny new toys. Recently I also spotted this excellent write up on the idea of “Diseases of the Will” on BrainPickings. Seems like the type of person he describes as the “bibliophile” or “polyglot” could describe a lot of software developers.

But I don’t think it’s quite as simple or clear-cut as many of us would like it to be. Saying “Well I know <TechnologyX> and therefore I’m going to stick with it because it’s just a tool and any tool can do any job” is not only foolish, it’s counter productive. It’s somewhat analogous to saying “Well I’ve learned to use a wrench and so, therefore, I’m going to use this wrench for every mechanical job I need to do everywhere!” You can drive a nail with a wrench but a hammer makes it a lot easier. So it seems that we need to at least be aware of new ideas in software development even if we decide our best bet is to stick with the technologies we already know.

So how do we balance the need to learn new things against the constraints of our limited time? That’s what I want to address here. I don’t know that I have any answers but I certainly have some suggestions.

Learning How To Learn

One thing that has been impressed upon me again and again is that many of us, i. e. software developers, don’t know the best ways to learn a new subject. For one thing, for a lot of us a lot of technical topics came somewhat easily up to a point. For myself I thought I was pretty good at math until I hit integral calculus. I really struggled with integral calculus. Partly I wasn’t terribly motivated to learn it at the time and partly I really didn’t have any study habits to speak of because I’d never really needed them. As I am sure people reading this essay will understand it’s probably one of the worst feelings I’ve ever felt to be unable to understand math immediately. If I had developed some sort of study habits I wouldn’t have been so badly thrown. If I had a bit less pride and admitted to myself that I could stand with some tutoring, I wouldn’t have been so badly thrown.

My point is that lifelong learning is an essential part of being a software developer so it’s worth your time to invest a bit in discovering good study habits if you don’t already possess them.

Making Time For Learning

Another essential ingredient of acquiring new skills is setting aside time to do it. I am fortunate enough to work for a company that sets a great deal of importance in training its employees. They expect all of us to set aside 5 hours a month solely for learning. Not every company is that enlightened.

Of course the time for learning has to be balanced with time for other things. More importantly, time for learning can become an excuse for avoiding things we don’t want to do so it does make sense to set a time limit on your learning and try your best to stick to that time budget.

What Should I Learn

This is, to me, one of the essential questions that a technologist must ask herself or himself. Given we only have limited time to acquire new skills and given that we don’t want to waste that most precious commodity, time, what should we focus ourselves on?

One answer I’ve heard trotted out repeatedly is to chase the next big trend. Right now the next big trend seems to be machine learning and artificial intelligence. I’m tempted to put those two terms in quotes because I think they are among some of the worst names for an idea since someone decided to call our genetic material colored bodies (chromosomes). But I digress.

My answer to the question “what should I learn?” is–learn whatever interests you. There will always be some shiny new technology to chase so don’t spend your life trying to learn the latest fad. In that I do believe that I do agree with Uncle Bob.

But even if I say learn whatever interests you, I can improve that recommendation a bit more. Learn something that interests you that is fundamentally stretching your mind. Are you the best C# developer at your company? Learn F#. Functional programming is a pretty dramatic paradigm shift from OO. They are not orthogonal to each other (as everyone seems to think they are) but rather they complement each other in nice ways. Of course if you’re really very interested in learning another OO language, that’s fine too. But I think it’s safe to say that one grows himself or herself more through fundamentally different approaches than through learning new variations on the same theme.