You Can Be a Lumberjack (and that's okay)

I'm interested in programming, not so much languages and platforms. Of course programming paradigms, libraries, and computer science theory is part of programming. Programming has a million very interesting parts!

But these things come and go, and folks commonly will argue for weeks at a time about things like semicolons. Or tabs vs spaces. We programmers, because we're so good at focusing in on small details and getting systems of logic into a consistent state tend to miss the forest for the trees.

If programming could be compared to being a lumberjack, we can certainly talk about cutting down trees! But we can, and should, also talk about forests and ecosystems.

So many years ago I decided the daily grind that was coding was not as interesting as making stuff people want, even if it's just you making something only you want. After all, isn't that the really cool part about tech? Wanting the computer to do something and then you make it happen, all for you.

A Symbol of Your Affection

So why was programming sometimes one of the best things in the world you can possibly do and other times this endless grind of despair and pointless thrashing? Does everything tech related, including video games it seems, have to become a grind?

Just like with every other coding-related topic, if you ask programmer you are likely to get perhaps thousands of different answers. Some folks swear by their IDE. Some folks love Object-Oriented Programming or Functional Programming, and so on.

For while, this seemed as intractable to me (and frankly pointless) as the tabs versus spaces discussions. You could make plausible arguments about things, you could kick around ideas, but at the end of the day it was just a matter of opinion.

I thought about that yet again when The Bobster was on Twitter last week talking about FP vs OOP vs Procedural Code. These are all good things, he basically said. Don't confuse the tools with the job. Learn and use discipline.

I get that. I felt the same way myself for a long, long time. At the end of the day, it's really all the same: programming. But I grew professionally beyond that opinion. It makes me sad to see people still stuck there.

Is there no place where we can talk about programming without getting bogged down in the details, either arguing about seeming minutia or throwing up our hands in defeat and proclaiming it all kinda looks the same?

There is. I believe that place is talking about symbols, tokens. Not what each language uses as symbols, but the idea of symbols themselves and how we use them.

Tell me what you Want

I've talked about this before with Code Budgets and Code Cognitive Load, but hope springs eternal, so I'll make another run at it.

As a programmer, you want stuff. Maybe you want the computer to print out "you're old!" if the age is greater than 20. So you type in the following line of code.

if (age>20) {console.log("You're old!")} else {console.log("You're not old!")};

Here you are the programmer and you want the computer to do something that outsiders can see. You tinker around, the computer does it. That seems to me to be both a practical thing and something we can measure regardless of any of the details of the actual technology used.

You've entered some things into your IDE. I'm going to call these "symbols" but you could use the word "tokens" or several other names. Doesn't matter. In our case "if" is a token, "else" is a token, the brackets are each tokens, the parenthesis, the variables, the conditional, and so on.

There are a lot of symbols here! Not an infinite number, of course, but a bunch. Fortunately you can learn about most all of these as you learn the language and never have to relearn them, but this is not important. They're still symbols, and you have to remember them and how they work if you use them.

You have to use some kind of symbols to get the computer doing new stuff, even if it's just talking to it. Ideally, the answer would be "one", something like:

tellMeIfImOld();

One symbol, one behavior. Life is good, at least for our toy problem.

Moving Past The Trees To Seeing The Forest

Let's say each Monday morning you sit down and write out what sorts of behaviors you want the computer to perform this week. Not functions, stuff you can see from the outside, cause-and-effect. The user pushes the button, the computer makes a belching sound. Boom, there's your first one.

On Friday this same week, before going home, you mark which behaviors you got accomplished, then total up the number of symbols you had to manipulate to get that work done. Not the amount of code you wrote! No, you write down and count up each little hunk of symbology that you typed in, maintained, deleted, looked up, and so on. Little chunks of things that had to go through your brain to make the computer do what you wanted.

Once again, not something you'd want to do by hand, but not impossible, either. I could easily imagine a plugin that could handle this for you.

Takes a lot of trees to make a forest, and doing this by yourself for just one week isn't accomplishing much. Some weeks you may use a small number of symbols to get a lot done. Some weeks may be spent going through millions of symbols and still you didn't reach your goal.  That's life, right?

In the aggregate, though? In the aggregate this gets extremely interesting and useful. If you had ten thousand programmers doing the same thing no matter what they were trying to do or what technology they were using, you'd start to see patterns. For instance, people using low-level languages might use a lot more tokens to get their goals met as folks using high-level languages (I suspect this is not true! But that's a conversation for another day)

The thing is that reasonable people, no matter what they're doing or what sorts of tech they're using can measure and compare something that's not a personal preference. It's more like an opinion survey: 90% of folks got everything they wanted accomplished this week when they did X, Y, and Z.'

"Did I get what I want, easily?" is probably the most profound metric you can apply to your programming career. Why aren't you using it?

The Non-Conclusion Conclusion

I'm not going to draw inferences for things you might discover. I don't need to. Go do it yourself and see what you find out. You'll figure it out.

The thing is, for many, programming is, well, just fun. They sit down for a small amount of time, they play around a bit, and it just works. We've known this for some time, but what we don't like admitting is that these folks aren't super geniuses. There's nothing magical here. This is something we can measure, teach, and learn.

We should be doing so. No, it's not all just the same. Sorry.

NOTE: I imagine some folks would want to talk about the difference between maintenance, testing, and greenfield development. I call bullshit on that, though. TDD and other wonderful practices exist for the sole purpose of accomplishing exactly what I'm saying: doing the most with the least. Chopping certain favorite parts off and calling them a "special" thing, not programming, takes us down that long and endless road that leads to braces-stands-alone stuff. Just look at what you want and how much pain it took to get it. The rest will come out in the wash over time. If you can't write code that you don't have to fix all the time, your Symbol-Behavior Mapping (SBM) count will go sky high anyway.  All of these other considerations will work themselves out.

Use Code Budgets. Please. Track Code Complexity Level. At the very least, be actively aware of this SBM metric every time you code. It's your career. Don't make it a miserable one.