The Dunning-Kruger Effect is Autocorrelation

This article is fascinating. The argument is that the well-known Dunnign-Kruger effect (i.e. unskilled people overestimate their skill), is not a psychological effect. Rather, it is a statistical mistake. It is an artifact of autocorrelation: Comparing a variable to itself.

Refactoring Ruby with Monads

Tom Stuart is a great, clear writer. This article does a great job at introducing the usefulness of monads – explaining them from the ground up, without the math pretentiousness.

Ruby Shell-Out Flow Chart

Ruby supports many ways of doing that. This excellent flow-chart from a StackOverflow answer tells you which one to use. I am reposting mainly so that I can find it again easily!

I maintain a series of small unix scripts to make my daily usage more effective. I approach the development of these utilities like I do my other software: Use Outside-In Test-Driven Development. I use rspec to write my tests, even if the code itself is written in bash, zsh, or ruby. Let’s see a few examples.

Testing Output

Some of my utilities are similar to pure functions: They always return the same output given for the same input, and they don’t have side-effects (i.e. they don’t change anything else in the system).

One of my most often used utility is jira_ticket_number. Given a string, it extracts the Jira ticket number from it. I typically don’t call it directly, but use it in other scripts. In my typical workflow, I’ll create a branch for a ticket I am working in, and include the ticket number in the name (e.g. ys/CF-8176_rework_request_sweeper). This is useful in a few ways. I use it in another utility jira, to construct and open a URL to the ticket. This saves me several clicks. I also use it to prepend new commit messages with the ticket number automatically when using git, via a custom prepare-commit-msg hook.

The specs for jira_ticket_number:

One Way Smart Developers Make Bad Strategic Decisions

So now, when I hear about top-down standardization efforts, I get a little worried because I know that trying to generalize across many problems is a fraught endeavor. What’s better is getting to know a specific problem by working collaboratively and embedding with the people who have the most tacit knowledge of the problem. Standardization and top-down edicts fail when they miss or ignore the implicit understandings of people close to the problem

Hints for writing Unix tools

General good advice on how to design unix tools. I summarize it as: “Design your unix tools to be composable”.

The Code Review Pyramid

The graphic speaks for itself: Spend more time in the bottom, than at the top. Automate what is possible.

HTML powers the web, in great part by providing a way to link to other content. Every website maintainer dreads having broken links: Those that when followed result in a document that is no longer there.

I remember that when I first learned to hand-write HTML (yes, last century) I used a Windows utility called Xenu’s Link Sleuth. It allowed me to check my site for broken links. I don’t use Windows anymore, but wget turns out to have everything I need.

Based on an article by Digital Ocean, I created a script that checks for broken internal¹ links:

#!/usr/bin/env bash
# Finds broken links for a site
#
# Usage
# find_broken_links http://localhost:3000

! wget --spider --recursive --no-directories --no-verbose $1 2>&1 | grep -B1 -E '(broken link!|failed:)'

It uses wget to spider (or crawl) a given URL and recursively check all links. All output is redirected and filtered to print only the broken links or other failures. The ! before the invocation inverts the process output: grep typically returns a non-zero (error) code if there is no output, but in this case we consider that a success.

Running against this blog found 3 broken links!

Now, my Makefile has a test target:

test:
  find_broken_links http://127.0.0.1:4000

I run it before every deployment (including posting this very post), to ensure I have not introduced bad link :-)

What do you really get from IDE-driven development?

The author reflects on why development with an IDE is not that useful. In effect, it creates a local maximum that can trap you into thinking it’s a global maximum.

In effect, as my friend experienced in his coding class, these sorts of things don’t make better programs and don’t make us better programmers. We end up knowing less than we should and get less than we deserve.

I’ve never warmed to IDEs myself. I’ve typically found them too constraining and wanting to take over all of my development workflow at once: How I setup my project, how I declare dependencies, how I setup my tests, how I compile my code. It feels like an all or nothing affair. I’ve long¹ preferred a programmer’s editor: Syntax highlighting, code navigation, and the ability to automate when I want it.

That Wild Ask A Manager Story

This article references a story that was new to me: The person interviewed is not the same person that shows up for work. This author’s takeaway is interesting. Instead of overreacting, he would do nothing:

The premise here is simple: designing a human process around pathological cases leads to processes that are themselves pathological.