Articles on Philosophy

Last updated: 2022/06/23

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.

What machines can and can't do

If you want a good intro to the article, open it up and read the first paragraph. All I'll say is that Ramkumar Ramachandra does an excellent job of exploring the limitations of machines, potentially dispelling fears that people might have about machines replacing us.

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".

Programming Style Influences

Not really a deep-dive, but I think it covers a subject that isn't much covered in programming. Laurence Tratt discusses how OpenBSD influenced his coding style and what people who write code have to gain from seeking out such influences.

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.

Chopping the monolith

Nicolas Fränkel philosophizes on the fact that most companies do micro-services wrong and proposes an approach to partially adopting them by splitting off parts of your monolith that are prone to frequent changes.

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.

There Was No Formal Methods Winter

Formal methods are a particular kind of mathematically rigorous techniques for the specification, development and verification of software. Basically software created using formal methods guarantees no bugs (although they can't guarantee some stray ionized particle won't flip a bit). Justin's article (in response to another one) highlights some of the limitations of formal methods that hindered their mass adoption industry, while underlining aspects that might be contributing to the growth of interest.

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.

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?).

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".

Tasks, lists, and promises

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


Want to see more in-depth content?

subscribe to my newsletter!

Other Articles