
Essays on programming I think about a lot - jchook
https://www.benkuhn.net/progessays/
======
nordsieck
Sadly it's a video/presentation, not an essay, but Simple Made Easy[1] is the
single software argument that has made the most impact on me.

___

1\. [https://www.infoq.com/presentations/Simple-Made-
Easy/](https://www.infoq.com/presentations/Simple-Made-Easy/)

~~~
breckenedge
I’ve been programming for a long time, watched this presentation several
times, done a bunch of other research, and still don’t know if I understand
what this presentation is about. I fear that I’ve tried to apply these simple-
vs-complex principles and only made my code harder to understand. My
understanding now is that complexity for every application has to live
somewhere, that all the simple problems are already solved in some library (or
should be), and that customers invariably request solutions to problems that
require complexity by joining simple systems.

~~~
mac01021
> still don’t know if I understand what this presentation is about

1\. The simplicity of a system or product is not the same as the ease with
which it is built.

2\. Most developers, most of the time, default to optimizing for ease when
building a product even when it conflicts with simplicity

3\. Simplicity is a good proxy for reliability, maintainability, and
modifiability, so if you value those a lot then you should seek simplicity
over programmer convenience (in the cases where they are at odds).

~~~
mumblemumble
I find the graph at the top of Sandi Metz's article "Breaking up the Behemoth"
([https://sandimetz.com/blog/2017/9/13/breaking-up-the-
behemot...](https://sandimetz.com/blog/2017/9/13/breaking-up-the-behemoth)) to
be poignant.

If you agree with her hypothesis, what it's basically saying is that a clean
design tends to feel like _much_ more work early on. And she goes on to
suggest that early on, it's best to focus on ease, and extract a simpler
design later, when you have a clearer grasp of the problem domain.

Personally, if I disagree, it's because I think her axes are wrong. It's not
functionality vs. time, it's cumulative effort vs. functionality. Where that
distinction matters is that her graph subtly implies that you'll keep working
on the software at a more-or-less steady pace, indefinitely. This suggests
that there will always be a point where it's time to stop and work out a
simple design. If it's effort vs. functionality, on the other hand, that
leaves open the possibility that the project will be abandoned or put into
maintenance mode long before you hit that design payoff threshold.

(This would also imply that, as the maintainer of a programming language
ecosystem and a database product that are meant to be used over and over
again, Rich Hickey is looking at a different cost/benefit equation from those
of us who are working on a bunch of smaller, limited-domain tools. My own
hand-coded data structures are nowhere near as thoroughly engineered as
Clojure's collections API, nor should they be.)

------
sbuttgereit
I read Peter Naur's "Programming as Theory Building" and thought it quite
good.

[http://pages.cs.wisc.edu/~remzi/Naur.pdf](http://pages.cs.wisc.edu/~remzi/Naur.pdf)

At the time I found it I was was working where the key challenge was not so
much technical as much as ensuring that simple technology, spread across a
large breadth of functionality, adhered to a consistent vision of the business
domain that was being implemented. The program became an implementation of the
mental model I developed of the business domain itself: its purpose, its uses,
and its allowances and prohibitions. The Naur paper hit exactly not only on
what I had been implementing in code, but on what other developers would have
to know in order to maintain that code over time.... and had the kind of
knowledge that had been lost over the life of application by the time I came
to be involved.... and part of why my project existed.

~~~
hnick
The examples near the start reminded me of another piece shared here before,
"How to Build Good Software". Most notably the part near the end, titled
"Software Is about Developing Knowledge More than Writing Code".

[https://www.csc.gov.sg/articles/how-to-build-good-
software](https://www.csc.gov.sg/articles/how-to-build-good-software)

It has a few great quotes scattered throughout.

"Building good software involves alternating cycles of expanding and reducing
complexity."

"Software should be treated not as a static product, but as a living
manifestation of the development team's collective understanding."

"Software projects rarely fail because they are too small; they fail because
they get too big."

------
simonw
So glad to see the Law of Leaky Abstractions in there - that's had a very
long-running impact on how I think about programming. It's still super-
relevant today, nearly 18 years after it was published.

[https://www.joelonsoftware.com/2002/11/11/the-law-of-
leaky-a...](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-
abstractions/)

~~~
holografix
I’m going through the conversation with a colleague atm where he believes DRY
applies to everything.

~~~
twic
The Sandi Metz talk/post included in the list touches on that:

[https://sandimetz.com/blog/2016/1/20/the-wrong-
abstraction](https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction)

My takeaway from it is that we need to distinguish what you might call
essential from incidental duplication. Essential duplication is when two bits
of code are the same because they fundamentally have to be, and always will
be, whereas incidental duplication is when they happen to be the same at the
moment, but there's no reason for them to stay that way.

For example, calculating the total price for a shopping basket has to be the
same whether it's done on the cart page or the order confirmation page [1], so
don't duplicate that logic. Whereas applying a sales tax and applying a
discount might work the same way now, but won't once you start selling zero-
rated items, offering bulk discounts to which a coupon discount don't apply
etc.

[1] Although i once built a system where this was not the case! In theory, the
difference would always be that some additional discounts might be applied on
the confirmation page. In theory ...

~~~
greymalik
I don’t understand why people interpret that article as recommending you avoid
prematurely removing duplication and comparing it to the rule of 3. The point
of her essay is that you should resist the sunk cost fallacy and refactor your
duplication-removing abstractions when requirements (or your understanding of
them) change.

------
mhink
Love the list, but I definitely think Programming Sucks [1] should be on any
list of programming essays. :)

1: [https://www.stilldrinking.org/programming-
sucks](https://www.stilldrinking.org/programming-sucks)

~~~
mormegil
I guess I have read this already, but did not remember it very much. Halfway
through, I thought it was written by James Mickens. So, if you liked this, you
might also like Mickens' essays like The Night Watch
<[http://scholar.harvard.edu/files/mickens/files/thenightwatch...](http://scholar.harvard.edu/files/mickens/files/thenightwatch.pdf>).
All should be available at [https://mickens.seas.harvard.edu/wisdom-james-
mickens](https://mickens.seas.harvard.edu/wisdom-james-mickens) And they are
not only very funny, but also insightful.

------
vrnvu
Lately I've been into what I would call "the classics", Knuth, Peter Norvig,
Minsky, Dijkstra... I realised most of what nowadays is called modern
software/techniques basically consist in re-framing old essays from them.

Some of my references: the famous Norvig view on design patterns [1] and also
his view of clean code [2]. Knuth on programming [3] also really enlighting.

1\. [https://norvig.com/design-patterns/design-
patterns.pdf](https://norvig.com/design-patterns/design-patterns.pdf) 2\.
[https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-
style.pdf](https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf) 3\.
[http://www.paulgraham.com/knuth.html](http://www.paulgraham.com/knuth.html)

------
lactobacillis
Joe Armstrong's PhD thesis 'Making reliable distributed systems in the
presence of software errors' is good reading.

[http://erlang.org/download/armstrong_thesis_2003.pdf](http://erlang.org/download/armstrong_thesis_2003.pdf)

~~~
yawboakye
Definitely recommend. I recently bought a book on Amazon on distributed
systems[0] which talked about fault tolerance without even a cursory mention
of Joe Armstrong's work. I've returned the book, but I wish I could have
browsed the bibliography before buying.

[0]:
[https://www.amazon.com/dp/1543057381](https://www.amazon.com/dp/1543057381)

------
danielnixon
I think about 'Why it is Important that Software Projects Fail' a lot.

[https://www.berglas.org/Articles/ImportantThatSoftwareFails/...](https://www.berglas.org/Articles/ImportantThatSoftwareFails/ImportantThatSoftwareFails.html)

It's been posted a few times over the years:
[https://news.ycombinator.com/from?site=berglas.org](https://news.ycombinator.com/from?site=berglas.org)

------
zvrk
"Reflections on Trusting Trust" \-
[https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...](https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf)

~~~
jjice
The first time I read this, I had to read it a few times to really understand.
Great essay/lecture, but what else would one expect from Ken Thomposon?

------
zem
"slumming with basic programmers"
[https://prog21.dadgum.com/21.html](https://prog21.dadgum.com/21.html)

------
deathanatos
Arthur C. Clarke's _Hazards of Prophecy: The Failure of Imagination_ :
[https://fabiusmaximus.com/2017/12/27/arthur-c-clarke-
hazards...](https://fabiusmaximus.com/2017/12/27/arthur-c-clarke-hazards-of-
prophecy-lack-of-imagination/)

~~~
apabepa
I read it from your link. It was an interesting piece about innovation and
imagination versus lack of imagination.

------
_pmf_
I only think about "Out of the Tar Pit".

~~~
akkartik
I've never understood why people like this paper. Over the years I've evolved
a bite-sized rebuttal, if anybody wants to fight me:

The authors' "ideal world" is one where computation has no cost, but social
structures remain unchanged, with "users" having "requirements". But the users
are all mathematical enough to want formal requirements. The authors don’t
seem to notice that the arrow in "Informal requirements -> Formal
requirements" (pg 23) may indicate that formal requirements are themselves
accidental complexity. All this seems to illuminate the biases of the authors
more than the problem.

Link to the paper, for convenience:
[http://curtclifton.net/papers/MoseleyMarks06a.pdf](http://curtclifton.net/papers/MoseleyMarks06a.pdf).
I think it's a siren and takes away attention that could be spent on better
papers.

~~~
nordsieck
> But the users are all mathematical enough to want formal requirements.

This seems like a strange interpretation. I understand that the term "formal
requirements" has a technical meaning in some disciplines, but I also think
it's pretty clear that the author isn't using the term in that way.

It is much more likely that the author meant that users have requirements, but
those requirements don't typically map cleanly to actions taken by the
computer. This step of translation is necessary in the construction of a
program, even if it is typically done piecemeal and iteratively.

~~~
akkartik
It's a strange interpretation only if you focus on just the vocal minority
that talks about formal requirements. Here are two quotes by Hillel Wayne
([https://www.hillelwayne.com/post/why-dont-people-use-
formal-...](https://www.hillelwayne.com/post/why-dont-people-use-formal-
methods)), whom I've found to have the most balanced take:

"The problem with finding the right spec is more fundamental: _we often don’t
know what we want the spec to be_. We think of our requirements in human
terms, not mathematical terms. If I say “this should distinguish parks from
birds”, what am I saying? I could explain to a human by giving a bunch of
pictures of parks and birds, but that’s just specific examples, not capturing
the idea of distinguishing parks from birds. To actually translate that to a
formal spec requires us to be able to formalize human concepts, and that is a
serious challenge."

"It’s too expensive doing full verification in day-to-day programming. Instead
of proving that my sort function always sorts, I can at least prove it doesn’t
loop forever and never writes out of bounds. You can still get a lot of
benefit out of this."

The post makes a strong case, IMO. Formal methods can be valuable, but they
don't have the track record yet for anyone to believe they're the #1 essential
thing about programming.

------
loopz
One of the last links, but probably most significant:

Inventing on Principle
[https://vimeo.com/36579366](https://vimeo.com/36579366)

------
colecut
I saw the Inventing on Principal video several years ago and I’m very happy to
come across it again. Thanks for sharing!

------
codeDruid
As a less experienced web developer, i found "How I write backends"[1] very
enlightening and I recommend it to all my peers when we discuss useful
resources.

1\.
[https://github.com/fpereiro/backendlore](https://github.com/fpereiro/backendlore)

~~~
dewey
I just read it but I think it focuses too much on specific tools (Redis,
Node,...) and their configurations which might not be the best for most use
cases. Especially if it's for a beginner who maybe doesn't have to start out
with a load balancer and Redis.

------
napo
"If you choose to write your website in NodeJS, you just spent one of your
innovation tokens. If you choose to use MongoDB, you just spent one of your
innovation tokens. If you choose to use service discovery tech that’s existed
for a year or less, you just spent one of your innovation tokens." I think the
author is stuck in 2010.

~~~
mavelikara
The essay was written in early 2015, around the same time NodeJS foundation
was set up.

