When getting one’s code or wiki entry or blog post reviewed, if a reviewer asks a good question (e.g. what the code is doing or why the code does not follow the common conventions), don’t answer them directly The problem is not that they have a question; the problem is that your code or text is not clear

Don’t mansplain with comments, READMEs, or call-outs in documentation; improve it so it can clearly speak for itself. A comment can improve code if it explains why the code is not doing the obvious thing; otherwise, it is compensating for code and naming that will, once improved, not need comments

Comment only what the code cannot say – Kevlin Henney

Change the text or code so it is clearer: improve the nomenclature or break operations into separate functions; add a diagram to show what you mean; replace magic numbers and codes with constants. You will likely find bugs, missing cases...

In times of crisis, everyone just gets stuff done to keep the boat afloat and ship that one, promised feature. Young startups are constantly in crisis: pivoting, shucking and jiving, all hands on deck, working all night to get the demo up. They need heroes who can do anything and everything. They don’t have time to explain or document, and — since everything is changing anyway — “what’s the point?”

Some people thrive in a chaotic environment. It engages their complete concentration and creativity. They are praised and rewarded for how much they can do and, often, how much effort they put into doing it. They know where things break, what they look like when they break, and how to fix them (at least in the short term). They like the environment; it fits them, it finds them, it breeds them. They are heroes

A startup entering adolescence has these heroic veterans of the early battles. As...

source code,
like poetry,
is more than its words and symbols
(or the bytes they represent)

it has shapes that communicate
its intentions

While we might share Mr. Jourdain’s¹ delight, we should not ignore the shape of our code as well as its syntax. In deciphering code, others (or ourselves after a few weeks) can use the shape and flavour of code not merely as artistic or affected expressions, but as guides to its meaning. While rhyming, alliteration, and meter are usually not practical for source code itself, patterns, rhythms, and flow are

Patterns and rhythm are how the logical parts of code (e.g. functions) resemble each other, how they appear when arranged or nested (e.g. methods in a class), and how variations from these patterns are intentional and recognizable. Top-level code, often the public-interface functions² that begin the orchestration of all the specialized procedures...

1. It Really Wants To Be Modal

click-release-move instead of click-drag¹

The common click-drag idiom used everywhere else does not work well in SketchUp

Once you are in a mode (by selecting a tool and clicking on a starting point once), you can rotate and pan the view (camera) to find and select the points you want to synchronize with your clicked-point or enter a numeric length. Then, exit the mode by clicking once or pressing Enter for the number. Holding the left mouse button makes it harder and prevents some nice features (see Control the Axes below)

2. Use the Tape Measure and Guide-Lines Constantly

Guide-lines allow you to do what you want without fighting the model. If you want to show a dimension and you cannot find the points to connect, draw a guide exactly where you want (e.g. specify a length) and use the endpoints of the guide for your dimension²
When resizing or...

Languages have rules about how their words or signs fit together (syntax). They have patterns of how their words or signs tend to sound or look, how some elements are built out of others, and how poets break the rules to make things interesting. One can have words or signs that look like they belong to a language, are sequenced, conjugated, declined, and capitalized correctly, and yet are not valid examples of that language. Likewise, one can have elements of a language used correctly according to those rules, but their combination has no meaning¹ according to its semantics, even to poets²

Software .. [are] systems of meaning – Kevlin Henny

Software languages, while using words from human languages, are even more rigid in their grammar, syntax, and context, and still are able to hide incorrect meaning in technically correct text

This And That

Even seemingly obvious things like...

In the 1990s, we were all searching for passion. Passion leads to Excellence, and we were all in search of that. In the 2000s, geeks took over, and geeks are just people who show their passion. The passionate, geeky software developer is a cliché, albeit a common reality. Many businesses and thought-leaders welcome that passion, and even try and motivate it

They enjoy the benefits of the drive and attention passion incites in software developers. They love the passion-fired momentum geeks have for “their” features. Build and support engineers can get passionate about their parts in a process even if customers never see it. But businesses also call on a different aspect of their workers from time to time: their professionalism

Compare the meanings of professional and its antonym amateur: the latter term might mean less-skilled (than a professional) or a dilettante. but originally it...

Technical debt (TD) – the compromises we make to get stuff out the door – is more often acknowledged and occasionally quantified. We categorize the inefficiency and difficulty working with it—the “interest” on the debt—as an unfortunate cost. Fixing technical debt (paying down the “principle”) competes for resources with new development and tangible defects

The common TD horror story is changing the behaviour of badly-coded modules¹. For example, spending hours adding a simple variation to an existing implementation, which has never worked consistently (and never been fully tested – let alone built for extension or reuse), is dangerous as well as frustrating. Without tests or clear documentation, we are never sure what good behaviour is, so extending that behaviour is often an exercise in faith²

In analyzing technical debt, we tend to mythologize it:

• Technical debt is something...

Decorators are a bit of meta-programming that allows one to add behaviour to functions and classes. The original function or class is wrapped in another function or class, and its name is pointed to that wrapper. Any use of that name will refer to the wrapper, not the original. This happens at “compile” time, not at runtime

The mechanics treat any function or class name prefixed by an “@”¹ as a decorator and apply it to the following function, class, or method definition. The compiler takes the completed definition and passes it as an argument to the decorator, and the decorator returns a function or class, which the original token (name) points to

@a_decorator
class Foo(object):    "Foo" = a_decorator(class formerly-known-as Foo)
    ...

@a_decorator          "Bar" = a_decorator(function fka Bar)
def Bar:
    ...

rab = Bar()           rab is pointing to the result of

While optimization is often premature and, therefore, the root of all evil¹, using an efficient design for data access is choosing a good path rather than paving a bad one. A common task for APIs is to retrieve a “page” of master rows and their detail rows (e.g. Invoice and Items), as well as a total count of the master rows that match the given criteria. Here are three ways to get the data from a standard SQL database:

Option 1: for each row of the master table query result, execute a query per detail table to get the detail rows for that master row (also known, derisively, as N+1)

Pro

• initiative design
• allows easy pagination of master rows

Con

• slow
• lots of little queries burden SQL server and network
• data might change during the process if the option does not include a potentially huge transaction (because the last query returns long after the first one)
  

Option 2: join

“… a landmark UCLA study showed that gestures count for a whopping 55% of the impact you have on an audience, while your tone of voice makes up 38%. Your words? A measly 7%” –Forbes

Words, then, are the minority player in presentations. Indeed, to help detect falsehood, one should ask for a written summary to remove the 93% of the demagoguery and hand-waving. Seven percent is not zero, however, and some audiences do pay attention to some of the words: the words that annoy them. If the words are also on visuals (like slides¹), they count for more than seven percent

The word impact as a verb (e.g. “This will impact sales”) makes me twitch. I prefer the verb affect, and I accept that this is a lonely preference. Likewise, performant, value proposition, upskilling, etc., will break my undivided attention

Important, perhaps, to an engineering or scientific audience: theory vs. hypothesi...