Muhammed Ali asks: Why is everything white?

click to watch the video

He tells the story as though its a funny anecdote, and everyone’s laughing, but you can still see how earnestly he wants you to hear him and really consider: why is everything white?

Thinking on this and similar subjects has made me make small changes in my own writing. For example, as I was previously thinking a lot about sexism, I started to write about “humans” or “people” instead of “men” when I want to talk about everyone in general, and to use “they” as a singular pronoun when the subject’s gender isn’t known. It’s an easy change for me to make, and demands nothing of my readers. And, it breaks the needless ambiguity that “men” can be used both to mean a group of males as well as a group of people in general.

I suspect, having listened to this, I’ll find more things to subtly alter: not to be more PC (which I generally despise), but to be more clear with my actual desired meaning.

Reflections on “coming out”

Today, October 11th, is National “Coming Out” day in the US. For those who don’t know, I’m bisexual. I came out publicly last year in this blog post. It’s been almost a year since then, and I thought it would be interesting to reflect back on what’s been like to have been “out” for a year.

Initial reactions

The initial reactions, much to my relief, were universally positive. There were many expressions of how people’s opinions of me didn’t change at all, and how brave I was to have come out at all (esp. considering I’m very straight-passing, and married to a woman). Several people shared their own coming-out stories, and one other friend of mine even decided to come out herself based upon my blog post. I received zero negative remarks (that I ever heard, anyway).

My own reactions were largely of absolute relief to finally have it off my chest. I hadn’t predicted how immense of a relief it would be to no longer be concerned that someone would find out, or “out” me without my permission. Even though it’s still something most strangers don’t know about me, the feeling that I don’t care if they find out is wonderful.

Coming out again, and again, and again…

One thing I hadn’t entirely absorbed before coming out was that you’re really never done coming out. There’s always a new group of people you meet, a new social situation you enter into, that new person who joins your office, whatever. They don’t know you, and eventually it comes up, one way or another, and you find yourself coming out again. And again. And again…

My experience has been that it does get easier over time, but that it’s never easy. I always feel at least a little nervous, and find it difficult to make eye contact. I always feel that little inner cringe of dreading a negative reaction. Even having never received a negative reaction, it’s still a little scary. It has definitely gotten easier, though.

Frequently asked questions

There have been a number of questions which come up pretty often when the subject arises:

  • What did your wife think? (She was cool with it.)
  • What does your son think? (Sex is icky: doesn’t matter who.)
  • Have you ever considered dating a guy? (I was never out enough with myself to consider it until after I was married.)
  • Would you ever consider seeing a guy? (Definitely, but only if I was no longer married.)
  • Do you regret not having dated a guy? (Yes, but in the same way you regret deciding not to go see the Taj Mahal: as a bucket list item you choose to cross off un-done.)

Mostly, people have been very respectful of trying not to pry, but seeing how open I am about it, I get questions which become more and more personal as the conversation progresses. I’ve never received a question I refused to answer outright, but there have been a few for which I give honest, but somewhat circumspect, answers to.

Exploring LGBT+ culture

As I became more comfortable with being “out” myself, I found it increasingly interesting to spend time with or learning about other people who were also “out”. This took the form of reading and posting a lot on Quora, attending the Denver Pride Parade, writing on this blog, talking with LGBT+ friends, and adding some other reading to my usual news feeds.

It’s been eye-opening, to say the least. Getting hit on at the Pride festival following the parade was amusing. Hearing a lot of shared experiences from others (particularly bi people) has been reassuring. Of all of it, though, I’ve found that increased exposure to trans-sexual and poly-amorous people has gotten me past the “feels very foreign” stage to the “fine, but not my thing” stage.

It’s also been interesting to observe that there really isn’t a single LGBT+ culture. There are definitely some cultural norms in there, but it’s more fragmented. Gay men have certain culture norms, as do lesbian women. Bisexuals share common life experience and difficulties, but I’ve not seen a lot of shared “culture” in the same way. As I’ve observed it, the “LGBT+” umbrella gets used mostly when creating a safe space for non-straight genders & sexualities, or when advocating political action. Apart from that, I’ve not seen much evidence of a unified culture across the individual “letters” in the acronym.


Nearly a year later, I’m still very glad I made the choice to come out. I’ve met some fascinating people, had some positive influence on others, and continued to more deeply learn to understand myself, and this larger community I find myself part of. Finally, I continue to feel more and more comfortable with myself, and I think that’s the most important thing of all.

Quora: What was the hardest situation you’ve faced?

I’ve been doing most of my writing on Quora these days, which has meant, of course, that I’ve been writing a lot less here. I’m going to start cross-posting some of the longer and more interesting questions & answers here so that this blog doesn’t completely go idle.


I was 25 years old. My son was less than two months old, and my wife was no longer working (to stay with him). We had two car payments and a mortgage on our very first home. I’d just left a very well-paying job at IBM to take a chance with an exciting new job at a tiny, local company.

I got laid off three weeks before Christmas.

I remember it was a Friday, just before lunch. The company, a consulting agency, had just lost a major contract and needed to make cutbacks. It was also a cooperative (i.e., owned by the employees). I was a fairly recent hire, and hadn’t yet been made into a full member. So, despite being one of the more qualified people on staff, I was one of the ones they let go.

After spending the better part of the weekend in a panic, I figured the only thing to do was to start looking for a job. I went after it with a vengeance. Resumes sent, phone interviews, in-person interviews, and lots of time searching job boards and following up leads.

In the end, I landed at Amazon. It turned out to be one of the best jobs I’ve ever had. I learned how to be a manager, launched a major new feature on the website, and learned a ton about building large-scale websites.

I also learned one of the most important lessons of my life. No matter how bad things seem (and they seemed really, really bad at the moment), the best way to proceed is to evaluate your current options, pick the best one, and get started.

Getting the most from your log file

Think back on the last time you urgently needed to figure out what a live, production piece of software was doing. It’s very likely that nearly the first thing you did was to pull up it’s log. It’s also very likely that the majority of the content was either useless, unintelligible, or flat-out misleading.

The reason most logs fall into this state is that they are a piece-meal accumulation of statements which were thrown in over time. This is a problem because the only possible reason to waste the computer’s resources producing them is to be as correct, intelligible, and useful as possible. In short, log files should be explicitly written for consumption by people.

As with anything else, clear writing requires the author to carefully select the content, and to create it with the reader in mind. In the case of log files, we know other engineers (or scripts they write) are going to read them, and they are going to want to know how the server has been behaving. Moreover, no one reads log files unless something is going wrong. Therefore, log files should be written to make it as easy as possible to debug why a server isn’t behaving as it should. To that end, here are a few specific guidelines I’ve found most useful:

Make it easy to track down errors

It should go without saying, but it is imperative to make it as easy as possible to identify where – in the code – an error occurred. In Java this may be printing out the stack trace; in C/C++/Objective-C, this may be using the __FILE__ and __LINE__ macros. Most languages have some similar feature. Along these same lines, try to avoid having logging statements which look too much alike. This makes it easy to misinterpret the log, and completely identical statements make it impossible to know exactly where an error occurred.

Log all inputs and outputs

The fastest way to track down the reasons for strange output is to know whether the input was strange, too. This is especially true for a server (i.e. a malformed request), but it applies to other programs as well, provided you have a sufficiently broad view of “inputs” and “outputs”.

I consider an input/output to be any data which enters (or leaves) the program’s runtime context. This includes: user input (mouse/keyboard events and the like), files read/written to disk, data sent/received on a socket, or requests/results from a database query. I recommend at least logging something every time such an input or output occurs, and if reasonable, the actual content itself.

Logging inputs and outputs provides a number of major benefits. First, you know exactly what the system was asked to do. This allows you to immediately know whether a problem is in your program or outside of it. Second, it gives you a pretty clear indication of what will reproduce a problem (if there is one). Finally, it allows you to report errors to the owners of the “other” system in case you received an unexpected input.

Record how long it takes

Errors are frequently just that a system is taking too long to respond. Being able to quantify the time required for each request is an extremely valuable way to isolate the problem. However, it is not sufficient to simply record how long your system took. You must also record timings for each request you make outside of your application’s runtime context. That way, you’ll know right away if your program appears slow because it’s waiting for something else: whether it’s a web service call or reading a file from disk.

Don’t log the expected case

If something is supposed to happen, you generally don’t need to know about in the log (unless it’s one of the things mentioned above). Bear in mind that no one is interested in reading a program’s log unless the program is misbehaving. At that point, the person wants to read as little of the log as possible. Including a lot of “business as usual” statements in the log only makes the process more difficult.

Use log levels to indicate action required

Since a log file’s purpose is to assist in figuring out why a program isn’t running correctly, it’s extremely valuable to use log levels to indicate how “badly” things are going. I recommend thinking of the action required as a guide to what log level to use:

  • FATAL: page someone immediately
  • ERROR: send an email immediately
  • WARN: send in a daily report
  • INFO: include for later debugging purposes

Depending upon your logging system, the various levels often have different names, but these should map to whatever you use. Even if you don’t actually have an automated system to page people based upon your log file, it’s extremely clarifying to think about each level in these terms.

Make it easy to parse

Finally, bear in mind that most uses of a log file involve searching or parsing them using automated tools. Be sure to include standard fields in each line so that these tools can easily extract information from them. Here are some examples of what fields you may want to include:

  • time (down to milliseconds and time zone)
  • the number of the line in the log statement (to ensure each line is unique)
  • the current thread
  • the current user ID / IP address / other client-related identifier
  • the log level
  • the file/class

There’s a lot more to be said on logging, but if every log I’ve read implemented these few principles, my life would have been a lot easier. If there’s some piece of wisdom that’s too good to be missed, feel free to add it in the comments!

The Secret History of Women in Coding

For years now, I’ve been following the thread of stories about the overwhelming imbalance of white men in the software industry. Over and over, I’ve seen the questions: “How did this start? Where do we fix it?”. This is the first article I’ve read which makes a serious, well-researched effort to actually answer the question. If, like me, you’ve been concerned about this subject, I highly recommend spending some quality time reading it over.

I’ll take a stab at summarizing some of the high points, but I urge you to go read the full article yourself.

In the early days of computing, the hard part was the hardware. So, that was an area which was pretty strictly segregated along sexist lines. However, writing the software was seen as less challenging, and therefore the process of identifying programmers was mostly done using purely objective measures: usually a battery of tests which determined an applicant’s abilities to solve logic problems. In these tests, men and women tended to score equally well, and so the earliest programmers included a great many women.

In fact, sexism crept in here as well… to favor more women programmers. Since the software part was seen (erroneously) as being largely secretarial in nature (it definitely isn’t), women were often favored for such positions. It wasn’t uncommon to see these massive, room-sized machines tended to by all-female teams of programmers.

This persisted right up to around the personal computer revolution sparked by Apple and IBM in the late 70’s and early 80’s. Before this point, computers were exclusively found at large companies and universities. All students or job applicants hoping to work with them were expected to come in with no experience, and to be taught along the way. This all changed when most families could afford to have a computer in the home.

With computers being commonplace in the home, the gender biases of the typical American family started to play a massive influence over who would eventually become programmers. Young boys would be encouraged to play with the new machines, while girls would be steered toward more typically feminine pursuits. By the late 80’s and early 90’s, this lead to college computer science departments starting to see a huge influx of freshmen who already knew a fair bit about computers: most of them men.

According to the article, this is what started the feedback loop which drove women out of computer science. Overwhelmingly, the students who seemed the most precocious were male, and the professors started to offer preferential treatment to those students. Not surprisingly, this creates a very hostile environment for students starting out the program without any computer experience: largely women.

In the predictable 4–5 years later, the same situation started to play itself out in industry. Programming jobs were increasingly seen as the province of men, and those women talented and brave enough to break into the industry faced an increasingly uphill battle as the balance of men to women continued to shift. Combined with programming increasingly being seen as a challenging intellectual endeavor, the latent sexism already present lead to women being increasingly ignored, trivialized, and passed over. Over the next 10 years, you start to see the alarming figures of 80%–90% men in technical positions at the largest, top-tier companies in the software industry.

What to do?

Even better than merely recounting this dismal history, the article actually talks about some places which are successfully counteracting this trend. In particular, I was impressed with Carnegie Mellon’s approach (which has resulted in 40% of students in the CS department being female). Recognizing the difficulty of new students entering the program without prior programming experience, they’ve started offering different classes to incoming freshmen based upon whether they have prior programming experience. By the time these students have gotten through the first half of the degree, they’ve pretty much all equalled out based upon their own natural talent.

The article talks about a number of other positive steps being taken as well, but not without pointing out that many other problems remain unsolved.


I do not accept guilt by association. So, despite the villains of this piece being male, I do not personally feel guilty to share some coincidental characteristics with them. Instead, I see a group of people who have been treated unfairly for far too long, and I find myself in the position of being able to say something against it. This is not about hating men, nor wanting to coddle women. It’s about hating injustice, and wanting to put a stop to it in whatever form, no matter how similar the perpetrator, or how different the victim.

I am proud to look back to all the women mentioned in this article (and the much larger number who weren’t) as fellow engineers who made my career possible. I appreciate them for it, and I’m glad to pass along word of their accomplishments.

Improving your estimates

Estimating most projects is necessarily an imprecise exercise. The goal of this post is to share some tools I’ve learned to remove those sources of error. Not all of those tools will apply to every project, though, so use this more as a reminder of things to consider when estimating, rather than a strict checklist of things you must do for every project. As always, you are the expert doing the estimating, so it is up to your own best judgement.

Break things into small pieces

When estimating, error is generally reduced by dividing tasks into more and smaller pieces of work. As the tasks get smaller, several beneficial things result:

  • Smaller tasks are generally better understood, and it is easier to compare the task to one of known duration (e.g., some prior piece of work).
  • The error on a smaller task is generally smaller than the error on a small task. That is, if you’re off by 50% on an 8 hour task, you’re off by 4 hours. If you’re off by 50% on an 8 day task, you’re off by 4 days.
  • You’re more likely to forget to account for some part of work in a longer task than a shorter one.

As a general rule, it’s a good idea to break a project down into tasks of less than 2 days duration, but your project may be different. Pick a standard which makes sense for the size of project and level of accuracy you need.

Count what can be counted

When estimating a large project, it is often the case that it is made up of many similar parts. Perhaps it’s an activity which is repeated a number of times, or perhaps there’s some symmetry to the overall structure of the thing being created. Whichever way, try to figure out if there’s something you already know which is countable, and then try to work out how much time each one requires. You may even be able to time yourself doing one of those repeated items so your estimate is that much more accurate.

Establish a range

When estimating individual tasks (i.e., those which can’t be further subdivided), it is often beneficial to start out by figuring out the range of possible durations. Start by asking yourself: “If everything went perfectly, what is the shortest time I could imagine this taking?” Then, turn it around: “If everything went completely pear-shaped, what shortest duration I’d be willing to bet my life on?” This gives you a best/worse-case scenario. Now, with all the ways it could go wrong in mind, make a guess about how long you really think it will take.

Get a second opinion

It’s often helpful to get multiple people to estimate the same project, but you can lose a lot of the value in doing so if the different people influence each other prematurely. To avoid that, consider using planning poker. With this technique, each estimator comes up with their own estimate without revealing it to the others. Then, once everyone is finished, they all compare estimates.

Naturally, there are going to be some differences from one person to the next. When these are small, taking an average of all the estimates is fine. However, when the differences are large, it’s often a sign that there’s some disagreement about the scope of the project, what work is required to complete it, or the risks involved in doing so. At this point, it’s good for everyone to talk about how they arrived at their own estimates, and then do another round of private estimates. The tendency is for the numbers to converge pretty rapidly with only a few rounds.

Perform a reality check

Oftentimes, one is asked to estimate a project which is at least similar to a project one has already completed. However, when coming up with a quick estimate, it’s easy to just trust to one’s intuition about how long things will take rather than really examining specific knowledge of particular past projects to see what you can learn. Here’s a set of questions you can ask yourself to try to dredge up that knowledge:

  • The last time you did this, how long was it from when you started to when you actually moved on to another project?
  • What is the riskiest part of this project? What is the worst-case scenario for how long that might take?
  • The last time you did this, what parts took longer than expected?
  • The last time you did this, what did you forget to include in your estimate?
  • How many times have you done this before? How much “learning time” will you need this time around?
  • Do already you have all the tools you need to start? Do you already know how to use them all?

There are loads of other questions you might ask yourself along these lines, and the really good ones will be those which force you to remember why that similar project you’re thinking of was harder / took longer / was more expensive than you expected it to be.

Create an estimation checklist

If you are planning to do a lot of estimating, it can be immensely helpful to cultivate an estimation checklist. This is a list of all the “parts” of the projects you’ve done before. Naturally, this will vary considerably from one kind of project to the next, and not every item in the checklist will apply to every new project, but they can be immensely valuable in helping you not forget things. In my personal experience, I’ve seen more projects be late from the things which were never in the plan, than from things which took longer than expected.


Estimation is super hard, and there’s really no getting around that. You’re always going to have some error bars around your estimates, and, depending upon the part of the project you’re estimating, perhaps some considerably large ones. Fortunately, a lot of people have been thinking about this for a long while, and there are a lot tricks you can use, and a lot of books on the subject you can read, if you’d like to get better. Here’s one I found particularly useful which describes a lot of what I’ve just talked about, and more:

Software Estimation: Demystifying the Black Art

Meditation for Practical Skeptics

I have been meditating on and off since I was a teenager. When I mention it to others, though, they’re often somewhat surprised since I don’t really seem like “the type”. I’m not into eastern religions, energy fields, chakras, or any other form of mysticism. In fact, I’m a very practical, secular, engineer. To me, meditation is a purely practical, secular activity which helps me gain more control over my body and mind.

It’s worth saying what I actually mean by meditation, as there are a lot of different things which fit under that heading. I specifically mean the activity of sitting quietly while keeping one’s thoughts focused on a single idea. Most often, this is just following the rhythm of one’s own breathing, but lots of things could be a good focus.

This is a lot harder than it sounds, though, as you will find a constant stream of distractions trying to draw your attention away. This could be an itch, being a bit hungry, thinking about what you’re going to do next, or worrying about something on your mind. It might even be just some weird random thoughts which keep popping into your head. Whatever it is, it’s surprisingly difficult to sit for any length of time without thinking about anything in particular.

In fact, the distractions are an expected (and even essential) part of meditation. The essential skill is to be able to retain some part of your mind which isn’t distracted, and use that to notice that you’ve become distracted. Then, stop briefly to merely notice the distraction, and allow your attention to glide back to the focus of your meditation. With practice, this gentle re-direction of thought becomes very fast and natural. Once you get really proficient at it, it becomes possible to keep your focus for longer and longer between distractions.

This ability to focus is, for me, one of the two primary benefits of meditating. The more I practice this skill, the more I can quickly and gently turn my attention away from something I don’t want to think about at that moment, and back to something I do want to think about.

The most common time this comes up is when I’m trying to get some work done. This skill allows me to redirect my attention back to my task at hand whenever I get distracted. This allows me to more readily slip into that “flow” state where complex work becomes easy (e.g., writing some difficult bit of code, or a blog post). Or, if its a day where my brain seems all over the place, it at least gives me a tool to try to corral it back where it belongs.

The second time this ability to redirect my thoughts becomes most useful, though, is when I’m feeling stressed about something. My stress often takes the form of endlessly circling around a difficult issue which is outside of my control. I will keep coming back to the issue and imagining worse and worse outcomes until I’m at the breaking point of anxiety and tension. I find that the skills built by meditation allow me to acknowledge the stressful thought, and dismiss it by replacing it with a more productive one.

The second primary benefit I get from meditating is the mental reset it offers. Each morning, just after I’ve finished washing up and getting dressed for the day, I sit down for ten minutes and meditate. For me, this creates a sense of absolute calm: mentally and emotionally. In fact, I’d say it goes further than that: it creates an anchor. No matter how much my day gets stormy and tries to toss me about, meditating helps me carry over some of that sense of calm, cheerfulness, and rationality underneath.


If you’re interested in trying meditation (and I highly recommend it), I recommend downloading the Headspace app. It comes with a free set of guided, 10-minute, meditations lead by an expert. The meditations are completely free of any mystical elements, woozy music, or gimmicks. Just a gentle voice walking you through the exercise. You can stick with the free material as long as you want, or sign up for a subscription (I have) to get access to other exercises. I’ve enjoyed it quite a lot, and I’ve gotten a lot of benefit from it.

Being Approachable: Even as an Engineer

I work with a lot of engineers, and we aren’t always the most approachable bunch.  Between the abstruse jargon of our fields, the deep concentration our jobs require, and the occasional individual who lacks practice socializing (ehem), we can be rather prickly.  I freely admit, as a younger person, I was particularly unapproachable: even compared with other engineers.  However, over time, I’ve learned a lot.  In fact, someone even called me “outgoing” a few days ago.  Given my history, I found it so odd an experience that I started reflecting on what’s changed.

Body Language

The first thing which comes to mind, and probably the simplest, is a conscious use of body language.  When someone approaches me at work, I have learned to deliberately take my hands away from the computer, and square up my shoulders to face the person.  This has the effect of turning me completely away from my computer, and turning my eyes and face directly at the person talking to me.  This unambiguously shows my visitor that they have my complete attention.

The second piece of welcoming body language I’ve learned is to smile and give a warm greeting.  Perhaps its a little obvious, but enough other people I work with don’t do this that it clearly isn’t.  By smiling, I not only make myself seem more approachable and cheerful, but it actually does make me more cheerful.  Even if I’ve been dealing with something stressful or frustrating when the visitor approaches me, smiling almost forces a reset of my mental state so that I’m ready to be welcoming and helpful.

The last bit of body language I’ve changed is to adjust my position so that we share a comfortable distance and eye-line.  If my visitor is standing, I’ll stand.  If my visitor takes a seat, I’ll stay seated.  Either way, I’ll shift so that we have approximately the same posture.  Of course, I don’t pop out of my seat… that would just be weird.  But if a conversation seems likely to be extended, I’ll make both of us more comfortable by matching up with the posture of my visitor.

Active Listening

Another skill I’ve been working on for a long while is active listening.  Briefly, this is when you try to quiet your own thoughts when listening to another person, and deeply absorb what they’re saying.  Then, when they’re finished, acknowledge what they’ve said before adding in your own ideas.  This especially applies when brainstorming or debating with another person.

I think we all find it much, much more natural to be half-way listening to what someone else is saying, and half-way preparing our own response in our head.  However, resisting the urge to do this makes it much more likely that I’ll actually hear and understand what the other person has to say, and that, in turn, will make it much more possible for me to have a sincere and honest conversation with that person.  Over time, as people come to expect this from me, they feel much more comfortable approaching me with whatever question, request, or even disagreements.

Offering to Help

Another major change in my own behavior is that I’ve come to persistently offer to help other people I’m working with.  Even when my time or ability to help is very limited, I try to offer what I can.  Occasionally, this will lead me to over-commit myself (although using GTD helps a lot with knowing my limitations), but often the person either doesn’t need my help (but is appreciative of the offer), or only needs something fairly simple.  Either way, when people come to trust that I’ll always be ready to offer what help I can, they come to feel much more comfortable approaching me with a question, or request.  Even when I can’t always offer much help, they know I’ll freely offer what I can.

Being Optimistic & Action-Oriented

When I think back on all the people I’ve most enjoyed working with, this, above all, is the trait they all shared. By this, I don’t mean being some kind of ridiculous Pollyanna. Instead, think this attitude is contained in the question: “So, what are our options?” When faced with some kind of difficulty, whether its some difficult technical problem, or a difficult people problem, this question re-orients the discussion away from the uncertainty, stress, anxiety, guilt, and/or sadness the situation creates, and toward a positive future where things are better. Also, by asking for options, you start a positive process of working together, instead of attempting to assign blame for the difficulty.


I expect in writing this, I’ve left out a whole bunch of things I’ve learned to do better over the years. I’m equally certain that I’ve left out a bunch of things I haven’t figured out yet. Got some of your own? Leave them in the comments below.

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.

Flexibility with the Pomodoro Technique

When I was a solo founder, I found I needed a way to structure those vast stretches of unstructured time to ensure I balanced getting done everything I needed to with switching between various tasks, and avoiding burning myself out.  I found it worked best to manage my work hours during the day using a variation of the Pomodoro Technique.

For those unfamiliar with it, this technique has you break down your working time into 25 minute sprints where you focus exclusively on work (i.e., no bathroom breaks, no getting coffee, no checking Facebook, etc.) with 5 minute breaks in between.  During the breaks, you can do whatever you like, and every fourth break (i.e., every two hours), you take a 20 minute break.

I find this immensely useful, but I’ve needed to make some changes for it to work best for me.  First, I use 30 minute work periods and 7 minute breaks.  I like the 30 minute time because it makes it easy to figure out how much time I’ve worked in a given day.  I find a good pace for me is between 4-6 hours (or 8 to 12 pomodori) each day.  Second, I use 7 minute breaks because that’s how long it takes me to brew a pot of coffee.

However, there are plenty of times where my day just doesn’t break down this way.  It could be that I have meetings to attend, or I’m working on something very intense and I feel I need a longer break, or whatever.  In that case, I still hold myself to the discipline of being focused during each pomodoro, but I allow myself longer breaks in between.  I also keep track of how many pomodori I’ve completed during the day, and hold myself to getting to at least my minimum number, but no more than my maximum (to avoid pushing myself too hard).

I’ve found this pattern works extremely well for me.  30 minutes on, 7 minutes off.  Take longer breaks as needed.  Set a minimum and maximum number of work periods for a day, and stick to it.