Month: November 2018

Git 201: Creating a “fixup” commit

Andrew Miner1 Comment

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

Andrew Miner1 Comment

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

Andrew Miner5 Comments

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

Andrew MinerLeave a comment

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

Andrew MinerLeave a comment

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?

Andrew Miner1 Comment

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

 

Cohesion

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.

 

Tests

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

Andrew MinerLeave a comment

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.

Makers vs. Managers

Andrew MinerLeave a comment

I recently read an article about the sharp divide between how different people use their time.  It divided people into two general camps: the “maker” and the “manager”.  People who fall into the former camp have work which requires large blocks of time which they can dedicate to a single concentrated task.  Engineers, authors, designers and the like all fall into this camp.  On the other hand, people in the “manager” group have work which requires them to constantly shift their focus from one task to another fairly quickly. Program managers are the quintessential profession in the software industry, but supervisors in nearly any field, people managers, and executives all of this pattern of work.

Unfortunately, makers and managers often need to work closely together, and often don’t really respect (or possibly even understand) the differences in each other’s mode of operation.  Managers will disrupt makers by scheduling meetings at whatever time works best to get the meeting scheduled soonest, without regard for leaving two funny 30 min chunks on either side of the meeting (which does a lot to kill the maker’s productivity).  On the other hand, makers will frequently drive managers right up the wall by failing to respond to a requests in a timely manner, or getting buried in one task and letting the schedule on another one slip.

There are two specific practices I’ve used which work well to smooth things out between these two groups: “Daily/Weekly War Team Meetings” and “Maker Time”.

A war team meeting is a routine standing meeting which the decision-makers of the team are required to attend, and which everyone is invited to attend.  The agenda for the meeting is decided in the first few minutes of the meeting.  Everyone present is welcome to add an item to the agenda, and request a certain amount of time for it (e.g., 5 minutes for a fast time, and up to 15 minutes for a long one).  The facilitator will put it up on the whiteboard.  Once the agenda is set (i.e., no one has any further items to suggest, or the duration of the meeting is spoken for), the facilitator starts walking through the items on the list.  Their job is primarily to keep the discussion on topic, capture items for future discussion, and keep things running on schedule.  If an issue cannot be resolved within the allotted time, it can either be settled privately between a few individuals who become empowered to settle the issue, or it can be brought back to the next meeting. Once all of the items which interest a person have been discussed, that person is welcome to leave.

This technique works fantastically well when coming up to a deadline, but is generally a good practice at any time (the closer to release, the more often you generally want to have the meeting).  The first positive effect is that it gives everyone on the team a forum and a voice on how decisions are made.  They don’t get to make the decision, but they can be part of the process.  That goes a long way toward improving morale on the team (especially one with really passionate, dedicated people).  The second effect is that it tends to consolidate hours of meetings into a much shorter span.  The vast majority of meetings take much longer than is required because they don’t have a really tight agenda, and because there is no strict timekeeper to keep things on track.  The third effect, and most important to makers, is that it makes the time of meetings predictable and consolidated.  This technique eliminates the need for many other meetings, and therefore gets rid of those odd little chunks of time which are hard for makers to use effectively.  Finally, and this is most important to managers, it creates a forum in which blocking issues can be resolved quickly and often. If your team does this daily, then the majority of issues which require a meeting can wait until the already-scheduled meeting the next day.

The second technique I’ve used for this kind of issue is “Maker Time”.  This is where makers are invited to block their calendars, reject meeting invites, close their doors, put on headphones or whatever else they need to do to put the world on hold for a few contiguous hours each day.  On one team I ran, we decided that we would prohibit meetings after 14:00.  In other situations, the team would pick a “meeting-free” day of the week (i.e., no meetings at all on Thursdays every week).  Whichever way, the leadership of the group made it clear to makers and managers alike that this time was to be set aside for makers to get their jobs done, and no one was to interrupt them (except for clearly defined emergencies).  This allows makers to have their dedicated time without completely blocking out managers for long periods of time.

The Interview Schedule

Andrew MinerLeave a comment

This is part 3 of a series on interviewing.  Check here for part 1 on setting up an interviewing team.

✧✧✧

It’s important that every candidate be treated like you’d treat a VIP customer.  Even if you don’t wind up making an offer, they will have a deeper interaction with your company and your staff than the vast majority of the general public, and you want them to go away wishing they’d gotten an offer.  They are going to tell people about their experience with your company, and you want the story they tell to be about how awesome a place it seems to be, rather than how they dodged a bullet by not getting an offer!

There are a long set of interactions which happen prior to a candidate coming in for an interview loop which I’ll talk about in other posts.  Here, I want to focus on the in-house interview.  For that, he first step of that is to make sure the candidate has a full  schedule of their visit.  This should be delivered to them along with all the initial travel arrangements.  Ideally, it should include:

  • an initial meet & greet / tour segment
  • a list of each person they’re going to meet along with their role and email
  • a schedule of when important events are happening throughout the day (e.g., each interview, lunch, happy hour, etc.)

The first part, the meet & greet, serves two important purposes.  First, it’s important to always bear in mind that most people find interviews extremely nerve-wracking.  A short tour of the office, and a chance to chit-chat with a few people helps the candidate unwind a bit.  Second, it gives you a time buffer to absorb any unexpected delays in the candidate’s travels.  Whether it’s traffic, parking, a flat tire, a late subway train… whatever.  It’s easy enough to just cut this period a bit short so the candidate can get started on time, and you can avoid messing up the rest of the day’s schedule.

The second point, giving a list of interviewers, deserves a bit more explanation.  For a mediocre candidate, this information won’t matter.  However, for an exceptional candidate, it’s an opportunity for them to show their enthusiasm and their diligence.  Really exceptional candidates will do some homework on their interviewers, and will often have some interesting question, anecdote, or topic to discuss with each interviewer.  Such candidates will also generally avail themselves of the opportunity to individually follow up with each interviewer to thank them for their time.

Finally, providing a schedule allows the candidate to mentally (and perhaps physically) prepare themselves for the expected duration and expectations for the full day.  I’ve had a number of candidates comment to me over the years at how unexpectedly rigorous / lengthy an interview was.  I’ve also had experiences as a candidate where I wasn’t able to make some other commitment because the full extent of my time commitment wasn’t clear.

✧✧✧

At the end of the day, you want your candidate to walk away thinking well of your company, the people they met, and how they were treated as a guest at your office.  One of the easiest things you can do to ensure that happens is to avoid surprising them, and by giving them a chance to do their homework up front.  And, you’ll be pleasantly surprised by your best candidates when they actually do.

Being bisexual in a straight marriage

Andrew Miner8 Comments

I was 37 years old when I started to call myself bisexual.  In hindsight, it’s pretty clear I was always bisexual, but it took a very long time for me to put a concrete name to it.

At least early on, it had a lot to do with where and when I grew up.  Calling someone a “fag” was virtually a daily insult among my peers.  HIV/AIDS was still very recent, very scary, and very much a “gay” disease.  And, most importantly, none of the recent acceptance of homosexuality had even begun to surface in my world.  Life was super, super hard for gay people back then, and if you had those impulses you sure as hell didn’t act on them if you could manage not to.  Plus, I was definitely interested in women, so I couldn’t be gay, right?

The second reason it took so long is my wife, and for all the very best reasons.  She is the most extraordinary person I’ve ever met: of any gender.  She is the most joyful, nurturing, and loving person I’ve ever met.  She’s wonderfully smart and dedicated.  Most of all, she’s honest, calm, patient, and rational.  I cannot even imagine finding another person I’d be more completely content to share my life with.  It’s been over 20 years so far, and, happily, I see no change in sight.  And, of course, being a male who is throughly in love with a female means you’re straight, right?

Nope.

What does it mean to be bi?

I can only really answer for myself, but I think of it this way.  When my physical / emotional gut reaction considers whether a person is attractive or not, their gender simply doesn’t matter very much.  To me, seeing a person who is confident, cheerful, well-groomed, and reasonably fit immediately puts them in the “attractive” category.  If you and I were just sitting in a coffee shop people-watching together, I’d find more women attractive than men—just by the numbers—but I suspect that’s because women tend to look after their appearance more carefully.  Naturally, the exact physical traits I find attractive for each gender are different, but so long as the general traits I mentioned are present, the gender isn’t especially important.

When it comes to having sex, the same indifference to gender applies.  I find the prospect of being with a man and finding mutual pleasure as appealing, exciting, and arousing as being with a woman.  I also find the idea of being the passive partner in sex as appealing, exciting, and arousing as being the active one: regardless of the gender of my partner.  To use the term from gay circles, I just consider myself to be a little extra versatile.

What doesn’t it mean to be bi?

Most importantly, being bisexual does not mean that I want to have multiple sexual partners (polyamorous).  The interest / capability / potentiality of having a male partner is certainly there, and if I weren’t already in a relationship, I would be very much open to it.  However, I am extremely happy in my current relationship, and I have no desire to change it.

Being bisexual also does not mean that I don’t think of myself as male.  I definitely think of myself as male, and am not at all personally attracted by the idea of being transgender, transsexual, transvestite, etc.  To be clear, I don’t have a strong opinion on those things, and to be perfectly honest, I know very little about them.  I just know they don’t appeal to me, personally.

What difference does it make?

It… doesn’t?  I think?  I’m a man in a happy, life-long, monogamous relationship with a woman.  Therefore, it’s easy to say: “Are you even bisexual?  What difference does it make, anyway?”  Believe me, I’ve been asking myself those questions over and over for years now.  As I’ve pondered, I’ve arrived at a few important answers.

Definitely bisexual

Even though I’ve found joy in a traditionally straight relationship, the way I react sexually has always been a part of me, and is still an undeniable part of how I experience other people.  I very definitely find both men and women sexually attractive, and I definitely could be quite happy in a serious long-term relationship with either.

Know thyself

There’s a deep satisfaction in being truly honest with oneself, and in understanding the genesis of one’s emotions.  Understanding, accepting, and talking about being bisexual releases uncertainty, anxiety, and tension I didn’t even notice I’d been carrying my whole life.

Relating to others

Identifying myself as bisexual, and coming out to other people changes how those relationships work.  Fortunately for me, I haven’t yet had a negative reaction, but I also haven’t come out to very many people.  In those cases where I have come out to someone, the experience has generally deepened the connection and helped the other person be more sincere, honest, and open with me (especially with other LGBT folks).

Freedom to explore

The last big difference this has made to me is that it removes a whole set of inhibitions about sex, sexuality, and attraction to other people.  It’s a relief to feel like I can think, write, and talk about these experiences.  And, within the context of my existing relationship, I feel empowered to explore possibilities I wouldn’t have been open to before.

Why tell anyone about it?

Every single person I’ve talked to about this blog post has asked this question, so I want to try to explain why I don’t just do the easy thing and keep it to myself.

It has been over two years since I first “came out” to my wife, my son, my parents, and—most importantly—to myself.  Since then, I’ve been slowly coming out to family and close friends.  It’s been an astonishing sense of relief.  My whole life, I’ve known this truth about myself was there, but I’ve pushed it away.  At every hint, and with every impulse, I’ve felt confused, embarrassed, or ashamed, and then promptly buried those feelings.  Again, and again, and again.  It felt way easier to just ignore that side of my sexuality, and why not?  I’m a guy in love with a gal; why make things complicated?

Why?  Because it’s a lie to say that I’m straight, and because it’s deeply distressing to continually lie to yourself.  The really hard part for people in my situation is that our sexuality is, for all practical purposes, invisible.  To me at least, that makes this life-long journey to understand and accept myself feel incomplete.  Knowing that I’m bisexual and doing nothing feels exactly the same as the hiding and repressing I’ve always lived with—and I’m done with that.

So, first and foremost, this essay is me permanently rejecting the closet in the only way I can.  Being frankly, openly, explicitly bisexual rejects the seemingly easy path of hiding in plain sight, and forever shatters any possibility of continuing to repress that side of myself.

Second, I’m seeking to find community with others who have shared this or similar experiences.  I am grateful to have amazingly supportive friends and family—straight and gay.  But they, nevertheless, can’t entirely relate to my experiences.  I would love to connect with other people who can.

Third, I’m hoping that sharing my experience of coming out to myself will prove useful to others.  Specifically, I hope this helps people who, like me, have struggled with their sexuality for many years before figuring things out: most especially to other bisexuals (closeted or not) who have struggled as I have.

Finally, I also hope this helps everyone else who doesn’t really know what bisexuality is, and who thinks they don’t know someone who is.  You probably do, and didn’t even know it.