Spectrums of Sexuality

A little while ago, I came out as bisexual.  The process of coming to grips with my own sexuality took a lot of thinking on my part, and I did a lot of reading on the subject as well as watching YouTube videos of other people who had already come out.  Early on in my research, I ran across the notion that sexuality is a spectrum from heterosexual to homosexual (with bisexual being in the middle).  

This idea of a spectrum has been studied at some depth already.  A sex researcher named Kinsey established a scale from 0–6 to rate people on a spectrum of exclusively heterosexual (0) to exclusively homosexual (6), with bisexual people in between.  A later researcher named Klein expanded upon Kinsey’s work with a much more complex system, but one which still focuses on the straight/gay spectrum (although with a great deal more richness).

It strikes me though, that this is hardly the only axis of sexual expression. While various people have suggested this already (Klein, in particular), I haven’t yet run across any research on the subject.  On top of that, as I’ve been thinking and reading, I’ve come to prefer thinking about these various axes less as spectrums between two opposing points, but rather as a level of interest in a certain kind of activity.  With that approach, the following ranges stand out as being more-or-less independent of one another:

  • sexual interest in a different gender
  • sexual interest in the same gender
  • romantic interest in a different gender
  • romantic interest in the same gender
  • desire to be the active partner during sex
  • desire to be the passive partner during sex
  • interest in performing various acts on a partner
  • interest in receiving various acts from a partner
  • desired frequency of sex
  • desired length of a sexual encounter
  • strength of preference for monogamous relationships

As long a list as this is, it doesn’t even touch on gender expression, and even then I’m sure there are other axes which haven’t even occurred to me (feel free to comment below if you can think of others).  My point, really, is that one can think of most aspects of sexuality as a matter of degree: not a matter of either-or.

I arrived at this concept by observing and reading about lots of different individuals and then working backwards.  So, for the purposes of this essay, I think it would be helpful to work forwards again by considering some specific examples.

One might imagine the worst stereotype of a straight 20 year old male, for example.  This hypothetical individual has high sexual interest in the opposite gender, no sexual interest in the same gender, low romantic interest in anyone (i.e., a desire to form a permanent bond with another person), high desire to be the active partner during sex, low interest in being the passive partner (and then only for certain acts), and a desire for frequent, but relatively short sexual encounters with many partners.

On the other hand, one could also imagine a married lesbian woman in her 40’s.  She may have low (but not zero) sexual interest in men, high sexual interest in women, high romantic interest in women (and none for men), a strong desire to be the passive partner during sex, and a preference for extremely extended (but infrequent) sexual encounters only with her spouse.

Or, just to illustrate that these needn’t be either-or, consider a bisexual woman in her 20’s.  She may have moderate sexual interest in both the same and different genders (though slightly more for men), moderate romantic interest in either, alternating desire to be the active or passive partner (depending upon the partner), and a desire for frequent sexual encounters of moderate duration.

One could, naturally, multiply these examples endlessly (e.g., gay men, swingers, asexuals, …).  And, for any given example, one could conceive of a person who is the same in all the axes: except the one where they differ completely.  Where do you fit on these various ranges?  If you’re with someone, where does your partner?


There is, of course, a huge variety of permutations when thinking about sexuality as a set of orthogonal ranges.  In fact, I think that’s how real people actually experience their own sexualities.  Moreover, I think taking this perspective helps eliminate the excessively nit-picky labeling which has become rampant without denying the truth of any one individual’s experiences.  With so many possible “labels” to stuff people in, the entire exercise becomes futile.  In the end, we’re all unique in our likes and dislikes, so each person should be judged on their own merits: not which end of what scale they might fall on.

Being the “second” parent

About 16 years ago, when my wife, Rachel, and I were contemplating having our first child, we talked a lot about how we would share the responsibilities for parenting.  In the end, she decided that she’d like to leave full-time hospital nursing to be able to spend full-time with our future child.  A few years after he was born, he was diagnosed as having high-functioning autism.  Needless to say, the job of parenting went from pleasantly challenging to downright daunting.

At the same time, I was building my career as a software engineer / manager.  It was (and still is) very demanding work which often requires a fair bit of overtime, and leaves me with very little time for anything else: even being a father.

So, the dynamic in our family is that my wife has taken about 75% of the burden of parenting, while I’ve taken on the rest.  This includes a lot of things: physical care (esp. during younger years), playing / supervising play, driving to appointments & activities, food preparation (and actual feeding, at least early on).  To be fair to myself, I’ve always shouldered my share of those tasks when I’m home.  But, the reality has always been that I’ve worked full-time out of the house, and I simply haven’t been physically present to do those things nearly so often as Rachel has.

Which leads me to my point.  In our family, I’m the de facto “second” parent.

Being the “second” parent is not remotely the same thing as being an absentee, uninvolved, or disinterested parent.  It also does not mean that I don’t carry my own weight in household chores or coping with parenting challenges.  But there are a few important differences.

First, it is completely true most routine decisions are made without my direct input.  I’ve always felt welcome to comment on them or suggest improvements, but my wife nearly always handles these out without any need for me to weigh in.

Second, my wife and I routinely set time aside (our date night) to talk over those decisions which aren’t routine.  Whether this is making some choice about schooling, correcting some nascent behavior problem, helping our son get started with a new activity, or altering some routine around the house, we always have a time and manner to make sure we address them together.  Often, these are situations where my wife will raise the issue, and I’ll give my feedback: leaving the final call in her court.  Most of the time, though, we come to a consensus on the spot.

Third, I have to be more deliberate about spending time with my son.  Since my calendar is often pretty full, it’s frequently the odd moments here and there which I need to capitalize on.  As one would expect, the exact form this takes has changed over the years.  Recently, he has begun to share my interest in fantasy & science fiction, movies, video games, and a number of other things.  So, recently, these odd moments have taken the form of late-night conversations which range all over, but most often start with one of those shared interests.

Finally, I’m often the member of the tag-team who is “tagged in” when things get intense.  Being on the autism spectrum, our son’s tantrums have always been intense, and they still can be.  By the point when my wife is getting frustrated and starting to lose patience, I’ll jump in and take over the conversation.  Both because of my particular personality, and especially because I’m “tagging in” fresh, I’m able to remain calm and detached from his intense emotions.  In these cases, I sit with him and help him calm down by gently refusing to react to his intense emotions (sometimes over the course of an hour or more), and by helping him talk though the issue.  These conversations often get very philosophical and talk about ethics, character, and principles for addressing the situation at hand.


It’s easy to dismiss the “second” parent.  In fact, the disconnected, bread-winning father figure, by now, is beyond clichéd.  It’s also not how things have to be.  Whether the “second” parent is the mother or father—and I know at least one family where dad stays home while mom works outside the house—both can be full partners as “the parents”.  It takes some deliberate choices of who’s going to step forward, and how often, and for what things, but that doesn’t mean it isn’t an equal partnership in keeping a home and raising a family.  So, all of this is really just to say: while the roles are different, there really isn’t any “second” parent.

My favorite books on software engineering

I started to teach myself programming when I was 8 years old.  It was a brand new Macintosh Plus, and I was totally hooked on Hypercard.  I mostly learned by tearing apart the examples it came with, and figuring things out myself.  And, while this was fun, it really didn’t teach me a lot about software engineering.

I personally look at the difference between programming and software engineering as the difference between building a dog house and building a real house.

You can learn how to build a dog house on your own: completely self-taught.  You can build a dog house over a weekend or two of dedicated effort.  You can build a dog house on your own.  The consequences of completely screwing up your dog house are pretty minimal.  All that said, it’s not actually easy to make a super nice dog house, so there’s some real effort involved if you’re going to do it well, and there are some spectacular dog houses out there.

However… building a real house is an entirely different kind of endeavor.  To even start, you’re going to need to seek out some professional education.  You certainly will need a lot more than a few weekends.  You’re also going to need a team of specialists to help.  And, of course, the consequences of screwing up a real house will be very expensive: if not actually dangerous.

So, when I went off to school to learn how to go from being an avid programmer to a professional software engineer, I had a lot to learn.

I may talk about my schooling at some future point, but it was actually the reading I did on my own, at the recommendation of some of my early mentors, that taught me the most.  So, I want to pay it forward, and recommend a couple of those books I found most formative.

Code Complete, by Steve McConnell is where I was first introduced to most of the essential concepts of large-scale software engineering.  As each concept was introduced, it was accompanied with lots of examples in code, and excellent, in-depth explanations.  It is no exaggeration that this book completely changed how I wrote code. If you only ever read one book on coding, make it this book.

Design Patterns, by Erich Gamma et. al. is the foundational book for the entire concept of design patterns.  In short, straight-forward chapters, it teaches some of the most fundamental and re-usable building blocks of complex software systems.  The patterns described in this book have become the very language of software design.

Refactoring, by Martin Fowler outlines the most essential skills in changing existing code. Whether it’s to add a new feature, fix a bug, or anything else you’ll want to learn and follow the procedures outlined in this book.


To be fair, these are three among a great number of amazing books on software engineering, so the fact that I don’t list a particular book here doesn’t mean it’s not valuable.  There are a lot of other books I have on my shelf and have read cover-to-cover (some of them multiple times).  However, of all the books in my collection, I view these three as having been most personally influential on the way I write and think about code.

Git 201: Creating a “fixup” commit

This post is part of a Git 201 series on keeping your commit history clean.  The series assumes some prior knowledge of Git, so you may want to start here if you’re new to git.


As I work on a branch, adding commit after commit, I’ll sometimes find that there’s a piece of work I forgot to do which really should have been part of some prior commit.  The first thing to do—before fixing anything—is to save the work I’m doing.  This might mean using a work-in-progress commit as described previously, or simply using the stash.  From there, I have a few options, but in this post I’m going to focus on using the “fixup” command within git’s interactive rebase tool.

The essence of the process is to make a new commit, and then use git to combine it with the commit I want to fix.  The first step is to make my fix, and commit it.  The message here really doesn’t matter since it’s going to get replaced anyway.

> git add -A
> git commit -m "fix errors"

This will add a new commit to the end of the branch, but that’s not actually what I wanted.  Now I need to squash it into the older commit I want to fix.  To do this, I’m going to use an “interactive rebase” command:

> git rebase -i master

This is telling git that I want to edit the history of commits back to where my branch diverged from master (if you originally created your branch from somewhere else, you’ll want to specify that instead).  In response to this request, git is going to create a temporary file on disk somewhere and open up my editor (the same one used for commit messages) with that file loaded.  It will wind up looking something like this:

pick 7e70c43 Add Chicken Tikka Masala
pick e8cc090 Remove low-carb flag from BBQ ribs
pick 9ade3d6 Fix spelling error in BBQ ribs
pick b857991 fix errors

# Rebase 1222f97..b857991 onto 1222f97 (       5 TODO item(s))
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# These lines can be re-ordered; they are executed from top to
# bottom.
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
# Note that empty commits are commented out

All of these commits are those which I’ve made since I cut my branch:  ordered from oldest (on the top) to the newest (on the bottom).  The commented out parts give the instructions for what you can do in this “interactive” portion of the rebase.  Assuming that the fix is for the Chicken Tikka Masala recipe, I’d want to edit the file to look like this:

pick 7e70c43 Add Chicken Tikka Masala
fixup b857991 fix errors
pick e8cc090 Remove low-carb flag from BBQ ribs
pick 9ade3d6 Fix spelling error in BBQ ribs

When I save the file and quit my editor, git is going to rebuild the branch from scratch according to these instructions.  The first line tells git to simply keep commit 7e70c43 as-is.  The next line tells git to remove the prior commit, and replace it with one which is the combination of the prior commit and my fix-up commit, b857991.  The other two commands tell git to create two new commits which result in the same end state as each of the old commits, e8cc090 and 9ad3d6.

As a bit of an aside…  Why does git have to create new commits for the last two commands?  Remember that commits are immutable once created, and that part of the data which makes up the commit is the parent commit it was created from.  Since I’ve asked git to replace the parent commit, it will now need to create new commits for everything which follows on that same branch since each one now has to have a new parent: all the way back to the commit I replaced.

At the end of all this, if we were to inspect the log, we’d see:

> git log --oneline master..

6a829bc3 Add Chicken Tikka Masala
29dd3231 Remove low-carb flag from BBQ ribs
0efc5692 Fix spelling error in BBQ ribs

In essence, everything appears to be the same, except that the original commit includes my fix.  However, looking a little closer, you can see that each commit has a different hash.  The first one is different because I modified the “diff” portion of the commit (i.e., I added in my fix) and therefore a new commit was needed (commits are immutable, so adding the fix required making a new one).  The other two needed to be re-created because their parent commit disappeared, and therefore new commits were needed to preserve the effect of those two commits, starting from my fixed-up commit as the new parent.


There is one caveat I have to warn you about when using this method.  Any time you rebase a branch, you’ve changed the commit history of the branch.  That is, you’ve thrown out a whole bunch of commits and replaced them with a completely new set.  This is going to mean loads of difficulties and possibly lost work if you’re sharing that same branch with other people, so only use this technique on your own private working branches!

Git 201: Keeping a clean commit history

This series is going to get very technical.  If you’re not already familiar with git, you may want to start over here instead.


Most people I’ve worked with treat git somewhat like they might treat an armed bomb with a faulty count-down timer.  They generally want to stay away from it, and if forced to interact with it, they only do exactly what some expert told them to do.  What I hope to accomplish here is to convince you that git is really more like an editor for the history of your code, and not a dark god requiring specific incantations to keep it from eating your code.

As I’m thinking of this as a Git 201 series, I’m going to assume you are familiar with all bunch of 101-level terms and concepts: repository, index, commit, branch, merge, remote, origin, stash.  If you aren’t follow this link to some 101-level content.  Come on back when you’re comfortable with all that.  I’m also going to assume you’ve already read my last post about creating a solid commit.

As you might expect, there’s a lot to be said on this topic, so I’m going to break this up into multiple commits… err posts.  To make things easy, I’m going to keep updating the list at the end of this post as I add new ones in the series.  So, feel free to jump around between each of them, or just read them straight through (each will link to the next post, and back here).


Git 201: Using a work-in-progress commit

This post is part of a Git 201 series on keeping your commit history clean.  The series assumes some prior knowledge of Git, so you may want to start here if you’re new to git.


My work day doesn’t naturally divide itself cleanly into commits.  I’m often interrupted to work on something new when I’m half-way done with my current task, or I just need to head home in the evening without quite having finished that few feature.  This post talks about one technique I use in those situations.

To rewind  a bit though, when I’m starting a new piece of work (whether a new feature, bug fix, etc.), I first check out the source branch (almost always master), and run:

> git pull --rebase

This grabs the latest changes from the origin without adding an unnecessary merge commit. I then create myself a new branch which shows my username along with a brief reminder of what the change is for:

> git checkout -b aminer/performance-tuning

At this point, I’m ready to start working.  So, I’ll crack open my favorite editor and make my changes.  As I’m going along, I’ll often find that I need to stop mid-thought and move on to a different task (e.g., fix something else, go home for the day, etc.).  It may also be that I’ve arrived at a point where I’ve just figured out something tricky, but I’m not through with the overall change yet.  So, I’ll create a work-in-progress commit:

> git add -A
> git commit -n -m wip

This is really more of a “checkpoint” than an actual commit since I very likely haven’t fully finished anything, probably don’t have tests, etc.  The -n here tells git not to run tests or linters.  This is fine for now because this isn’t a “finished” commit, and I’m going to get rid of it later.  For the time-being, though, I keep on working.  If I reach another checkpoint before I’m ready to make a real commit, I’ll just add on to the checkpoint commit:

> git add -A
> git commit -n --amend

The first command pulls all my new work into the index while the second removes the prior work-in-progress commit, and replaces it with a new one which contains both the already-committed changes along with my new ones.

When I’ve actually finished a complete unit of work, I remove the work-in-progress commit:

> git reset HEAD~1

This will take all the changes which were in the prior commit, and add them back to my working directory as though they were there all along.  The commit history on my branch looks just as though the commit had never been there.

A Queer Thanksgiving

I came out as bisexual earlier this year after a long time struggling both with acknowledging my own sexuality, and then building up the courage to come out to others.  As I’ve been thinking about being thankful for various things this year, it keeps coming back into my head that I owe an immense debt to other people who have paved the way for my coming out to be possible.

The first group of people who come to mind are the martyrs.  The countless gays, lesbians, and other queer folk who found themselves living at the wrong point in history, and paid the price for just existing.  Even only considering recent history, this includes millions of people trapped in Nazi Germany, people persecuted in the UK and America under discriminatory laws, and others around the world who were victims of lawfully enshrined prejudice.  This especially includes Alan Turing, one of my personal heroes, whose heroism during WWII, and later epochal contributions to computer science didn’t prevent his government from persecuting him, and likely driving him to suicide.  This also includes martyrs to private hatred, like Matthew Shepard, who was murdered by private citizens in a gruesome case of homophobia.  While tragic, I am thankful that the stories of these people helped to awaken our society to the injustices being done to queer people.

The second group of people who come to mind are the crusaders.  From those who protested in the Stonewall riots at the start of the modern gay rights movement, through to the people who still march at pride parades, protest against unfair laws, and speak out for equal rights for the LGBT community at large.  But for these people, I would have been in legal jeopardy if I decided to come out, and, being bi in a straight marriage, I almost certainly wouldn’t have.  I’m thankful that they have changed my society into a place which acknowledges and respects queer people, and that—by their struggles—my rights are protected regardless of my sexual orientation.

The third group which comes to mind are the scientists and educators.  There’s been a long road which leads up to our current understanding of sexuality as a complex set of variables in which people fall into a myriad different categories describing sexual and gender expression.  In particular, Alfred Kinsey comes to mind as one of the earliest of modern researchers to seriously study the subject and start to move away from homosexuality as a disease to homosexuality as being part of the normal spectrum of human behavior.  In this group, I also include more modern scientists and doctors like Lindsey Doe who promotes positive sex education: including non-hetero orientations.  Without their work, both I and the society I live in would still be trapped in antiquated and prejudicial views about sexuality.  I am thankful to live an a time enlightened by their research and teaching.

The final group I think of are my own friends and family.  The largest portion of this group is made up of all those people who said such kind and supportive things when I actually did come out.  But, this group most especially includes my friends Duane and Blake, both of whom spent hours talking and exchanging emails with me while I worked through whether to come out, how to come out, and why I should want to do such a thing.  That I could be so articulate in explaining myself, and, as Duane put it so well, “tremblingly determined” to make myself understood, is through their friendship and advice.  I am thankful to have such thoughtful and wise people in my life to help me when I’m struggling and uncertain.

But, most of all, I think of my wife, Rachel.  I could have never understood my own sexuality without our long talks, and she was always there to talk, or just listen to me talk.  It was also immeasurably easier to accept myself with the certain knowledge that she would accept me, too.  And she did, and does.  It would also have been so much harder to muster the courage to come out without her love and support.  I am thankful to have such a caring, thoughtful, and loving person as a partner who constantly urges me to be the best and truest version of myself.

Recipes: Thanksgiving Feast

This year, we decided to ditch the usual turkey in favor of a French-themed feast.  Here’s the menu:

Okay… perhaps French-themed is a stretch, but it will definitely make a nice change from turkey!

What makes a good commit?

It is distressingly common for me to see commits in a git repository which look something like:

commit 6a69053d2419b311cc38c9fdbbbac75b5a62c4fa
Author: dev-dude <dev-dude@somco.com>
Date: Sun Mar 29 14:05:46 2015 +0200

    fix missing commas

Such a commit will often be half a complete thought (if even that much), have no tests, and a message which explains exactly nothing about why the change was made, or what its intended consequence are.  We can do a lot better.


A good commit is much like a good sentence: a well-formed, grammatically correct, complete expression of a single thought.  In the case of a commit, this means that it should:

  • make exactly one cohesive change to the code
  • include tests to verify the change
  • have a title which clearly—but briefly—indicates what was done
  • have a message which describes why it was done



The most important virtue of a well-formed commit is good cohesion, or: doing only one thing.  This could be a refactoring in preparation for some new feature to be added, it could be adding that feature, it could be fixing a bug.  The actual size of the commit doesn’t matter so terribly much (though smaller is generally better), but that it clearly represents a single change does.

As a short-cut for deciding whether your change is cohesive or not, consider how easily you could come up with the title for the commit.  Can you, in 70 characters or less, state clearly what your change does.  If not, it’s probably not very cohesive.  If you find yourself tempted to make a list as your commit title, you definitely don’t have good cohesion.

In such cases, stop and ask yourself: “what is the smallest thing I could possibly do to this codebase which would be a clear improvement?”.  In a single pull request, it’s not at all uncommon for me to have more than one of these kinds of commits:

  • clear up some stylistic problems with old code
  • refactor various parts of the code I’m about to touch
  • add a new class which will be part of a new feature I’m about to add
  • tie a bunch of prior commits together in a way which makes the new feature visible to the user
  • update documentation

Of course, depending upon the exact nature of the work, I may not need all of those, but it will be very common for me to have at least a few of them.



In my opinion, tests deserve as much care as any other code, and it’s quite possible to have too many or too few.  That’s a topic for another time.  For now, I just want to point out that any new commit should include any appropriate tests related to that new code.  Of course, it’s possible that it’s appropriate not to add new tests (e.g., for a refactoring), but if a commit doesn’t have tests, it should only ever be because you considered it, and decided there weren’t any new tests which were needed.


Commit Title

Git actually does have a proper format for the commit message; it’s not just arbitrary.  Remember that git is a command-line tool, and is often used in environments where space can be limited.  To that end, there’s a definite format.

In this format, the first line is considered a title, and it should be a present-tense, imperative sentence stating what changed with this commit (e.g., “Add the FizzyWizzBanger class”).  This should be less than 70 characters because git will only show that many in the various “one-line” versions of its commit logs.  Ideally, it will be sufficiently differentiated from other commit messages so that you can readily figure out which one of several commits it is, even out of context.


Commit Message

The question of “what” the commit changes should really be summarized by the title, and made obvious from the code.  In the commit message, you should focus on why you made this change.  Perhaps it fixes a certain bug.  If so, go ahead and explain—in a sentence or two—why this change fixes that particular bug.  It doesn’t hurt to mention the bug number here either.

Don’t be afraid to use simple formatting here either.  A good many Git-related tools support markdown formatting, so feel free to use whatever you like.  Just be sure to leave an empty line after the title since that’s what git will be expecting for its longer-form messages, as will other git-related tools.


Building up your codebase using a series of well-formed commits has a number of major benefits.  

  • other developers will be able to understand what changed and why much more easily with small, focused commits with clear messages
  • it creates a commit log which reads well, whether using the full log format or just the “one-line” version
  • it is much easier to test small changes
  • not allowing any commits without proper tests means not playing catch-up with a massive and under-tested codebase later on
  • tracking down problems later is much easier if you can isolate the problem to a single commit, and that commit isn’t massive
  • merging branches is much easier (and git is much better at avoiding conflicts altogether) if you work in smaller increments

So, before you start typing… stop to think about what small, specific improvement you’re going to make to the codebase next, and make it as perfect and tidy as you can before moving along to the next one.

Fail early, fail loudly

One easy step to help simplify your programs is to follow the adage “fail early and fail loudly”.  By failing early, I mean that your code should actively look for problems and stop as soon as something wrong is encountered.  By failing loudly, I mean that your code should raise the alarm in a way that makes it obvious to other parts of the system (and people reading the code) that something unusual has just occurred.

Naturally, this doesn’t mean that your code should explode whenever the slightest thing is wrong.  On the contrary, it means that each object/package/component in your system should demonstrate good cohesion by refusing to operate in a situation it shouldn’t have enough context to do so.  Instead, each component should fail when encountering something that it isn’t supposed to be able to handle, and delegate responsibility for handling that situation to the caller.  The caller can then decide whether it has sufficient context to handle the situation, or to pass along the responsibility to another component.

Failing early is a benefit because you can then build whole sections of your program which don’t have to consider some particular error case.  For example, consider building a web service which accepts objects encoded in XML as input.  If all the necessary error checking is performed up front (e.g. the XML is validated against the DTD, required elements needed in the API are found to be present, and various values are confirmed to be within acceptable ranges), the remainder of the web service call can be written to assume that the request was perfectly valid.  The notion of Short Circuit statements I discussed recently is another variation on failing early.  All of them reduce the mental load of reading (and writing) the code which follows them.

Failing loudly is a benefit because it reduces the mental effort required to follow up on errors which occur in other parts of the system.  If a component fails loudly, a caller must ensure that they correctly respond to error conditions in order to be correct themselves.  The best example of this is a checked exception.  In Java, for example, any method which can possibly throw a checked exception must explicitly declare it in its signature.  Calling methods are forced—by the compiler—to either to catch the exception or declare that they throw the same exception themselves.  This radically reduces the mental effort required to follow up on the error, and provides a built-in mechanism to remind you when you’ve forgotten to do so.

(The fact that some API’s abuse checked exceptions horrendously is a topic for another time.)

There are a number of cases where these two ideas apply, but they are especially true around where data enters a program’s runtime environment.  Some examples include: reading from a database, accepting user input from the mouse/keyboard, accepting an incoming TCP/HTTP connection, or simply reading data from a file.  In all of these cases, doing all of your error checking as soon as the data has entered the runtime environment will allow subsequent code to assume all the data was correct.

Failing early and failing loudly can also be seen as corollaries of Cohesion and Coupling.  If a component is well-integrated to a single purpose, it will not attempt to handle conditions which are outside of that purpose.  Instead, it will fail as soon as it is asked to cope with such a situation.  In order for a component to offer loose coupling, it must reduce the amount of knowledge needed to interact with it.  One aspect of this is to make it very clear what to expect in case the component has problems.  Both of these concepts lead back to preserving the Unit Economy of the reader (and author!) of the code.