A couple years ago when I heard a Radiolab podcast episode about a computer programming tournament, I thought I would try to reproduce in code a framework similar to the one devised by Robert Alexrod back in 1980. The premise revolved around the Prisoner’s Dilemma, an example in game theory that explores the rewards of selfishness.

In a nutshell, “play” revolves around two criminals who are in police custody. They are separated for questioning, and as any CSI junkie knows, the detectives will pressure each prisoner to rat the other out. Here’s a little truth-table summary of the game’s consequences:


This post is just a quick recap of how to do the cron-like task of executing code on a periodic basis in Elixir. In other languages, you might implement this using a sleep function, but behold this warning from ye olde Elixir docs:

For almost all situations where you would use sleep/1 in Elixir, there is likely a more correct, faster and precise way of achieving the same with message passing.

Like vampires, Elixir never sleeps! Remember what Joe Armstrong said of Erlang (Elixir’s engine): “write once, run forever.” In this case, we can do our message passing via Process.send_after/4.


My first program was written in BASIC on an IBM PC Jr and featured GOTO lines. Times were tough in the days when you used cartridges to load programs.

My first real programming job used Perl (and vim as our IDE), and after that played out, I started doing freelance web development and that meant writing a lot of PHP. Boatloads of it. Following that were professional stints with Python, Node, and Ruby. I was able to bounce between these languages pretty easily because all of them felt the same and the web frameworks mostly had the same basic pieces…


It always boggles my mind when smart developers pour hours and hours of their brilliant experience into coding an open-source package, and then they completely drop the ball when it comes to the delivery. From omitting installation instructions to the briefest of descriptions, packages that would otherwise be usable are instead dumped as veritable charity cases onto the unsuspecting community. Only the most amazing packages survive these types of lapses, so don’t let your hard work go to waste by failing to do these simple things!

  1. Include a README. Everyone who knows me knows that I am passionate about writing…


Hear me out: developers cannot and should not solve big problems. Every time they try to mastermind some brilliant solution to a complex quandary, the endeavor collapses, crushing the sanity of those poor souls who must interpret and maintain the code.

It’s like watching a toddler try to shove too much sandwich into their little mouths: most of it ends up on their face or on the floor and it’s left to the responsible adults to do the messy cleanup.

The thing that developers need to do very well is divide and conquer. They must be adept at breaking up…


The last article I wrote about Dotenvy didn’t leave much room for demonstrating specific use-cases. So in this article I wanted to take one on: using Dotenvy with Elixir releases.

When you create an Elixir release, you create a self-contained directory that consists of your application code, all of its dependencies, plus the whole Erlang Virtual Machine (VM) and runtime. Releases are frequently used when you are deploying production code to a server. The trick is ensuring that they can still read the configuration on the environment where they are running (and not from the environment where they were built).


Elixir makes it crazy easy to document your code. Documentation really is a first class citizen in Elixir-land: just add your @moduledoc or @doc blocks and you’re on your way. You can even test the examples in your documentation to verify that they are accurate: no bad examples allowed! Add the ex_doc package and then running mix docs will generate beautifully formatted HTML pages (or an epub eBook) all about your app. I have not once felt the need to scratch out some add-on readthedocs.org-esque solution when the native documentation was already so presentable.

Except for charts. Because OTP applications…


The last meandering text exchange I had with my father took a surreal turn when he interjected “there’s a tornado warning now. I can see it.” The thread went eerily silent, but after a tense hour, he sent me this photo:

Having grown up in the most tornado-prone county in the United States, I videotaped my first tornado on a bulky VHS camcorder for a Denver TV station when I was 12. In graduate school in Kansas, I photographed a twister for the Lawrence Journal World as it neared town, and I witnessed a handful of others left unphotographed from…


This is one of the phrases I find myself perpetually muttering because it is so patently true. I gained newfound respect for one of the titans of software development, Martin Fowler, when I rediscovered his famous quote:

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler

There are so many things about writing code that I wish someone had told me when I was coming up through the trenches. Maybe they tried, and maybe the words were lost on my youthful arrogance or my ears had not yet…


This is not a post about how you can make passive income as a developer while you sleep, or a listicle about the 10 best Python packages you simply must incorporate into your project to find dev-nirvana. This is just a fun little shout out to some old technology that lets you turn regular text into giant ASCII streams of text, like this:

This is cool the way that tractor-feed dot matrix printers were cool. It’s an homage to the nerds on whose shoulders we all stand. I like this kind of thing the same way some people like art…

Everett Griffiths

Code person.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store