Crafting Code Podcast

~/podcast

$ cd episodes/020-the-humble-programmer

~/podcast/episodes/020-the-humble-programmer $ ls -1a
. .. episode-summary.txt get-mp3.sh
~/podcast/episodes $ cat episode-summary.txt

The works of Edsger W. Dijkstra have made a huge impact on the software industry. In this episode, your hosts dive into his paper, The Humble Programmer, to discuss how well it holds up to today's programming world. We cover hardware, cleverness, abstraction, proofs, and more. Even when we disagree with his specifics, we find ourselves still nodding in general agreement.

Timestamps

[00:00:00] Host introductions. A short introduction to Edsger W. Dijkstra.

[00:04:12] A brief summary of Dijkstra's paper.

[00:06:26] Hardware vs software expenses over time. Most developers no longer care much about specific instruction sets. "Giant" computers and the software crisis. Visible machines vs. invisible software.

[00:14:23] "Computer programmer" was not yet a profession. Changing software because machines changed vs. because the product needs change. The impact of technical decisions on business (and business decisions on technical: re-orgs).

[00:20:56] The mindset of programmers, then and now. Avoid clever tricks; save cleverness for understanding and solving a problem. Don't use clever tools or be clever in code.

[00:26:23] "Nicely factored" problems. Work on the problem until a simple solution falls out. Code is intended to communicate with other people, and cleverness is not good communication. You have to take apart the one-liners anyway.

[00:30:25] Abstraction. Is tying your shoes one thing or billions of interactions? Abstractions create concise & precise ways to communicate. Conceptual complexity & ubiquitous language. "Check out the basket."

[00:36:46] People systems and exponentially increasing lines of communication. What if you had to talk about bits stored on disk when you have 3 teams in a room? Messy code abstractions make it difficult both to code and to talk with the business stakeholders.

[00:40:59] The process of creation is messy (e.g. startups). Growing a proof of correctness. Discipline. The process can be messy; don't let your code also be messy. Matt's disciplines of TDD & REPL-driven-development.

[00:48:31] Proofs vs. testing. Natural variation in things like I/O make programs almost impossible to prove. Building confidence in the code. Automated tests may not always be worth investing in (but if you're not sure, write the tests).

[00:54:30] Better tools don't mean programming gets easier, because we try new and more difficult things. How can we keep our programs within our intellectual control? Wittgenstein and the limits of thought to express the inexpressible. Simplicity & complecting.

[01:00:07] Tuning a guitar E string. "Downtuning" your tools, then bringing them up to "just enough." Ian Malcolm quotes. Debugging after the fact.

[01:05:08] Progress in software development by accepting restrictions. What will be the next restriction? Go generics as a study in limiting complexity. Get rid of tools which are no longer useful / appropriate.

[01:08:07] Education teaser. Summary: be very humble programmers.

[01:09:14] Outro

References in this episode: ~/podcast $ cat copyright.txt

Copyright © 2024 - Crafting Code Podcast