No Clever Code

Read this first

The Magical, Full‑Stack Developer or The Intellectual Shmoo

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 (and all of them!)

“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...

Continue reading →


The Futures of Python

Futures defer execution of code. They can allow code to wait for external resources like file reads, network calls, and database access, and then automatically continue without stopping every other operation. They allow the definition (i.e. coding) of entire sequences of work in one place rather than having one function hand-off to another (presumably coordinated) function

Python’s syntax for Futures (and coroutines) is simple and, for me, surprisingly confusing at first. I have concluded that Futures in Python boil down to three (3) rules:

  1. Functions prefixed with async return a Future1 when called even if the function itself does not return a result. The code inside the function does not execute until something resolves the Future

  2. The ways to resolve a Future are

    • await <Future>
    • asyncio.get_event_loop().run_until_complete(<Future>) or ayncio.run(<Future>)2
  3. Use await inside asyn...

Continue reading →


Don’t Mansplain Your Code

When getting one’s code reviewed, if a reviewer asks what the code is doing or why the code does not follow the common conventions, don’t answer them The problem is not that they don’t understand; the problem is that your code is not clear

Don’t mansplain code with comments, READMEs, or call-outs in documentation; let it speak for itself

Change the code so it is clearer: improve the nomenclature; break operations into separate functions; or, if absolutely necessary, add a comment. You might find bugs, missing cases, or other improvements in clarifying the code. In any case, your code must be able to speak for itself unless you add your personal phone number

Don’t write so that you can be understood; write so that you cannot be misunderstood – William Taft

Comment only what the code cannot say – Kevlin Henney

This principle includes comments on a Wiki (e.g. Confluence). Don’t reply...

Continue reading →


The Tragedy of Heroes

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...

Continue reading →


Source Code as Poetic

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’s1 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 functions2 that begin the orchestration of all the specialized procedures...

Continue reading →


Four Unintuitive, Critical Things to Learn About SketchUp

1. It Really Wants To Be Modal

click-release-move instead of click-drag1

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 dimension2
When...

Continue reading →


Temba, His Arms open()

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 meaning1 according to its semantics, even to poets2

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...

Continue reading →


Professionalism ∝ Passion-¹

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...

Continue reading →


Technical Debt Is Cholera, not Quicksand

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 modules1. 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 faith2

In analyzing technical debt, we tend to mythologize it:

  • Technical debt is something...

Continue reading →


Python Decorators (and Digressions)

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 “@”1 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
...

Continue reading →