Business Tech: Watch Your Language

Whorfianism

John Lennon: You speak English?

Jeremy Hillary Boob, Phd.: Old English, middle, a dialect, pure.

Paul McCartney: Well, do you speak English?

Jeremy Hillary Boob, Phd.: You know, I'm not sure!

Ringo Starr: He's so smart, he doesn't even remember what he knows.

The theory of Whorfianim states that language is a critical part of how we form thoughts. We've all heard this, we know it, accept it. There's a fair amount of scientific evidence that it isn't true. Let that sink in for a minute. Language has a huge effect on how we communicate thoughts but it has less to do with the way we think. For more on this: https://www.scientificamerican.com/article/does-language-shape-what/

Despite that, I'd like to submit to you that programming languages are a critical part of how we form code. And, I'd like to further assert that the biggest impact is from the first language — or languages — you use professionally or extensively.

When we try to bring non-MV people into MultiValue, it is useful to know their roots.

A Million Words

When you start with a wordy, long-winded language like COBOL, you tend to plan a bit before committing your ideas as code. Even those of us with a high typing speed and a low error rate are more likely to cowboy our way through a coding project in a terser language.

But once the plan-first perspective takes hold, many programmers find that they keep that habit long after they've changed languages. If you don't believe me, watch a COBOL programmer — they still exist, there are a lot of them — try their hand at PHP, Python, or mvBASIC. You can almost see the thoughts forming.

Stop Java-ing

At the risk of offending a lot of very smart people I know who code in Java: Stop. Java is based on C and C++. These are mid-level languages. They should be used to build compilers, interpreters, operating systems, and engine. If you are using Java/C/C++ to write LOB (Line of Business) software, please take a deep breath and step away from the keys.

The problem with learning Java and applying it to application development is that you are drawing with sledgehammers. While scraping the head of a hammer on paper might make a mark, it isn't really drawing. Likewise, I try not to break down walls with crayons. Java is an amazing and powerful language when it is applied to the correct sort of problems.

Watch a Java-indoctrinated programmer develops in any language and it will likely look as if they got the memo about segmenting code but missed the memo on making each segment clean and distinct. When you build operating systems in Java, the reasons for the division of code make sense. When you write accounting in Java, you end up with code that is much harder to support than if you worked in a high level language.

Please note: C# is not really in the C family. Swift is C but it tends to avoid the issues I'm discussing in this article.

PHP... Python… JavaScript...

These are languages that are brilliant at solving short problems. People who work in them are often very efficient on those sort of projects. When the work gets longer and more complex, the solution tends to be libraries of third-party code, often open source. Using these assets makes big projects somewhat smaller because a lot of the complexity is off-loaded onto pre-existing code.

Bad Programmers

No one language has a monopoly on bad programmers. They come in all shapes and sizes. It helps if you think of them as people speaking a broken dialect. I don't blame a person who speaks broken English for speaking broken English. Most bad programmers, in my experience, are parroting what they already saw someone else do.

If all I've ever seen is bad code (written by people who knew better but were rushed) then I will think that's how code is supposed to be. If all I've ever seen is the code with dozens of poorly documented patches, I won't know that it started out well structured. If all I get is X=A+Q then I won't likely think about good variable naming.

Most programmers are accidental programmers. They don't have any training, not formal training. They mistake code that works for good code. That it works is not enough. Code needs to be supportable, modifiable, and provable. People who speak broken dialects can be shown how to speak better.

What Would Chuck Do?

I have an advantage because I am a professional trainer. But, if I weren't, I would do for others what was done for me when I started in the business. I would send them to a class. However expensive training is, in time and money, if it prevents errors, there's an argument for it.

Ask yourself if you industry has regulations — they all do — that can result in fines — many do — if data is mishandled or misrepresented. Weigh those fines against training fees. Many companies are at risk for SLA (Service Level Agreement) penalties that can be prevented by improving the language skills of your people. Some of us are in businesses where chargebacks — essentially fines created by our too-big-to-lose customers — make certain mistakes insanely expensive.

So, as a business professional and as a technical person, I wave the flag of get-them-trained proudly and publicly. But it isn't enough to train them. You have to make sure that the training takes into account their current perspective. The way the already tilt their head when they want to see a path through the code will have an impact on how they code.

I'll leave you with a parting thought that's been oft quoted to me:

Big Boss: What if we train them and they leave.

IT Manager: What if we don't train them and they stay?

Featured:

May/Jun 2018