Low-Code Generation Z

02 May 2024
💬 EN

I’ve seen a lot of handwringing about Generation Z not grokking hierarchichal file folders and directories.

At the other end of the spectrum, software engineering professor Dimitris Kolovos wrote:

“a growing proportion of the workforce are digital native and, while they may lack a background in programming, they are well-versed computer and web users and skilled with non-trivial software (e.g. office/mobile applications). Low-code software engineering aspires to leverage this increasingly computer-savvy workforce”

So which is it as the old PC-raised software application implementers retire and youth replace them? A bunch of technologically helpless fresh faces or “well-versed and skilled computer users?”

Still not enough formal education

As I wrote in “In defense of Salesforce Flow,” I strongly believe that computer education for the masses needs to catch up quickly with the explosion of flowchart-based programming languages.

I want to see more computer science and software engineering best practice books, blogs, and self-help videos that teach intermediate and advanced programming concepts from the 1970’s-2000’s, but entirely demonstrated in flowchart-based programming languages.

I’m horrified that in 2024 with enterprise workers working magic in Salesforce Flow and Microsoft Power Platform, I Googled “low-code software engineering” today and still didn’t find anything useful on old-school software engineering principles.

Hope in tablets

Maybe the tablet generation’s relative ignorance of certain details about desktop user interfaces is going to help them – and the educational leaders shepherding them – avoid missing the forest for the trees as they enter the workforce and become low-code software application developers.

Maybe teaching the TikTok generation (many of whom have more hands-on-experience-driven intuition about film lighting, reasons to choose a certain type of scene cut, etc. than I learned in 2 semesters of college-level film studies, so I suspect playing around on a tablet has, as Dr. Kolovos suspects, still rendered them a “computer-savvy workforce” at a business objectives level) about “D.R.Y.” software application implementation is going to be the desk job world’s 2030’s equivalent of teaching the Oregon Trail generation Excel.

---

LLMs

Update, 4/2/2026:

Today, cartoonist Adam Turner published a comic that satired mid-career professionals insisting an LLM can’t replace their skill, with the professional then turning around and outsourcing the gruntwork of their job to an LLM.

I’m here to to tell you that we mid-career professionals worry about this a lot, for a few reasons:

1. Justice (the Taylorism and wealth gap issues of it all – is it really fair for mid-career professionals to be increasingly expected to turn out large teams’ worth of output benefitting a company without receiving a meaningful raise, just to keep their jobs? Also, churning out that much work on that many features/products requires insane amounts of context-switching to a degree that is probably bad for human mental health, and that seems like a problem of injustice for those mid-career professionals having to do all of that context-switching)
   • (See also Dusty Bock’s and Tobias Van Renning’s comments toward the top of this thread, this article, and this article.)
     • (Actually, skimming those and realizing that this a 19th-century problem of Taylorism causing human health breakdowns … hmmmmmm … I wonder if American labor union law needs to be updated from a 19th/20th-century model where “Most unions don’t allow managers to join, as they’re generally considered to be part of capital’s collective bargaining side, if not part of capital themselves,” to a 21st-century one that presumes knowledge/information labor can be equally hard on a living breathing organism. To better allow workers whose labor is to do the cognitive labor of managing fellow workers to form and join specialized unions of their own. The way much of Europe already seems to have allowed for, even on their old 20th-century manual labor workplace models. Much of Europe solves the “representative of capital” problem, it seems, by just having separate labor unions dedicated to protecting worker’s rights specifically for people who happen to also have hiring/firing/task-delegating power over other people. I’m not sure if US labor law is sufficent to protect human health from cognitive overwork yet the way some European labor law seems to be?)
2. Mentorship, which is what the rest of this section will discuss.

Most tech podcasts I listen to are wondering how on earth we software developers are supposed to train up Generation Alpha and the younger members of Generation Z on what we know, in the era of LLMs.

If we can leverage – and are expected to spend all of our time leveraging – our expertise to supervise outsourcing gruntwork to LLMs instead of to young humans, how are we going to mentor the young humans about all of the weird stuff that makes us experts?

We’ve always done that teaching as part and parcel of getting work done, while peer-reviewing the gruntwork we delegated to the junior developer.

This kind of loss of “structure within which to teach concepts” isn’t new.

1. Teachers had to reinvent how to teach research skills when suddenly Google and Wikipedia existed.
2. Math teachers had to reinvent teaching algebra, geometry, and calculus concepts when suddenly graphic calculators existed.

It’s not that we can’t figure this out. I just am not yet seeing that we have.

Which makes sense – for the most part, unlike licensed teachers, we programmers are not formally trained in instructional design. We just taught the way lots of animals do – as a show-and-tell side effect of interacting. Of course it’s going to take us longer to figure out how to reinvent teaching than it took teachers.

But wow, this old post feels so … naive? small? beside the point? … with its focus on deterministic low-code tools. Those still involved a software development lifecycle (“SDLC”) bottleneck where authoring “code” was relatively slow, so there were inherent opportunities for mentorship and transfer of oddball expertise (all the wisdom the 1990s called “software engineering”) baked into the rate of change inherent to the process of collaborating to author “code.”

My I’m as much at a loss as everyone else about what teaching software engineering best practice looks like in the era of fast authoring. Has anyone else seen great tips and tricks, as we fumble around trying to figure it out? Leave a comment if so.

• (So far, all I’ve heard about is hiring committees improving interviews to watch while prospective developers work alongside LLMs, to get a better sense of their existing software engineering expertise, and/or their curiosity and creativity, as hinted by the prompts they ask the LLM. But I still haven’t heard much about how, once someone already works for you, you skill them up at software engineering and best-practice use of LLMs.)