Many years back I had a player on the MUCK that was majoring in Software Engineering. I asked them what sorts of things they were doing and what their plans were, only to be told that they didn’t want to talk about that school stuff on their time. They didn’t really care about tech, other than as a job. So be it.

They graduated. I asked what they were seeking. “I’m going to get a job doing process — not grunt coding.” Grunt coding. I pointed out that without experience, they were likely going to start at the bottom like everyone else. They disagreed. They had a BS degree, after all.

It was a few weeks later when they were back and I asked how it was going. “I’ve got a job.” “Doing what?” “Writing reports in VB for a bank.” They didn’t seem at all happy. Granted, after the contempt for grunt coding I couldn’t help myself, “How’s that process working out for you?” They never spoke to me again.

Much of what we do as developers is in fact “grunt coding.” Much of what auto mechanics do is in fact “turning wrenches” too. Like fixing cars or home improvement there are many classes, bootcamps, online courses, self-study programs, books, etc., on the use of our various tools. And like mechanics, knowing how to work our tools is necessary — but it’s not sufficient.

What is necessary to go with what is sufficient?

The Ones Who Are Doing Great

Starting in high school there’s many great programs and paths for those with a burning passion for building software. The whole STEM movement has really helped in this — geeks are cool. I was born too early for that one, darnit. But, it’s true.

Want to control robots and pit them in battles in arenas? Check. Build virtual worlds? Check. Work on projects with local industries? That too.

Almost all of these programs are helping guide brilliant youngsters into exceptional universities, where they can pursue Computer Science degrees on scholarships.

In all honesty, even if we offered these kids no help whatsoever, they’d still thrive. They have available resources for free online even when they’re attending schools without the budget for better.

Naturally, when these people graduate, with a background that includes calculus, statistics (for machine learning), physics, and all the classes on CS theory the last thing they want to do is write VB reports for banks. They go off to Google, to Microsoft, or to SpaceX. They are desperately needed.

What About Those VB Reports?

But we need those VB reports. Well, today, we need those PowerBI and Tableau business analysts who make the reports.

And we need the people to write the microservices for accepting business transactions. We need the DevOps people who can get the Jenkins CI/CD pipeline working and keep it working.

To put it simply, we need a lot of grunt coders. And I mean that in the kindest way possible.

And we’re not finding them.

Shop Class

I’ve been speaking with a few people lately about trying to fill the voracious needs for computer programmers. Not Software Engineers or Computer Scientists, but … programmers.

Computer programming has a degree program too. Community colleges routinely have AS/AAS programs that teach the mechanics of programming languages, SQL, basic Windows and Linux skills, and a small variety of other useful topics. Mostly, the programs teach programming languages and tools.

This isn’t a bad thing. To be a programmer, one must know how to use a programming language. But, to put it in perspective … to be a writer, one must know how to use words and grammar; even though just knowing words and grammar isn’t enough.

I don’t like explaining via analogy, because all analogies break down. And yet …

In a shop class, back when I was in high school many decades ago, there were cars and tools. The students were taught how to use the tools and then they were taught how to use them to fix the cars. The point wasn’t the tools for their own purpose. The point was that using the tools they could fix the cars.

Computer language classes are effectively coding classes. They are teaching a tool. C++ is a tool. Java is a tool. We don’t learn either of them for their own purpose but in order to achieve a goal. The goal, in software, is to create a solution that achieves the requirements.

The Programming Reality

But programming is not a shop class. The analogy fails because in a shop class what the students do is representative of what people do in the real world. Auto mechanics truly do use their tools to fix cars. The point is to fix cars.

We don’t “fix” something when programming, unless we’re doing maintenance on an existing program. But that skill, maintenance coding, is not taught. It requires the ability to read existing programs, figure out (through much pain) what the code does, and then figure out what it will take to modify it to either fix a bug or add a feature. This is an example of programming reality — many developers will never write a new program professionally. They will enter an organization with millions of lines of code and take part in keeping those lines working.

But many other programmers will be told a problem and be expected to solve it. This is nothing like fixing a car.

By far the hardest task of programming a real system is determining what constitutes “the problem.” If the greatest programmer alive solves the wrong problem the program will be (rightly!) rejected.

Once the problem is understood, there are an enormous number of ways to use computer technology (or other technology) to solve it. This requires creating candidate solutions, evaluating them for suitability, and picking one. This is not a trivial process — but it is often skipped. People just “jump into code” instead of actually plan a solution. Whatever their first thought is they go for it.

Once a candidate solution is chosen then it must be broken down into small enough steps (or parts) that each can be tackled with the resources available. Even a team of one can only do so much in a given day — breaking it down is key to enabling focused work on each independent and dependent part.

Lastly, grunt coding. Finally, we get to put that C++, Python, Lisp, Java, Prolog or even Haskell to work.

We’re still not done. It has to be tested, go through verification and validation, and then be deployed.

Then the cycle enters maintenance — finally, where the shop class started is reached.

Learning the Programming Craft

All these steps, from problem to solution, require more than tools. No amount of great and powerful tools will “solve” the customer’s problem until they are used by the programmer. These tools include programming languages, but also modeling languages (like UML), written prose, CASE tools, etc.

And more than anything, the craft requires diligent practice with continual feedback. It’s very easy when “working before a glowing screen alone in the dark” to do awful work and not realize it until the next maintenance cycle — when the “idiot’s code” being fixed is your own.

This is where even the university BS, MS, and PhD programs tend to struggle. They can teach tools — and they do. They can teach algorithms, lexer and parser design, UML … but they don’t have the time (or the intention) of having the students sit down with experts for hundreds or thousands of hours and bring them up to speed in the pragmatics.

This used to be normal. A new hire would spend a lot of time working with a more experienced developer, doing simple tasks and learning to do them well. It was very similar to an apprenticeship model, only without the beatings and cruelty from the middle ages.

Not Teaching the Craft

However, at some point (in the late 80s and early 90s) the idea that coding was “mechanical” came up. That led to the offshoring movement and the claim that we don’t need programmers because “coding is a monkey task and we’ve got hundreds of coders who can code what they are asked for.” It didn’t work. I always asked the question “Where will you get people to give the coders good designs?” The answer was always “Our senior people.”

The obvious question “Where will you get senior people when you have cut off the pipeline of programmers?” always went unanswered.

Today, there’s two shortages: good entry level people to do the work that is well defined and doesn’t require astonishing brilliance (the jobs that the CS grads reject); and the second is a lack of senior people because without that time spent building up the craft the people with many years actually lack the expertise to do the work needed.

In effect, someone who has spent 20 years of doing something poorly is little better (if any) than someone who has spent one year doing something poorly.

We have failed as a craft, professionally, for years. We’ve not helped our developers actually do well.

We have great tools, though. Yeah, that’s … wonderful.

How Can We Fix It?

In speaking about finding talent I have often asked, “Why not train people instead of try to fight for the small pool?” Finally, I’ve started getting people wondering if they can.

Many places have setup training programs where they get “the best grads” and they run a hard multi-week course and “filter out” the ones who don’t cut it. There, they say, “We have trained new hires.”

No, what they did was cherry-picked the ones who didn’t need their training. In many ways, the “training program” is an extension of the job interview. This is the case even when they do teach useful material in the training. The reason it isn’t good training is because it’s not long enough doing the work under supervision with feedback. It’s a class.

Instead, we need to step back a bit. How long does it take someone writing Python to also learn how to decompose a prose description and make a design? To interview a payroll clerk or gas station attendant and capture their needs?

These questions assume they already know the tools. I can teach someone the Python language in a week. I can’t teach them how to program in Python in a week unless they are already a skilled programmer.

Expect that each person will learn at a different speed. This isn’t a class that I’m describing. It’s more like a maker-space or an apprenticeship. It’s about doing and not about talking or listening to people talk about doing.

Some people get it and would be able to leave and do great work in weeks. Some might take months. Does it matter?

The reality of programming is radically different from what most people expect. If in a few weeks or months they realize that they absolutely hate attempting to be perfectly precise without any error to a machine that tells them over and over “You are wrong!” then they’re smart if they quit. They may not discover this in years of school, with assignments that last under an hour.

This doesn’t need the people to have degrees. If they have a degree, they’ll likely pass through more rapidly. But, some of the best developers I know do not have degrees. What they have is patience, diligence, and discipline. They also have determination and the will to succeed.

Please don’t misunderstand — I’m all for people getting a degree. But most programming doesn’t require calculus. It’s rare for a modern developer to create a sort. Most developers will use libraries instead of rolling their own lists or sets.

Let’s actually take the time to spend with those who would be programmers and have them program with us. We can do it personally, as a mentor relationship (even while they are students). We can do it professionally by setting up places where retirees lead real projects with inexperienced developers and give them the days, weeks, or months they need to become good in the craft.

Classes can’t do this. This is obvious in many professions:

• doctors have residency
• airline pilots have to be copilots
• lawyers work as juniors
• baseball players go through HS, university, and A, AA, AAA before major leagues

We’re really not different.

Let’s really promote the profession — let’s help even those who aren’t driven to university learn how to do the best they can. We all benefit from it.

Keep the Light!

Otter
Brian Jones