Articles on Philosophy
Last updated: 2022/12/14
Top deep-dives on Philosophy
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.
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.
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.
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".
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.
Alex Ellis talks through the different approaches for visualizing code and underlines some available tooling one could use.
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.
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.
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.
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.
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.
Dan Lew discusses the different approaches one can take towards making sure the code that is written is "correct".
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.
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.
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.
Llorenç Muntaner explores Extended Backus-Narus Form, the language that describes the syntax rules of programming languages.
Xe Iaso starts a discourse by presenting some of the issues resulting from the modern devops philosophy.
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.
A new top-level syntax for programming languages is proposed by Alex Rogozhnikov to show advantages of this method.
- 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
Bob Rudis goes on a technical deep-dive of how to take care of your most important tool and piece of equipment, yourself.
Charles Scalfani discusses the difficulties that arise during the maintenance phase of software development, when shortcuts taken during development come back to bite programmers.
- 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
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.
Fred Hebert elaborates on errors in software engineering/site reliability, and the "human" factor in interpreting, understanding, and ultimately solving them.
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?".
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?).
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.
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.
- Models are easy to understand
- Models are cheaper to make
- Models need to be kept in sync with actual implementation
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.
Philippe M. Groarke philosophizes on "a different way to write templated C++ and type traits".
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.
- 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
Rachel Kroll describes a technical approach to task priority handling using a dependency graph with two examples.