Articles on Philosophy

Last updated: 2022/12/14

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

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.

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.

Why Functional Programming Should Be the Future of Software Development

Charles Scalfani discusses the difficulties that arise during the maintenance phase of software development, when shortcuts taken during development come back to bite programmers.
Some highlights:

  • The software industry's trajectory is towards increasing complexity, longer development times, and greater fragility of production systems
  • Functional programming could be part of the solution to these issues
  • Like any programming paradigm, it's ultimately just another tool in your toolkit and not the best fit for every job

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.

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.

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

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

ChatGPT Can Do Astonishing Things. But Is It a Helpful Development Tool?

Mattsi Jansky discusses some of the limitations of ChatGPT. I personally agree with his conclusion that it'll eventually become a tool used by people writing code to accelerate development, but will still require careful scrutiny. Now that I think of it, sounds like it could also have an application for helping newbies learn to review code.
Some highlights:

  • Has no access to internet (so no real-time data)
  • It usually produces incorrect or buggy code that requires careful scrutiny
  • It takes what you say literally and isn't great with context

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