An 80 (non-whitespace) character limit is sensible because it improves source code readability.

A regular argument for a higher limit is that it is more modern. Our displays are bigger and the limit comes from punch cards where it made physical sense. But does that history make the limit bad? And does the available screen real estate change anything?

We read code more than we write it. For prose typography recommends line lengths of 40 to 80 (sometimes 100) characters. And that has not changed with modern display sizes since our eyes and brains have not changed. One can argue that code is not prose, but both want to be understood by humans. One major difference is that code uses a lot of whitespace for indentation. A (sensible) nesting level of 5 and a default tab width of 4 adds ~20 whitespace characters. This results in 60 to 100 (sometimes 120) characters. Ideally our tools would allow for that distinction. Sadly, they don’t. Nonetheless: 80 characters are in the sensible range.

Is our screen real estate thus wasted? No. Modern displays make it possible to read code side-by-side. For example to review diffs (e.g. git or pull requests) or to open two files together (e.g. implementation and test). With the standard font size of 12 pt two tabs in Visual Studio Code can show 156 characters. A more legible 16 pt reduces that to 118 characters. Another reason to keep the character limit sensible. Otherwise one has to start scrolling left and right to read everything. This makes it harder to understand because one can never see everything. Ideally all tools would be responsive and wrap lines at the edge of the viewport dynamically (like e.g. Xcode). Sadly, they don’t.

In summary: a limit of 80 non-whitespace characters makes sense. To account for indentation I recommend a limit between 80 and 120. Everything else makes your code harder to read and understand.

Please be aware that this is an easy topic to discuss ad nauseam. Often everybody has a (strong) opinion about it. If you ever discuss this longer than 15 minutes, you are likely bike-shedding. Choose a value - even a random one - and stick with it. That consistency will help readability more than the difference between 90 and 110.

Examples to illustrate the point:

RUN \
    --mount=type=cache,target=/var/cache/apk,sharing=locked \
    apk add \
        git \
        make

# vs.

RUN --mount=type=cache,target=/var/cache/apk,sharing=locked apk add git make

_logger.LogInformation("Client timestamp for {}: {}",
    connectionId,
    webSocketRequest.ClientTimestamp);

# vs.

_logger.LogInformation("Client timestamp for {}: {}", connectionId, webSocketRequest.ClientTimestamp);

return map.map(MappingNode::getValue)
		.map(List::stream)
		.orElse(Stream.empty())
		.filter(t -> {
			if (t.getKeyNode() instanceof ScalarNode keyNode
					&& key.equals(keyNode.getValue())) {
				return true;
			}
			return false;
		})
		.findFirst();

# vs.

return map.map(MappingNode::getValue).map(List::stream).orElse(Stream.empty()).filter(t -> {
			if (t.getKeyNode() instanceof ScalarNode keyNode && key.equals(keyNode.getValue())) {
				return true;
			}
			return false;
		}).findFirst();
</pre>

If you ever have to work with a (virtual) machine that has restricted internet access, you can use this little trick to use your local host as a SOCKS proxy during your SSH session. This requires the server to allow TCP forwarding.

ssh -R 60374 $hostname

export http_proxy=socks://localhost:60374/
export https_proxy=$http_proxy

curl https://example.com

I believe I found this this talk in the comment section of a Hacker News post. I first watched the 2014 version of it. Since then I found out that Christophe Pettus gives this talk yearly.

It’s a long talk, but he talks about almost everything there is to know about Postgres. For advanced stuff he gives just enough starting points for figuring it out yourself.

Watch out! The slides links in the video description don’t work. But you can find them on thebuild.com.

The talk is PostgreSQL Proficiency for Python People by Christoph Pettus.

RebelLabs by ZeroTurnaround (the company behind JRebel) does a yearly developer survey. And it is always accompanied by great write-ups. This time they wrote three blog posts:

• Part 1: Looking at the raw data
• Part 2: Pivoting the data: microservices usage, early vs. late adopters, and so on
• Part 3: Looking at trends and the historical data

I like these kind of reports since they give you a birds-eye view of the “vocal” community. “Vocal” community in the sense of people that fill out surveys. So always take these reports with a grain of salt. Use the trends as a guideline on what you should checkout rather than what you have to adopt.

You can also download the full RebelLabs Developer Productivity Report 2016 as a PDF.

Brad Frost says it how it is: Death to Bullshit. Be sure to turn the bullshit on and watch his talk.

Doug Seven tells a cautionary tale on why deployments should be automated as much as reasonable.

I found this talk in a comment by larsiusprime in the comment section of a Hacker News post. Lis Pardi did a survey on whether people of certain age groups can identify icons that reference old objects such as the floppy disk. I found the data pretty interesting (majority can identify successfully) and her arguments that try to explain it are sound (context gives meaning).

The talk is In Defense of the Floppy Disk by Lis Pardi.

I can’t remember where I found Simon Menner’s talk on his Stasi project but it’s an interesting watch. Complete with pictures that spies have taken of each other and everything. The talk is What does Big Brother see, while he is watching? by Simon Menner.