Welcome Guest | My Membership | Login

Business Tech: Watch Your Language


Article

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?

 

# # #          # # #          # # #

 

Related Articles

  • From the Inside May/June 2018

    Company: International Spectrum

    Our community has been battling this issue for years: the perceived lack of entry and mid-level developers. One of the things that I noticed in the last few Spectrum Conferences was that the age demographic of our attendees was trending younger.

  • 37th Annual Spectrum Conference Recap

    Company: International Spectrum

    The International Spectrum Conference for 2018 covered a lot about modernizing systems and re-inventing your IT environment for both new and existing developers. See what you missed at this year's four days of education, networking, and more.

  • Using OWIN Security with MultiValue Data - Part 3

    Company: International Spectrum

    Our series on OWIN continues with even more information about OWIN classes. This will give you the information you need to create the proper connection points between your database environment and OWIN.

  • MV Your Way: Extending mvBASIC

    Company: HDWP

    Every developer, regardless of languages used, tends to have a list of commands or processes or functions that annoy them. In MultiValue, it can be things like how the parenthetic version of the LOCATE statement has a parameter order of needle, haystack but the INDEX statement is haystack, needle. Or maybe you wish that OCONV had a few more options. This column is all about remaking MultiValue to work your way.

  • Business Tech - Computer Memory…the Other Kind

    Company: HDWP

    Sometimes we need to take a fresh look at what we do. While our ground-level perspective is superior for detail, we need to pull back a few thousand feet to really see how things connect. This installment of Business Tech asks the deceptively simple question "Is your data complete?"


Return to top