The Power of Understanding

This post describes my personal approach to software development. It highlights different aspects that are not strongly connected but all affected by generative AI – a topic I’m not particularly keen on writing about, but here we are.

Shortly after I got internet access, I came across a free documentation: “SELFHTML – create your own HTML files”. Established in 1995, Selfhtml was one of the first German webauthoring tutorials. Its influence on the early German-speaking web cannot be overstated.

Selfhtml was founded by Stefan Münz, who studied literature and philosophy and trained as an application developer. His fascination for Hypertext systems brought him to the web. Münz aimed to establish a welcoming, sustainable community that contrasts with the toxic sysadmin culture that still dominates technical discussions.

Selfhtml not only explained web technologies, but always came with a critical commentary on common practices and the booming internet economy. This tutorial and its community planted ideas in my head that went far beyond technical skills.

In the 90s, people with different social and professional backgrounds logged into the web for the first time. Almost no one was a programmer or computer scientist. Many were students, teachers, homemakers, retirees. The profession of a web developer was just forming.

I realized that people hold different approaches to webauthoring: Some want to understand the underlying concepts, like the radical impact of Hypertext. Some value the personal expression and artistic freedom. Others appreciate the intellectual exchange in web communities that connect people from all over the world.

By 1998, Selfhtml adopted the motto “The Power of Understanding” (“Die Energie des Verstehens”). This motto still resonates with me. In the community forums, I learned to grasp what learners are trying to achieve, to debug problems and to explain them with empathy.

This allowed me to develop an important professional skill: Finding out how things work, getting to the bottom of things and communicating them clearly.

Caring and understanding

Matthias Ott recently wrote on using GenAI in the workplace:

[Before] AI, organisations relied on the quiet labour of skilled professionals to compensate for weak process and poor decision-making. […] Care filled the gaps. […]

If we reduce professionals to reviewers of machine output, we don’t eliminate “the work”. We don’t make work more easy and efficient. And we also don’t increase the speed and quality of our work. We devaluate it. We displace it. […]

The care is the work. The care creates the value.

This made me think about what matters to me professionally: I strive for quality based on principles such as usability and accessibility.

Making good software requires a broad and deep technical knowledge and understanding of the field. As you slowly build up experience, you get quicker and more efficient at acquiring knowledge, developing skills and making decisions.

When applying my knowledge, I try to understand the use cases and weigh up the requirements. I pay attention to details. During implementation, I try to find a simple and robust solution using defensive programming, based on proven architecture.

While this methodology values quality, it still allows you to design and implement features quickly. The velocity comes from mastering your craft, from a strong confidence in the system, from making quick and informed decisions.

Once the software is deployed, my colleagues and I are responsible for distributing, scaling, maintaining and enhancing it. Without an accurate mental map, without a understanding the logic and the trade-offs behind it, I would be unable to reason about, debug and extend a piece of software.

For me, software design and development is a hermeneutic process: I rely on deep understanding and the process that lets me question and refine my mental map – a hermeneutic circle.

Goal, process and passion

While there are many valid approaches to software development, people try to pit them against each other. Some attribute support for and opposition to GenAI to personal traits:

On the one end, there are supposedly goal-oriented developers. They want to get the work done. They see their tools as instrumental and interchangeable. They are excited about the final product and its impact on the user. They find pleasure in other forms of art, culture and community.

On the other end, there are supposedly process-oriented developers. They want to achieve the goal with reliable, sustainable tools. They see software development as their craft and emphasise coding as a form of art. Programming is their passion, part of their identity, and they take pride in their work.

According to this dichotomy, goal-oriented people are eager to adopt GenAI while process-oriented people oppose GenAI. The dichotomy is often part a rhetoric that tries to frame GenAI as “inevitable”. With condescension, proponents of GenAI tell the latter group to find other ways of creative expression since their craft is being destroyed “inevitably”.

While a spectrum between goal- and process-oriented people may exist, I think this is a false dichotomy because process and final product are inseparable.

As Zach Leatherman sums it up:

it’s important to keep caring about how things work and how they’re built

“How things work” and “how they are built” are interwoven. A good design process leads to good code using reliable tools and techniques, which leads to usable, performant and accessible software.

Good software stems from diverse teams with proper resources and organizational support. A team where each member lifts up other members to produce better results within the given constraints. Where friction inspires and encourages everyone.

To recognize how process and goal are intertwined, programming does not have to be your passion or part of your identity. It does not matter whether programming is a job for you to get by or whether you take artistic pride in it.

The field fell into this trap several times. In the past, privileged cis-male gatekeepers looked down on newcomers accusing them of “being in it only for the money” and lacking any deeper interest. With schadenfreude, GenAI proponents now invoke the same trope against the old guard who sees the act of writing code as a craft.

For me, software development is wage work first and foremost. I am motivated by the goal: I want the software to serve the user. But each time, I work myself backwards from the goal to a certain process: thought-out architecture and meticulous programming practice.

Information retrieval

In 1989/1990, Tim Berners Lee wrote his original proposal of the Web for the European Organization for Nuclear Research (CERN):

We should work toward a universal linked information system, in which generality and portability are more important than fancy graphics techniques and complex extra facilities.

The aim would be to allow a place to be found for any information or reference which one felt was important, and a way of finding it afterwards. The result should be sufficiently attractive to use that […] the information contained would grow past a critical threshold, so that the usefulness […] would in turn encourage its increased use.

My “hermeneutic” approach requires research: posing questions, finding information, connecting observations to form a working hypothesis.

In the past, finding information mostly meant searching the web. Reading documentation, API references, source code, forums. Then writing minimal demos with in plain HTML files, simple scripts. Probably using starter kits, boilerplates, CodePen.

This practice is now foiled. GenAI thwarts finding information because it poisons the very well it draws from. Public programming forums like StackOverflow are winding down because programmers ask LLMs instead, among other reasons.

Web crawlers are hammering all possible sources of information and code. The open web is dying. Publicly accessible knowledge decreases or is poisoned by slop while AI companies enclose information to sell it back to programmers.

Searching effectively used to be a crucial programming skill. But search engines are almost unusable now for these purposes. There are noticeably fewer results for programming questions. The remaining results are generic and fuzzy even for very specific requests. Results are filled with spam and slop.

I’ve been searching the web since 1998. With every search query today I realize that the big tech corporations have stopped funding semantic search and have diverted their investments to GenAI. The text corpus that used to be the search index is only valuable for training LLMs nowadays.

AI companies keeping programming knowledge in their silos means that searching the open web becomes increasingly pointless. “Prompting” an LLM is the only way left to access this information. But then the output is so fuzzy, random, flawed and devoid of context that it does damage in ways you cannot foresee.

Search engines have terminated the tacit agreement with publishers that once formed the basis of the web economy: Publishers created high-quality web content. Search engines rewarded this by listing these sites on result pages, directing traffic to them. Sites were able to monetize this traffic.

Step by step, search engines implemented ways to keep users on their site. They integrated the helpful information directly into the search result page. For the publishers, inbound organic search traffic plummeted.

LLM chatbots drove the final nail into the coffin of classic web search. At most, web pages are added as “sources” for the LLM output, which they often are not, making it impossible to assess the provenance and timeliness of the presented information.

Years ago, I would have advised beginners to start a humble blog and publish their lessons learned regularly. Without much effort, people would find your writings through search engines, give feedback and blog about the topic as well. As Tim Berners Lee wrote, the usefulness would encourage its increased use.

Today, GenAI is depriving us of the tools to share and acquire knowledge, to connect with each other, to contribute to this “universal linked information system”.

Learning and education

When you learn to transform problems and requirements into computer programs and user interfaces, you not only amass facts in your brain. You grow as a person, you develop instincts, opinions and taste. You become an expert in fields of your choice. You learn how to critically assess different approaches. You connect with other practitioners, follow their work. Their views constantly shake your worldview.

Especially junior developers need to have the freedom to dive deeply into technologies. They need be able to read and write code without haste and unnecessary pressure. They have to make mistakes themselves and learn from them. They become creative by experimenting and exploring.

Carson Gross, who teaches computer science, tells his students that they have to write the code:

If a junior programmer does not learn to write code and simply generates it, they are robbing themselves of the opportunity to develop the visceral understanding of code that comes with being down in the trenches. […] If they don’t write the code, they will not be able to effectively read the code.

More broadly, the astrophysicist Minas Karamanis describes that no aspiring scientist can skip the “grunt work” and outsource it to AI.

Karamanis describes two hypothetical PhD students named Alice and Bob. While Bob uses AI agents for the research, Alice does not. This enables Alice to [build] a structure inside her own head, and that structure is hers now, permanently, portable, independent of any tool or subscription. Karamanis:

What’s great about science is its people. The slow, stubborn, sometimes painful process by which a confused student becomes an independent thinker. If we use these [AI] tools to bypass that process in favor of faster output, we don’t just risk taking away what’s great about science. We take away the only part of it that wasn’t replaceable in the first place. […]

Every hour you spend confused is an hour you spend building the infrastructure inside your own head that will eventually let you do original work. There is no shortcut through that process that doesn’t leave you diminished on the other side.

What is essential for the scientific method applies to software development as well: We need confusion to build the infrastructure inside your own head.

Mental capacity

While self-directed learning is challenging and mentally taxing, there is a natural limit. If someone or something pushes you beyond that limit again and again, you burn out.

Producing the code to implement an idea used to be a bottleneck in software development. Proponents of GenAI say that code is cheap now since it can be generated en masse. Code is cheap if no one has to understand, maintain and support it. If no one takes the responsibility for its consequences. If you ignore all externalities that LLMs involve.

Thus, code is never cheap. Long before code was LLM-generated, practitioners pointed out that the sheer amount of code is a liability.

Junior software developers learned to read, write and change code. Senior developers assisted them with these tasks, but also identified code that should not be written or changed in the first place. After careful consideration, they politely said “no” to features and changes – to protect the stability, usability and performance of the software.

With LLM-generated code, these checks and safeguards aren’t removed necessarily. But the burden of responsibility is imposed on individual developers.

As the computer science professor Margaret-Anne Storey writes, generated code leads to cognitive debt in the brains of the developers and affects their lived experiences and abilities to ‘go fast’ or to make changes. She states:

Cognitive debt is likely a much bigger threat than technical debt, as AI and agents are adopted. Peter Naur reminded us some decades ago that a program is more than its source code. Rather a program is a theory that lives in the minds of the developer(s) capturing what the program does, how developer intentions are implemented, and how the program can be changed over time. Usually this theory is not just in the minds of one developer but fragments of this theory are distributed across the minds of many, if not thousands, of other developers.

GenAI does not require you to develop a theory in your mind. Since it tends to isolate each developer, it is less likely that a theory is distributed across minds. Storey experienced that velocity without understanding is not sustainable and advises developers to slow down and apply proven practices to build a shared understanding.

Experienced users of GenAI describe their work as “mentally exhausting”. GenAI churns out lines of code so fast that their brain is not able to keep up.

The software engineer Marvin Hagemeister describes this experience as a Distributed Denial of Service (DDoS) attack on the brain. The sheer volume of code, the rapidly changing tasks and responsibilities require your brain to switch between contexts often and remain in a hyper-vigilant state.

A study by Aruna Ranganathan and Xingqi Maggie Ye, professor/student of Management of Organizations, showed that AI doesn’t reduce work, it intensifies it: Employees worked at a faster pace, took on a broader scope of tasks, and extended work into more hours of the day, often without being asked to do so. The introduction of GenAI into the workplace widened the field of responsibility, expanded the quantity and density of work. That workload creep can in turn lead to cognitive fatigue, burnout, and weakened decision-making.

The Conditions of Possibility

When thinking about the future of software development, I am wondering about the Conditions of Possibility: What do software and web developers need …

to be able to learn something,
to be able to apply these skills,
to be able to achieve something they want, something that benefits the users.

On all of these levels, the preconditions are being destroyed and taken away from us.

GenAI is an onslaught on developer agency and independence, specifically on thorough understanding. Instead of thinking through a problem and editing few lines of code, GenAI encourages you to burn through millions of tokens – mostly a synonym for fossil fuels – to brute-force a solution that adds hundreds of lines of code. Such a workflow makes independent, self-directed learning with educators, mentors and coworkers less attractive and more and more impossible.

My “hermeneutic” approach is one possible approach to software development. There are plenty of others, perhaps equally effective and important. I am not defending it for my own sake. I simply hold the opinion that pursuing this path should remain possible.