Articles on Philosophy

Top deep-dives on Philosophy

On bad advice

Yeah it's mostly philosophy related to writing code and not super technical, but we really surround ourselves with a lot of philosophy when programming (design patterns, language patterns, architecture styles to name a few). In this insightful article, Jamie Brandon explores the validity of advice received over 12 years of working with code, and shares thoughts on observed patterns.

How Not to Teach Recursion

Recursion can be difficult to understand, and as a result of that, it is frequently misused or just flat out not used. That's a shame though, because it can be very useful for certain situations. The author of this article outlines some of the common functions used to teach recursion, why they're not very good lessons, and finally a better way to teach recursion, as recommended by How to Design Programs.

How We (Don’t) Reason About Code

It has been said that as programmers, we spend more time reading code than writing it. It reminds me of what my boss once told me when I was interning at an electrical engineering company, something along the lines of most good engineers ending up writing more than they end up doing actual engineering. Well Lucian Radu Teodorescu's article explores how we reason about code, by transforming a normally intuitive process into something mathematical.

Up and Down the Ladder of Abstraction

Full disclosure, this article is a decade old. However, I found its concepts were timeless, so figured no harm in featuring it. Bret Victor's exceptionally interactive article "presents the ladder of abstraction, a technique for thinking explicitly about [different levels of abstraction], so a designer can move among them consciously and confidently".

Moving faster

More of a philosophical/self-help piece that looks at improving your programming abilities. Jamie Brandon describes some of the methods he uses to speed up his process for writing code. Specifically, Jamie covers how to make decisions, improve focus, batching, making small changes, shortening feedback loops, writing stuff down, reducing frequent mistakes, making low level skills automatic, and reflecting.

How do you visualize code?

Alex Ellis talks through the different approaches for visualizing code and underlines some available tooling one could use.

What is a Programming Paradigm?

This is more of a philosophical article, where Jonathan Goodwin explores the nuances of what a programming paradigm is, very much in a Theory of Knowledge-esque essay for anyone who did the IB. Jonathan first looks at the "unhelpful" Wikipedia definition, then Thomas Kuhn's, ultimately ending with an analysis of George Floyd thought and the relevance of both opinions in the 21st century.

Practising Programming

This article kind of resonated with me, because it's kind of how I do things. Laurence Tratt discusses his approach to practicing programming by implementing real life applications in different languages or using different tools.

Free Software is an Abject Failure

This could probably be considered a controversial piece, but if I wasn't exposing you to different perspectives and ideas, I wouldn't be meeting the expectations of this newsletter. Jake Bauer's article explores how free software (not to be confused with open source software) is ultimately a failed ideology and culture. Jake also picks apart the GPL and free software's relevancy.

Measuring Technical Debt

Sean Mack takes a thorough look at technical debt; its history, the different forms it comes in, and ultimately how it can be measured/calculated.

Maintaining Software Correctness

Dan Lew discusses the different approaches one can take towards making sure the code that is written is "correct".

Practical frontend philosophy

I constantly hear about frontend engineers getting a bunch of crap for not being "real" programmers. As a non-frontend guy who has dabbled extensively in the field, that sounds like a bunch of BS to me. In this philosophical article, Jared Gorski explores some of the diffiiculties of frontend engineering and building human-data interfaces. Although I don't agree with all of his points (I don't think backend is often obvious), Jared highlights a couple of important points in regards to the difficulties of making data palpable for humans.

Overengineering can kill your product

When you're developing a product, you might be inclined to add features or extra code to handle things in the future. You might spend a lot of time doing it, only to find out later that you're not even going to use it, because your users don't want to use it. Simón Muñoz's article illuminates this issue and the general problem of overengineering, going through the what, why, and how to avoid it.

EBNF As a Mental Model to Learn Programming Languages

Llorenç Muntaner explores Extended Backus-Narus Form, the language that describes the syntax rules of programming languages.

Technical Solutions Poorly Solve Social Problems

Xe Iaso starts a discourse by presenting some of the issues resulting from the modern devops philosophy.

Delimiter-first code

A new top-level syntax for programming languages is proposed by Alex Rogozhnikov to show advantages of this method.
Some highlights:

• Write all code with the delimiter first
• New syntax is arguably as simple, but more consistent, better preserves visual structure and solves some issues in code formatting
• Exploring new ideas like this is helpful for the evolution of programming language design

Escaping Groundhog Day

Bob Rudis goes on a technical deep-dive of how to take care of your most important tool and piece of equipment, yourself.

On Variance and Extensibility

When I write code for any nontrivial system, it feels like I'm on tightrope for each new feature, balancing how long something takes and the extendability of the result. At the same time, there's a blindfolded user at the end, precariously swinging a cutlass around the connection to the platform, potentially cutting the feature at any moment. Well this article by Steven Wittens won't help you with that existential crisis, but he does analyze what makes a system extensible, using birds.

Errors are constructed, not discovered

Fred Hebert elaborates on errors in software engineering/site reliability, and the "human" factor in interpreting, understanding, and ultimately solving them.

The code quality pyramid

Fabian Zeindl discusses different ways to improve the quality of software systems. Fabian groups different qualities into a pyramid, with lower parts of the pyramid supporting the parts further up.
Some highlights:

• Keep the build graph simple by grouping related tasks together and eliminating unnecessary work
• Use a caching mechanism to avoid rebuilding the same thing multiple times
• Avoid installing dependencies multiple times by using a dependency manager

Interface ergonomics: automation isn't just about time saved

Although more philosophical in nature (it has code too though!), this article by Macoy Madson focuses on exploring an important question all programmers have to face; at what point should you automate a task? Macoy uses an example of having to keep the user interface responsive during a full system file scan to justify the use of macros with Cakelisp.

Why is it so hard to buy things that work well?

Dan Luu takes a stab at explaining why effective purchasing is so difficult, and how it relates to writing software for a business. I know, I know, doesn't sound super technical, but this piece struck a chord with me, especially when it comes to the decisions of "should I build this myself, or SaaS it up?".

Accumulation of tech debt; experiments and shortcuts are core components

Tim Cochran and Carl Nygard discuss why technical debt arises, how to keep track of it, and how to get rid of it. Not a technical deep-dive per se, but relevant to programming nonetheless. Unless you're some maniac who never has technical debt, in which case kudos (or maybe that's a problem too as highlighted by this article?).

Striped Development

Jordan Kaye discusses the idea of "striped development", which is an iterative approach to designing and implementing software. In this approach, work is organized into three repeating phases: design, striping, and implementation. The most important part of this strategy is that it is circular, meaning that the design phase is updated after each stripe is implemented. This allows for new information to be taken into account and for the design to be improved over time.

Why Lisp

Claude Roux describes some of reasons as to why someone would choose to use a Lisp language over more conventional C resembling alternatives. If you haven't attempted to learn a Lisp language yet, I'd really recommend it.
Some highlights:

• Lisp is homoiconic
• An advantage of Lisp is that there is no need to invent different programming styles to integrate new features
• Lisp is a way of representing and executing programs in an intermediate form between man and machine

The Case for Models

This article is about the benefits of using models to combat the complexity of software. Alex Weisberger argues that models are essential to software minimalism and that they offer a number of benefits, including simplifying testing and proofing.
Some highlights:

• Models are easy to understand
• Models are cheaper to make
• Models need to be kept in sync with actual implementation

Why am I not terrified of AI?

Scott Aaronson explains why he's not afraid of AI.
Some highlights:

• Compares it to bullying nerds and worse
• Exceptionally intelligent people generally aren't evil?
• This article is just philosophy on a technical topic (no code!)

Understanding the Law of Demeter

Caleb Hearth explains the "Law of Demeter", which "says that an object should not 'reach through' its collaborators to access their collaborators’ data, methods, or collaborators", using examples from Ruby.

Stack Machines and Where To Find Them

Tom Niget explains recursion and how it can be used to solve various programming tasks. Tom also talks about the disadvantages of recursion and how it can be inefficient.
Some highlights:

• Multiple programming languages used for examples
• Dives into how functions work from bottom up
• Implements a stack

Misspecification: The Blind Spot of Formal Verification

As humans, we're subject to believing in what people we admire or respect say, often times without taking a second to double check if said statement is true or "correct". This assumption of truth doesn't only extend to people. In this appeal-to-reason article, Alex Weisberger discusses and presents examples of how "this progam was formally verified, so please stop asking me if there are any bugs" doesn't really mean much when the initial specifications were wrong.

Data-Driven, Descriptor Based Generative C++

Philippe M. Groarke philosophizes on "a different way to write templated C++ and type traits".

Use Cases for Transparent Telemetry

In this series of articles, Russ Cox discusses why and how transparent telemetry can help improve open source software projects.
Some highlights:

• "Without telemetry, developers rely on bug reports and surveys to find out when their software isn’t working or how it is being used"
• Not having detailed information about how the software is being used makes it difficult for maintainers to implement essentials fixes/features
• Transparent telemetry collects as little as possible (kilobytes per year from each installation) and then publishes every bit that it collects, for public inspection and analysis

Tasks, lists, and promises

Rachel Kroll describes a technical approach to task priority handling using a dependency graph with two examples.