Link

A classic that deserves perennial review: Things You Should Never Do, Part I

They did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch.

As if source code rusted.

Christophe Pettus’ Software Development blog PostgreSQL When It’s Not Your Job

Useful site with information about using / administering Postgres.

Saw this great list on HN today: A Short 100-Question Diligence Checklist

Due diligence is ostensibly about an investor carefully checking out a potential investment in order to make sure everything is in order, but since investment theses already start with real-world data that leads to a thesis, the actual goal is a hostile cross-examination of your own thought process.

37signals posted their Guide to Internal Communication, which is a short and pithy read.

Writing solidifies, chat dissolves. Substantial decisions start and end with an exchange of complete thoughts, not one-line-at-a-time jousts. If it’s important, critical, or fundamental, write it up, don’t chat it down.

A revist of the 12-factor app after a few years. One persons take.

12 Factor App Revisited

I’ve become convinced that “little languages” — small languages designed to solve very specific problems — are the future of programming, particularly after reading Gabriella Gonzalez’s “The end of history for programming” and watching Alan Kay’s “Programming and Scaling” talk.

Little Languages Are The Future Of Programming

This page is a living collection of summaries, signposts, and advice for these broader points that made my journey with C and other compiled languages easier.

Everything I Wish I Knew When Learning C

This is the foundational Go style guide at Google.

The Go Style Guide and accompanying documents codify the current best approaches for writing readable and idiomatic Go.

Go Style | Styleguide

A useful collection of bit manipulation techniques and hacks.

Bit Twiddling Hacks

Mike Acton’s Expectations Of Professional Software Engineers - Adam Johnson

In a 2019 talk/rant titled “Everyone Watching This Is Fired”, games industry veteran Mike Acton rattled off a sample of 50 things he expects of developers he works with. The title refers to his tongue-in-cheek suggestion that anyone who doesn’t meet all these requirements would be immediately fired.

Although his sense of humour isn’t for everyone, the suggestions are valuable. The list forms a baseline for software engineers to compare themselves against, and it’s not very specific to the games industry.

Adam Johnson make a textual version of the suggestions in the talk, and provided it for reference.

A fantastic resource of Old Maps Online, where you can find and browse many old maps.

This is a classic; I regularly return to this post for a refresher.

How To Write A Git Commit Message

But a well-cared for log is a beautiful and useful thing. git blame, revert, rebase, log, shortlog and other subcommands come to life. Reviewing others’ commits and pull requests becomes something worth doing, and suddenly can be done independently. Understanding why something happened months or years ago becomes not only possible but efficient.

The Consilience Project posted an informative article; can honest communication survive the culture wars?

The situation has degraded to the point where it is widely believed that calls to good faith (such as this paper) are themselves acts of bad faith, undertaken only by those interested in controlling the discourse. Calls for good faith communication are understood at best as naive requests to calm the outrage and conflict that now runs rife in political discourse. Both ends of the political spectrum (the far left and the far right) express this view. Both sides believe that “the other side” simply can’t be trusted and therefore cannot be engaged in good faith. To do so would be to fall into a trap, serving only to validate the dangerous views of groups known to be acting in bad faith.

Venkatesh Rao, of ribbonfarm.com, wrote about the idea of states and large organizations frequently imposing “order” on pre-existing chaotic systems, in an effort to improve legibility.

His primary source is the book Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed, in which the author, James C. Scott, describes some major social engineering ventures in history that have failed spectacularly.

An oldie, but goodie. This came up in discussion today, and wanted to link it for future reference.

If your project contains multiple packages you may find you have some exported symbols which are intended to be used by other packages in your project, but are not intended to be part of your project’s public API. Although Go has limited visibility modifiers – public, exported, symbols and private, non exported, symbols – internal packages provide a useful mechanism for controlling visibility to parts of your project which would otherwise be considered part of its public versioned API.

Interesting take by Kieran Potts on the ongoing REST discussion.

So, we should not abandon the term REST altogether, but as an adjective for API it just doesn’t make a whole lot of sense. Even in the context of the ongoing efforts to realise truly RESTful APIs, hypermedia is a better, more expressive classification.

This document is a set of guidelines for using C++ well. The aim of this document is to help people to use modern C++ effectively. By “modern C++” we mean effective use of the ISO C++ standard (currently C++20, but almost all of our recommendations also apply to C++17, C++14 and C++11).

C++ Core Guidelines

I regularly read what Shane Parrish has to say on his site “Farnam Street”.

In this post he coalesces a lot of content he’s provided about mental models, into one resource.

This guide explores everything you need to know about mental models. By the time you’re done, you’ll think better, make fewer mistakes, and get better results.

Farnam Street: Mental Models