Low-Code Generation Z

02 May 2024 🔖 professional development prompt engineering
💬 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.)

Update, 8/12/2026: my original thesis still stands! Formal software engineering education is the entry path for our youngest developers, just as it was for me!

Florian Herrengt just pubished “AI is removing the middle class of software engineering” and I wrote in my diary:

“My years formally studying software education as a ticket into getting to be a programmer for a living speedtracked the transfer of perspective and context from my elders to me, which let me have judgment from the get-go about what makes a software implementation ‘good,’ even before I could properly code. What a gift!”

And then it hit me – just like I said about Scratch-like “low-code” programming languages … that’s it. We don’t have to reinvent the wheel.

There are literally software engineering university degrees out there that teach you a wealth of things about project management, gang of four patterns, application architecture, storage, networking, cryptography, release, etc. etc. etc. and … oh yeah … are also happy to throw in a few programming classes so you can get your hands a little dirty before you graduate. They’re designed to be timeless, keeping around the best of the 1900s and only adding things in as best practices consolidate around them (e.g. 2000s/2010s big distributed computing/data, 2000s/2010s automating client-server software release processes).

And you know what? Mine was timeless. Because it focused on systematically, with drills and exercises and tests, passing down the best practices that my elders figured out the hard way that worked.

Now, at an economic justice level, I don’t know how we’re going to deal with LLMs’ velocity problem wiping out on-the-job curricula where people get paid to learn software engineering from their direct elders rather than paying a professor for the privilege of learning the knowledge of long-retired elders. Florian Herrengt’s 100% right that that’s a major blow for economic justice to people who need to get paid to learn software engineering rather than able to afford paying to learn it. (I got lucky and got a free ride, and had the free time for all that homework.)

But I do think that the idea that such things can be taught in isolation before writing much code is well-proven by formal educational programs.

• I know I certainly feel like walking proof of that thesis. The money model’s all kinds of unfair and messed up and wealth-gap-ish (as it is in, say, open-source software maintenance), I’ll admit, and I suppose that’s really what I wrote about on 4/2/2026, and yeah, that’s not a solved problem.
• But the instructional design question – of whether “software engineering” – taste, quality, good-ness, etc., whatever you want to call it – is teachable without students having to actually write much good code as a way of learning it – is a long-solved problem. The answer is “yes.”
  • (I consider myself a pretty decent coder / code-reviewer, but when I started I wasn’t, but from the get-go, thanks to that formal education, I had a pretty good idea of how to find out if it was any good and how to understand what peer-reviewers were trying to tell me. And I’m the kind of prompter Florian dreams of because of that formal education in software engineering, taught by people who’d dedicated years to learning to train people and who were paid full-time to train people. I attribute my sense that I’m not “vibe coding” hugely to my formal software engineering curriculum.)

I dunno, maybe more than ever, we need corporations to invest in paying for their “non-programmer” “business side” staff who’ve proven their mettle as process-oriented critical thinkers to attend formal “software engineering” schools, and then place them as the “junior developers” in-house?

It doesn’t take care of the people without jobs at all, or without time for work + night school, but it does at least help somewhat with the economic justice for that subset of “newbies.”