The Human side of Coding @ AWS Community Day NL

Our tech stacks are exploding in complexity, even with all the higher level building blocks that we have at our disposal. How do we tackle that complexity? Do we take the usual route and solve it by adding more tech or AI? Or is there another route?

Even in the 80’s, people already realized that the theory of a system can’t be transferred through code and documentation alone. It requires developers to work closely together. Learn how you can use your human power skills to better understand the problems you’re facing and build systems that last!

Transcript

1. The Human side of Coding Nico Krijnen
3. Legacy Systems Rule the World
4. When is code "Legacy"? • Missing tests
5. When is code "Legacy"? • Missing tests • Code you got from somebody else
6. When is code "Legacy"? • Missing tests • Code you got from somebody else • Code that you're scared of
7. 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
8. How does code become "Legacy"?
9. How does code become "Legacy"? Knowledge "left the company"
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. 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.
13. 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.
14. 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.
15. 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. !
16. ...
17. Nico Krijnen
21. Jack Jansen and Jennifer Steiner in prefab offices Lambert Meert
22. Lambert Meertens in 'Smallest Office'
23. Steven Pemberton in stackable office
24. ble office Paul Vitanyi in vertically mobile office
27. ABC
28. ABC
29. ABC
30. The Human side of Coding
31. What is code?
32. Code = map " to #
33. Code = map " to # Result: programs / software
34. Value of software
35. Value of software Flexible
36. Value of software Flexible " changes = # changes
37. Hardware
38. Hardware Infrastructure
39. Cloud changes everything!
40. Infra = Flexible Infra = Code
41. Everything is Software! Infra = Flexible Infra = Code
42. Programming
43. What is programming? "Activity of forming theory of matters at hand" – Peter Naur, Programming as Theory Building, 1985
44. What is programming? Program != Fully captured by it's source code
45. 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.
46. 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. &
47. Result: Production view Input = Requirements & Observing real world Programmers = Replacable "machines" Output = Code & Docs '
48. 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.
49. 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
50. '
51. '
63. Solution: Put the "Theory" into written documentation
64. Solution: Except: you can't... Put the "Theory" into written documentation
65. 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.
66. 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
67. 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
68. "the art" of doing something
69. "the art" of doing something Is not something you can write down!
71. The Situation Today
72. 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"
73. 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?! (
74. Fundamental flaws in the current industry approach
75. 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 + ↔ Fundamental flaws in the current industry approach - ?
76. 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. Fundamental flaws in the current industry approach .
77. Scaling Problems • Large organizations scale software development by distributing work across many teams. • Naur would argue this fragments theory, understanding is spread thin, so “big picture” comprehension suffers. Fundamental flaws in the current industry approach / / / / / /
78. 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. Fundamental flaws in the current industry approach 1 0
79. Fundamental flaws in the 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
80. Fundamental flaws in the current industry approach Underestimating the effect of physical organization
81. Remote Work Challenges • The shift to remote-first 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. Fundamental flaws in the current industry approach 2 3 4
82. Fundamental flaws in the current industry approach Tacit Knowledge Loss Short-Termism Over-Reliance on Tools Scaling Problems Remote Work Challenges 5 '
83. 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.
84. Damn! So we're doomed!?
85. Maybe not...
86. A Framework for Preserving Programmer Theory 1. Capture the Theory continuously 2. Distribute Theory across the team 3. Incorporate Theory into tests 4. Preserve Theory through tools 5. Promote Theory building
87. A Framework for Preserving Programmer Theory 1. Capture the Theory continuously 2. Distribute Theory across the team 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".
88. <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
89. “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
90. A Framework for Preserving Programmer Theory 1. Capture the Theory continuously 2. Distribute Theory across the team 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"
92. A Framework for Preserving Programmer Theory 1. Capture the Theory continuously 2. Distribute Theory across the team 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.
94. A Framework for Preserving Programmer Theory 1. Capture the Theory continuously 2. Distribute Theory across the team 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.
95. A Framework for Preserving Programmer Theory 1. Capture the Theory continuously 2. Distribute Theory across the team 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.
96. 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!
97. % 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.
98. ✨ The Vison Today: code and tools are treated as the source of truth.
99. ✨ 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.
100. ✨ 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.
101. ✨ The Vison 7 No more Legacy Systems 8 9 Faster Innovation :✨
102. Can AI assist to Preserve Theory?
103. AI assisting to Preserving Theory • Capture knowledge automatically • Extract knowledge from artifacts • Knowledge-aware onboarding • Surface gaps in knowledge • Amplify knowledge sharing
104. ⚠ 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.
105. ⚠ 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 *
106. AI as co-worker on the team • A team-mate that never leaves • That retains theory
107. 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.
108. 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.
109. AI as co-worker on the team • Strengthen the “intellect” layer % By preserving and surfacing explicit knowledge better than humans alone can. • AI cannot generate “intelligence” by itself > It doesn’t build lived theories through engagement, trial, and adaptation in the same way humans do.
110. Practical consequence ⚠ Teams using AI thinking it can be the tacit competence, will fall into the same trap Naur warned against: confusing written artifacts with the living theory. ✅ But if you use AI as a memory aid: Help preserve rationales, surface context, reduce cost of transmitting knowledge. Use as a powerful ally in keeping the team’s tacit "Theory" alive.
111. The human parallel
112. 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.
113. The human parallel For AI to match that, it needs a developmental trajectory: Experience → feedback → adaptation → social learning → intuition-like heuristics.
114. The human parallel Today’s LLMs don’t really “try” things and live with the consequences. ?
115. The human parallel Today’s LLMs don’t really “try” things and live with the consequences. They predict text. ?
116. The human parallel Future AI would need: • safe sandboxes where it can make mistakes, • see consequences, • and refine its approach. This echoes reinforcement learning, but at the scale of real systems and over long horizons. ?
117. The human parallel Future AI would need: • safe sandboxes where it can make mistakes, • see consequences, • and refine its approach. This echoes reinforcement learning, but at the scale of real systems and over long horizons. ? ✨
118. .? @
119. The Human side of Coding
120. What did we cover... • Way too much "Legacy" and getting worse. • What is code & software and what is it's value. • What is programming. • What is tacit & explicit knowledge. • Fundamental flaws still present in current industry.
121. What did we cover... • How to preserve the tacit "Theory" living in the programmer minds of a team. • How AI can assist with that & it's limitations.
122. Key takeaways 1. Deep human understanding remains crucial to build lasting systems. 2. LLM's can help, but human collaboration and knowledge sharing remains critical 3. Action: introduce your knowledge continuity KPI
123. The Human side of Coding Deep human understanding + Human collaboration + Knowledge continuity
124. The Human side of Coding Deep human understanding + Human collaboration + Knowledge continuity Feedback