The Human side of Coding @ Dutch AI Conference

Now that AI’s are writing our code, what is the value that we humans still bring to building software systems?

Our tech stacks are exploding in complexity, systems are more and more distributed and fast-paced development leads to an ecosystem full of fragile legacy systems that provide the backbone of business capabilities. How do we tackle that technical and social complexity? Do we take the usual route and solve it by adding more tech or AI? Or is there another way?

Even in the 80’s, people realized that the theory of a system can’t be transferred through code and documentation alone. It requires developers to work closely together. We need to encourage human collaboration across disciplines, backgrounds and personalities (including our new AI buddies). Learn how you can use your human power skills to better understand the problems you’re facing and build systems that last!

Transcript

1. Nico Krijnen The Human side of Coding
3. Legacy Systems Rule the World
4. When is code "Legacy"? • Missing tests • Code you got from somebody else • Code that you're scared of • It still makes the business loads of money
5. How does code become "Legacy"? Knowledge "left the company"
7. Causes of Developer Turnover Sources: Stack Overflow Developer Survey 2022–23; Atlassian Developer Experience Report 2024; Storyblok Dev Survey 2023; Dice Tech Career Survey 2023; Work Institute Retention Report 2022; Gallup State of the Global Workplace 2023; DDI Retention Report 2019.
8. Causes of Developer Turnover Sources: Stack Overflow Developer Survey 2022–23; Atlassian Developer Experience Report 2024; Storyblok Dev Survey 2023; Dice Tech Career Survey 2023; Work Institute Retention Report 2022; Gallup State of the Global Workplace 2023; DDI Retention Report 2019.
9. Causes of Developer Turnover Sources: Stack Overflow Developer Survey 2022–23; Atlassian Developer Experience Report 2024; Storyblok Dev Survey 2023; Dice Tech Career Survey 2023; Work Institute Retention Report 2022; Gallup State of the Global Workplace 2023; DDI Retention Report 2019.
10. Causes of Developer Turnover Sources: Stack Overflow Developer Survey 2022–23; Atlassian Developer Experience Report 2024; Storyblok Dev Survey 2023; Dice Tech Career Survey 2023; Work Institute Retention Report 2022; Gallup State of the Global Workplace 2023; DDI Retention Report 2019.
11. Causes of Developer Turnover Sources: Stack Overflow Developer Survey 2022–23; Atlassian Developer Experience Report 2024; Storyblok Dev Survey 2023; Dice Tech Career Survey 2023; Work Institute Retention Report 2022; Gallup State of the Global Workplace 2023; DDI Retention Report 2019. 😬
12. ...
13. Nico Krijnen
17. Jack Jansen and Jennifer Steiner in prefab of fi ces Lambert Meert fi
18. ble of fi ce Paul Vitanyi in vertically mobile of fi ce
21. ABC
22. ABC
23. ABC
24. ABC AI
25. The Human side of Coding
26. What is code?
27. Code = map 🌍 to 🖥
28. Code = map 🌍 to 🖥 Result: programs / software
29. Value of software
30. Value of software Flexible
31. Value of software Flexible 🌍 changes = 🖥 changes
32. Programming
33. What is programming? "Activity of forming theory of matters at hand" – Peter Naur, Programming as Theory Building, 1985
34. What is programming? Program != Fully captured by it's source code
35. What is programming? Program != Fully captured by it's source code True essence = Theory constructed by programmers The mental model of how it works, why it was designed that way and how it fits in its intended domain.
36. Contrast with Formalist approaches Dominant view in 1970s–80s on programming theory: • Programs are mathematical objects. 𝑓 • Correctness comes from formal specifications and proofs. 📃 • The programmer’s role is to implement specifications faithfully, ideally in a way that can be mathematically verified. 👍 LGTM • Human understanding is secondary to formal reasoning. 🧐
37. Result: Production view Input = Requirements & Observing real world Programmers = Replacable "machines" Output = Code & Docs 🏭
38. Naur’s view (“Programming as Theory Building”) • Programs are human constructions. • The essence of programming lies in the mental theory programmers hold, not just in formal documents. • Specifications and proofs may help, but they are incomplete unless tied to programmer understanding. • Human understanding is central — code and documents are secondary artifacts.
39. Programming as Theory Building Input = Observing real world, situational experience Programmers = Build a mental theory Output = Theory: mapping between real world & code Code = Side-product
40. 🏭
41. 🏭
48. 🏭
49. Solution: Put the "Theory" into written documentation
50. Solution: Except: you can't... Put the "Theory" into written documentation
51. Tacit Knowledge Explicit Knowledge Definition Personal, experiential know-how that’s hard to articulate. Formal, documented knowledge that can be written down, codified, or stored. How it’s gained Through practice, intuition, trial-and-error, observation. Through reading, lectures, databases, manuals. How it’s shared Mentoring, storytelling, shadowing, demonstration, practice. Books, reports, procedures, checklists, training materials. Examples Riding a bike, a chef’s “feel” for seasoning, a leader’s intuition in a crisis. Recipes, standard operating procedures (SOPs), user manuals, financial reports. Transfer difficulty Hard to capture in words; usually requires personal interaction. Relatively easy—just copy, store, or transmit the written or digital record. Value Enables creativity, innovation, and expert judgment. Provides structure, consistency, and scalability.
52. Tacit Knowledge Explicit Knowledge Definition Personal, experiential know-how that’s hard to articulate. Formal, documented knowledge that can be written down, codified, or stored. How it’s gained Through practice, intuition, trial-and-error, observation. Through reading, lectures, databases, manuals. How it’s shared Mentoring, storytelling, shadowing, demonstration, practice. Books, reports, procedures, checklists, training materials. Examples Riding a bike, a chef’s “feel” for seasoning, a leader’s intuition in a crisis. Recipes, standard operating procedures (SOPs), user manuals, financial reports. Transfer difficulty Hard to capture in words; usually requires personal interaction. Relatively easy—just copy, store, or transmit the written or digital record. Value Enables creativity, innovation, and expert judgment. Provides structure, consistency, and scalability. Code Docs Tests Theory
53. Tacit Knowledge Explicit Knowledge Definition Personal, experiential know-how that’s hard to articulate. Formal, documented knowledge that can be written down, codified, or stored. How it’s gained Through practice, intuition, trial-and-error, observation. Through reading, lectures, databases, manuals. How it’s shared Mentoring, storytelling, shadowing, demonstration, practice. Books, reports, procedures, checklists, training materials. Examples Riding a bike, a chef’s “feel” for seasoning, a leader’s intuition in a crisis. Recipes, standard operating procedures (SOPs), user manuals, financial reports. Transfer difficulty Hard to capture in words; usually requires personal interaction. Relatively easy—just copy, store, or transmit the written or digital record. Value Enables creativity, innovation, and expert judgment. Provides structure, consistency, and scalability. Theory Code "the art" of doing something Docs Tests "the instructions" for doing something
54. "the art" of doing something Is not something you can write down!
56. The Situation Today
57. Today's programming practice mixes both Adopted from formalism: • Specs, contracts, testing though less mathematical than envisioned • Emphasis on rigorous tools and processes static analysis, type systems, automated testing, CI/CD pipelines Adopted from Naur: • Recognition that human and social factors are critical Agile, DevOps, Domain Driven Design, Sociotechnical engineering, pair programming, code reviews • Documentation is seen as secondary to "working software and team communication"
58. Today's programming practice mixes both Adopted from formalism: • Specs, contracts, testing though less mathematical than envisioned • Emphasis on rigorous tools and processes static analysis, type systems, automated testing, CI/CD pipelines Adopted from Naur: • Recognition that human and social factors are critical Agile, DevOps, Domain Driven Design, Sociotechnical engineering, pair programming, code reviews • Documentation is seen as secondary to "working software and team communication" Not too bad, right?! 😀
59. Let's diagnose current industry approach
60. Tacit Knowledge Loss •Teams underestimate theory in developers’ heads 🧐 •Staff turnover leads to “orphaned systems” no one fully understands 🙄🤔 •Documentation and knowledge transfer are often inadequate 📑 ↔ Let's diagnose current industry approach 💭 ?
61. Over-Reliance on Tools •Many companies lean on tests, CI/CD, or AI-assisted tools as if they can replace deep understanding. •These tools catch defects but don’t preserve theory. Let's diagnose current industry approach 🛠
62. Short-Termism • Agile and DevOps encourage responsiveness but often at the cost of long- term theory preservation. • Teams optimize for speed and delivery, neglecting the deeper shared understanding of the system. Let's diagnose current industry approach 🌊 🚤
63. Let's diagnose current industry approach "Having only one computer around had some good social effects: there was also a single terminal room, where everyone went who did anything with computers. As a result you got to know every computer user well, and there were lots of discussions and exchange of information." – Steven Pemberton Underestimating the effect of physical organization
64. Let's diagnose current industry approach Underestimating the effect of physical organization
65. Remote Work Challenges • The shift to remote- fi rst collaboration has made informal, tacit transfer of theory even harder. • Hallway conversations and pair debugging sessions — where much of the tacit knowledge used to spread — are reduced or lost. • Remote tools (chat, video calls, collaborative docs) enable productivity, but rarely capture or transmit the deeper, context-rich understanding needed to sustain a shared theory. Let's diagnose current industry approach 👨💻 👩💻 🧑💻
66. Formalist dream (1970s) Correctness lives in math. Naur’s insight (1985) Correctness lives in people’s heads. Industry today (2020s) Correctness lives in a hybrid of people + tools, but tacit knowledge gaps remain.
67. Damn! So we're doomed!?
68. No! We can fix this! Right?
69. Catch & Spread Preserve Mental Theory
70. 1. Distribute Theory across the team 2. Capture the Theory continuously 3. Incorporate Theory into tests 4. Preserve Theory through tools 5. Promote Theory building Catch & Spread
71. Catch & Spread 1. Distribute Theory across the team 2. Capture the Theory continuously 3. Incorporate Theory into tests 4. Preserve Theory through tools 5. Promote Theory building Avoid knowledge silos by adopting practices like: • Pair/Mob programming & Collaborative modelling (theory transfer through collaboration) • Rotate code ownership to touch different modules or use "Code rub" • Internal tech talks – "how this works and why"
74. Catch & Spread 1. Distribute Theory across the team 2. Capture the Theory continuously 3. Incorporate Theory into tests 4. Preserve Theory through tools 5. Promote Theory building • Use living docs • ADRs • Design rationale in PRs • Domain-driven design glossaries • Record why decisions are made, not just what was coded. • Think "products", not "projects".
75. <issue|type>: <title|summary|what> <description|why> # Description should answer: # Why are the changes necessary? # How do changes address the issue? # Why have I made these changes? # What effect have my changes made? # What side effects do the changes have? # What are the changes in reference to? “When a programmer first creates his code, only he and God know how it works, a few months down the line and only God knows.” https://www.szalimben.com.py/blog/english/posts/write-git-commit-message/ git commit message
76. “You’re reminded every time you open up your IDE, it invites you to create a new project. The vocabulary is deep.” https://www.youtube.com/watch?v=MdWH9lbgEws
77. Catch & Spread 1. Distribute Theory across the team 2. Capture the Theory continuously 3. Incorporate Theory into tests 4. Preserve Theory through tools 5. Promote Theory building Make tests not only check for correctness but also reflect programmer intent. • Example: well-named test suites explains theory of use cases. • High-level acceptance tests as executable documentation of system behavior.
79. Catch & Spread 1. Distribute Theory across the team 2. Capture the Theory continuously 3. Incorporate Theory into tests 4. Preserve Theory through tools 5. Promote Theory building Use tools as memory aids: • Code reviews with decision discussions preserved. • Architecture diagrams that auto- update from code. • AI-assisted summarizers to extract “theory fragments” from commits, tickets, or chat discussions.
80. Catch & Spread 1. Distribute Theory across the team 2. Capture the Theory continuously 3. Incorporate Theory into tests 4. Preserve Theory through tools 5. Promote Theory building Treat knowledge continuity as seriously as uptime or security. • “Theory onboarding” sessions for new hires (walkthroughs of how the system really works). • Knowledge debt tracked alongside tech debt. • Incentives for knowledge sharing in performance reviews.
81. You get what you measure! Do measure: • Hours mob or paired • Bus factor • Psychological Safety Do not measure: • Knowledge contributions per Employee (docs, wiki, posts) = explicit knowledge, not tacit!
82. % of coding hours spent in pair or mob programming Protect against single points of failure & ensure tacit knowledge spreads beyond “the expert.” Tacit knowledge is shared most effectively when engineers see each other think in real time. % of critical systems where >1 engineers can handle incidents, releases, or major changes Monthly or quarterly survey with 2–3 focused questions Safe, learning-oriented culture forms foundation for tacit knowledge flow.
83. ✨ The Vison Today: code and tools are treated as the source of truth. Tomorrow: the source of truth is recognized as a shared, evolving theory, and code is just its executable expression. Companies that adopt this mindset will likely build software that allows faster innovation and is more resilient, maintainable, and humane.
84. ✨ The Vison 🍻 No more Legacy Systems 🥳 🏎 Faster Innovation 🧪✨
85. Can AI assist to Preserve Theory?
86. AI assisting to Preserving Theory • Capture knowledge automatically • Extract knowledge from artifacts • Knowledge-aware onboarding • Surface gaps in knowledge • Amplify knowledge sharing
87. ⚠ Risks, Limits & Dangers • False confidence • Context loss • Over-automation Teams might mistake AI-generated summaries for “the real theory”. AI can’t fully capture tacit, evolving human understanding. AI can remix artifacts but may miss domain nuance unless continuously fed updated human input. If teams rely too much on AI, they might undervalue direct knowledge transfer — the very social practice Naur says is central.
88. ⚠ Risks, Limits & Dangers • False confidence • Context loss • Over-automation Teams might mistake AI-generated summaries for “the real theory”. AI can’t fully capture tacit, evolving human understanding. AI can remix artifacts but may miss domain nuance unless continuously fed updated human input. If teams rely too much on AI, they might undervalue direct knowledge transfer — the very social practice Naur says is central. Hmm 🤔
89. AI as co-worker on the team • A team-mate that never leaves • That retains theory
90. AI as co-worker on the team What AI is good at ✅ • digesting, indexing, and summarizing artifacts: code, docs, tickets, PRs (explicit representations of knowledge) • generate intellectual scaffolding: structured documentation, cross-references, diagrams.
91. AI as co-worker on the team What AI struggles with 🫤 • Tacit, embodied competence “I know this hack works because last time we hit a race condition under load,” or “this module is fragile, so don’t touch X without checking Y.” These judgments live in lived practice, not just artifacts.
92. The human parallel
93. The human parallel Think of a junior developer: • They read docs (sometimes). • But they really learn by pairing, making mistakes, fixing bugs, asking questions, living through incidents. • Over time, they develop a feel for the system: a lived theory.
94. The human parallel For AI to match that, it needs a developmental trajectory: Experience → feedback → adaptation → social learning → intuition-like heuristics.
95. The human parallel Today’s LLMs don’t really “try” things and live with the consequences. They predict text. 🤖
96. The human parallel Future AI would need: • safe sandboxes where it can make mistakes, • see consequences, • and refine its approach. This echoes reinforcement learning & AI agents but at the scale of real systems and over long horizons. 🤖 ✨
97. 🛠🤖
98. 🛠🤖 😴
99. 🛠🤖 😴
100. The Human side of Coding
102. Today's workplace Remote work isolates developers, destroys hallway conversations
103. Value of software Flexible 🌍 changes = 🖥 changes
104. What is programming? Program != Fully captured by it's source code True essence = Theory constructed by programmers The mental model of how it works, why it was designed that way and how it fits in its intended domain.
106. Nico Krijnen The Human side of Coding