If names are not correct, language will not be in accordance with the truth of things — Confucius (attributed)

Good names take effort[^1]. Bad names, eventually, take more effort. Good names help code look like (awkward) prose[^3] instead of mathematical formulas. Good names help readers focus on what the code is getting done rather than “WtF is this coding doing‽”. Good names reduce the need for comments or the readers to drill into the functions’ code[^4]

Think of a big pile of tools, materials, and supplies. To find anything, one has to dig through, on average, half the pile. It’s like one big function or script

Think of the same stuff in unlabeled drawers and boxes. One looks through boxes unnecessarily because the contents are not obvious from the boxes’ labels (or one does not understand or does not trust the labels)

Think of the same stuff in labeled boxes grouped by some...

TL;DR Programs must be written for people to read, and only incidentally for machines to execute —Harold Abelson

In the old days <eyeroll/>, we had 26 variables: the letters of the alphabet. The next leap in programming, we could add one digit after the letter. That was not good enough for development then, and it surely is not now

With no restriction on the length of names, the vestigial traditions of opaque naming cannot hide behind brevity or idiom, and certainly not consistency¹. The only measure for names is their utility in communication

A line of code like r.Get(true) is opaque. While IDEs can help decode what the r and the true mean, using descriptive names allows the code to speak for itself: orderReader.Get(CacheDataOk)

Multi-letter abbreviations harken back to Hungarian notation: abjad² type names prefixed or suffixed to a (presumably) descriptive name (e.g. submitBtn). Or...

TL;DR: A function must respect all arguments or return an error

The Arguments

The only realistic way a function can fail its interface is how it treats arguments as mis-typed arguments or return values are usually caught by a framework

All The Arguments

Be they required or optional arguments that are present, functions must respect all the arguments; they cannot ignore some because they are inconvenient or contradictory

“I’d like a number four with no cheese”

One cannot stop paying attention just because we know what a 4 is. Functions and especially REST endpoints often accept resource ids or primary key values, which implicitly identify specific resources. Tempting as this easy lookup is, the function must apply all the arguments even if they are additional criteria. With a key value in hand, the function does not need additional criteria, but it cannot ignore them

A function...

TL;DR

Cha-Cha-Changes

Breaking changes happen, and the breaking occurs between the layers (e.g. UI and API, API and database). Rather than trying to release new layers simultaneously (especially with edge distribution), commit the time and effort to a four or five-step pattern that ensures the layers work perfectly at all times, losing no data

1. Create the Change You Want To Be

Create the goal: the new schema; the new endpoint; the new protocol. Test it, benchmark it, and be happy with it. Copy and translate the old system’s data to the new system (handle the subsequent data changes in step 4)
For example, instead of changing the data type of a column, create a new column of the desired type

2. Embrace the New While Respecting the Old

The Problem With Data

It’s always the data

The transition depends on how the old and new systems share data

• Type A: if the clients are making...

One might use it like this:

var myCache = NewOurCache(0, calculateTimestamp)
// ...
var myValue time.Time = myCache.Open(dateText, timeText, Location)

OurCacheType is an alias for the actual data cached. It can be any type including a structure or pointer. composeKey() is an example how to consistently create a string key from whatever identifies the data. These parameters usually match the parameters of the createAValue function (if used)

Use the cache by Write() values if the Read() cannot find them, or you can use something like the Open() function, which returns the cached value if found in the cache or it generates the value (using the createAValue function), caches it, and returns it[^1]

[^1]: My naming convention is:
find("key") returns the value and a boolean (like aMap["key"])
get("key") excepts/panics if it cannot return the value
open("key") returns an existing instance or...

From Wikipedia:

The Single Responsibility Principle (SRP) is a computer programming idea: every module or class should have responsibility for a single functionality. All its services should be narrowly aligned with that responsibility. I leave the discussion about SRP in modules and classes to the plethora of sources addressing them

Yeah, But Every Line

Yes, every line should perform a single¹ task. Even if you are using Perl, every line should have one specific goal. Complex expressions are ¡very impressive¡, but such preening makes the code hard to understand². Breaking complex expressions and commands into informational variables and steps makes them easier to read³, easier to debug, and easier to refactor

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated...

Callbacks are great and always have been. Long ago, we didn’t know we were injecting control or inverting dependencies; we just used them. When closures appeared, I did not see a huge difference: a little state here, a little context there. I have found my Closures Killer App: remote cleanup

Here is an example in Go:

In the calling code (with dependencies on DataDog, Redis, etc.)

type cleanupSignature  func(aName, aType string) func()

cleanupFactory := func(aName, aType string) func() {
    if _, found := SpanFromContext(context); !found {
        span, _ := datadog.SpanFromContext(context, aName, aType)
        return func() {
            span.Finish()
        }
    } else {
        return func(){}
    }
}

baz := foo(cleanupFactory, bar)

// ...

In the called code (with no dependencies on context, DataDog, etc.)

func foo(cleanupFactory cleanupSignature, zap int) string {

Python holds a deep, dark secret: it can be as unpredictable as Ruby if we let it. Even with the new typing¹, the staggering flexibility of Python at runtime remains. We can change individual instances of classes to anything we want, and nothing can stop us

But It Would Be Wrong

The whole point of classes and instances is that they are predictable: every instance should act the same; every subclass should do the same things, perhaps in slightly different ways². Cleverly³ changing instance 47 to get around some restrictive class design might feel good, but it is a land-mine you planted waiting for the next developer to come along

Except

Except for testing. Testing less than end-to-end involves making some code think that it’s in the real world when it is not. Be it mocks,, stubs, composition, or references to services, tests need to simulate other code to simplify, isolate, and...

Software, at least traditionally, was made in layers and parts, and each part has its own domain and its own technology. Developers know multiple languages and multiple domains, i.e. their skills gained from training and experience, but no developer knows every language and domain, however inconvenient this is for managers, and therefore recruiters. A team would have members who brought different skills and experiences.
A recent innovation is the invention of the Full‑Stack Developer to get exactly the skills needed in one engineer

“Stack” is a description of technologies that interact with each other. Originally, the stack extended down to the operating system and the binary network protocol and the physical electronic connections, and now the most common range of the stack is the data store (e.g. Redis, SQL) to servers (e.g. APIs) using communications protocols (e.g. REST, Thrift...