Giving an excellent technical interview

There are several things I do in my technical interviews which I think make the experience quite a bit better than your average interview.

The first step comes before the actual interview in selecting the technical question. I have a few which I’ve created myself based upon actual problems I faced as a professional developer. They are, of course, somewhat simplified to be able to fit into an interview time slot, but they have the ring of a “real” problem rather than some annoying “toy” problem. Each question is intended to have multiple “extra features” you can add to it, so every candidate is able to complete at least part of it, and exceptional candidates can complete several. Only once have I had a candidate who completed all of the sections I had prepared.

Second, as the interview starts, I deliberately adopt a fairly casual, friendly, outgoing attitude, and chit chat. If possible, I try to crack jokes, and put the candidate at ease. I try to get them to tell me stories about something which will give me a sense of whether they’d be a good culture fit with the company and our team.

Then, as I introduce the technical question, I make a few points right up front to try to take some of the anxiety out of it:

  1. This is a pair-programming exercise, and the primary point is to see how well we like working together.
  2. I’m not particularly interested in seeing how much of the language you’ve memorized; if you’re uncertain on something, just ask, and we’ll look it up, if necessary.
  3. I’m not as much interested in how quickly you solve the problem, but how you approach the problem, and how you think it through.

At this point, I turn my laptop around for them, and either project the screen or slide my chair around so I can see what they’re doing. On the laptop is a basic IDE already set up with a “hello world” program and a simple test case. There’s also a browser with Google brought up.

I think this is the most important part.

I want to make the impossibly contrived interview situation as close to actual working conditions as humanly possible. Starting with a simplified, but realistic problem, continuing with real tools (i.e., IDE and Google), and ending with us looking at the same screen, side-by-side, I’ve tried to emulate, as closely as possible, a situation developers find themselves all the time: pairing up to write a piece of code.

As we start to work on the problem, I try to strike a balance between being a helpful part of the pair programming team, and leaving enough of the problem for the candidate to solve that I can evaluate their performance. The more junior the candidate, the more helpful I am. The more senior, the less. If a candidate seems to be stuck at any point, I’ll suggest a possible solution.

During this process, I will deliberately probe a candidate to see how they react when:

  • I suggest something which isn’t the best solution.
  • I directly contradict a course they had chosen.
  • I point out a minor typo or error in their code.
  • I press them to justify a design choice.

I never interrupt the natural flow of the conversation to do these things, but I always have my eyes open for an opportunity to slip them in. In all of them, I’m looking for the candidate to have the best possible answer in mind, and to neither try to boost their own ego or mine.

As we get to the end, I keep my eye on the time (easy, since we’re looking at my laptop where I keep it up in the corner), and let them naturally stop when we get to the end of a part with somewhere between 5–10 minutes left. At this point, I let the candidate ask me questions for the remaining time.


I think the important take-away here is to try to make the interview feel as much like a pair-programming session on a real problem as possible. Pick a problem which isn’t directly from an algorithms textbook. Set up a real development environment for the candidate (for coding questions). Sit next to the candidate and look at the same screen, just as you would for a pair-programming session (or stand at the whiteboard with them, for a more design-y, less code-y question). Finally, don’t interrogate the candidate, or just let them squirm if they’re stuck; be a good member of the “pair” and help them along.

Go is the founder’s game

I’m currently about two months into founding a company, and, on an unrelated note, I just purchased my first really nice Go board (if you’re not familiar, you’ll probably want to read a bit about Go before continuing). It’s a new game to my wife, so I was explaining some of the basic principles to her this evening, and I was forcibly struck with the similarities to founding a company.

Opportunity cost

Each stone you place on the board during a game can only achieve certain objectives. It may limit the an opponent’s liberties (opportunities for advancement), it may offer your more liberties (sometimes more than one), it might strengthen your established positions, or it might conquer new territory. However, each piece you put down means giving up on other options: sometimes forever, if an opponent takes that place on the board. The best moves are those which do several of these at once.

I find this exactly corresponds to thinking about my business. Every hour I spend on one task is taken away from all the other tasks I might have spent time on. As in the game, it’s very easy spend time on things which are valuable, but not valuable enough. To be most successful, I use the Objectives & Key Results system (from Measure What Matters) to scan the board as a whole (i.e., make goals for the upcoming quarter), and my Getting Things Done (GTD) weekly review to zoom into the details (i.e., select projects and next actions) to pick the best moves I can.

Done is better than perfect

In the game, you often find yourself with a formation (a connected sequence of stones) which is in danger (i.e., about to be captured). In order to save that formation, you need to keep adding stones to it until it is out of danger. However, it’s very tempting to keep adding more stones to make it safer and safer, even though it’s no longer in grave danger (just mild peril). In the meantime, opportunity cost catches up with you. It would have been better to make it “safe enough” and then turn your attention to other, more strategically important, moves.

This is a constant struggle as I work though decisions about my business, since my natural tendency is to make everything “perfect”. For each project I undertake, I challenge myself to find the correct state of “doneness” for the current stage of my business: which is nearly always far, far less than “perfect”. I put “perfect” in quotes because, in the context of getting my business off the ground, taking “perfect” to mean “polished to the utmost degree” is the wrong definition. In this context, the real definition should be “polished to the minimal degree necessary to unlock progress on something more important”.

Keep all the balls in the air

The challenge created by the last principle is that you rapidly wind up with many vulnerable formations on the board at once. With each move, you need to consider each formation to see if it’s in danger of getting taken, or has an opening to extend it to capture new territory. In many cases, an opportunity to start an entirely new formation arises unexpectedly, and now you have one more thing to juggle.

Particularly as a solo founder, this is a daily balancing act. I use my GTD project list to constantly remind myself of the many, varied, projects I have on my plate, and update my action lists daily to deliberately choose which are going to get my attention on a particular day. As I do this, I often choose based upon which important priority hasn’t gotten my attention in a while. Taking this time to reflect is particularly important for me as a technical founder because writing code feels so productive, and therefore can easily absorb an out-sized portion of my time. So, I personally need the constant reminder to keep all the balls in the air: especially those more outside my comfort zone.

Mistakes and sunk costs

Go is a game of capturing territory, and sudden reversals are common. You may be working on building up a certain formation, only to find that your opponent has outflanked you, and that formation is suddenly in danger. If you’re not thoughtful and cautious, it’s very tempting to keep playing more and more stones racing to protect that formation, only to lose it anyway in the end.

The uncertain nature of a new venture means this is a constant danger for my business as well. I need to make a dozen key decisions (and loads more little ones) each week. Most of those are made with too little data, too little expertise, and not remotely enough time to acquire either. Unsurprisingly, those decisions are sometimes sub-optimal, and occasionally terribly wrong. The skill I’m constantly striving to hone is to recognize those mistakes as early as possible: often by seeking out and actually listening to hard feedback. Then, if I discover I’m on the wrong course, to swallow my pride and immediately stop throwing more time and money at it.

Recognizing a lost cause

Most games of Go don’t actually get played all the way until all the stones are on the board. At any point, either player can “pass” on their turn if they don’t think there’s anything productive they can do (it is quite possible to decrease your final score by playing too many stones). If the opponent agrees that there’s nothing productive left to do, then they also pass, and the game is over. I’ve sometimes conceded games where I’ve badly misjudged something within 10 minutes of play (a very short game!). The silver lining is that the sooner you recognize a particular game is over, the sooner you can move on to a game where you’ve got better chances.

Launching a new product starts with a huge pile of hypotheses about what customers want, what they’ll pay, how many people actually want it, etc. And, of course, almost no actual data. The goal, then, is to keep testing hypotheses and converting them into real knowledge of your product, your customers, and your business model. In the happy case, you prove your hypotheses correct, and the business thrives. In the not-so-happy case, you keep finding your hypotheses are incorrect, and eventually, you need to admit that this particular product idea doesn’t have a future. If you’re quick enough to do this, then you might have enough time and money left to try again (and, if you’re extremely good at this, even another time or two after that!).


Of course, many games rely on these principles to some degree or another. And, it’s entirely possible that my current situation makes me see these principles in everything I do. However, I really do think that Go requires these principles so constantly, and to such a stark, obvious degree that it really is the “founder’s game”.

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.

Learning to appreciate the “out” group

A few weekends ago, my wife and I had some friends over for brunch. We had an entirely delightful time. We made breakfast together, swapped stories, joked around, and had a completely wonderful morning. As it turns out, my wife and I are white, and our friends are black. And, as much as I enjoy their company and admire their many accomplishments, I’ve realized I probably don’t appreciate them as much as they deserve.

I grew up in a very white community, and knew only one black person all the way through high school. She was my co-captain of the debate team, and, while we argued some (it was the debate team, after all), I thought very highly of her. But, in retrospect, I also don’t think I appreciated her as much as she deserved either.

However, in both cases, it wasn’t for being too sensitive of my friends’ skin color, but rather for being a little too color-blind.

It’s only been as an adult that the diversity of my group of friends has increased. Over the years, I’ve heard them talk about growing up, their school experiences, their professional experiences, and their adult lives. And only after hearing their stories that I’ve begun to really understand how to appreciate my friends fully. What you don’t really learn when you’ve always been part of the “in” group, is what it’s actually like to be part of the “out” group.

I’ll stop here a moment to say that while I’ve been part of enough “out” groups (e.g., nerdy, Jewish, bisexual) to have some inkling what it’s like, my experiences as part of those groups is far, far more mild than what I’ve heard from my black friends. So much so as to basically not be the same experience at all. I’ll also pause to say that I think the same applies to anyone who isn’t with the “in” group for whatever other reason (e.g., recent immigrants in an English-speaking business, women in engineering, men in nursing, or gay people in a conservative community).

Every company I’ve worked at has been overwhelmingly homogeneous on many axes. And, not all of the people I’ve worked with have much sensitivity toward “out” groups in general. So, when I start to imagine the sense of isolation it must engender being part of a small “out” group, I start to have an appreciation for the determination and self-confidence it must require to show up, and keep coming back: despite not fitting in with the larger group in some way.

And then, there are all the stories of people in an “out” group being passed over because they just don’t seem like management / leadership / whatever material. Or because they “don’t quite click as well” with the rest of the team, or whatever other squishy, hard-to-refute, but nevertheless-bullshit reason. One has to admire the grit and resolve it takes to decide to persevere through such an experience. And then you realize that every person you meet in such an “out” group may well have had to deal with that kind of thing personally.

Or maybe not. Perhaps they were lucky, and didn’t have those negative experiences. As always, making blanket assumptions about an individual based upon some inessential characteristic is dangerous. However, we all do it all the time: at least at first. You can only learn so much about a person in a first meeting, and it takes time to learn their actual history, struggles, and accomplishments. So, in the interval between meeting a person and deeply getting to know them, we all make lots of inferences from what little we do know.

My takeaway, then, is that in early stage of building a friendship with someone, it’s actually not fair to be as perfectly egalitarian as I’d like the world to become. For someone in an “out” group, the accomplishments I see and admire may very well have come at higher cost or effort than I would have expected. As a consequence, a person in that situation most likely deserves some extra credit for the extra friction they’ve had to overcome.

Of course, I fully expect this is all super obvious to anyone who isn’t part of one of the important “in” groups in their life. However, we of the “in” group are mostly so uncomfortable talking about this kind of thing, that it’s not at all obvious to us. I know I’m uncomfortable writing about it now. I feel more than a little blind that it’s taken me so long to become sensitive to it. It’s only after having enough conversations with my friends who are: black in a mostly white environment, female in a mostly male environment, gay in a mostly straight environment, etc. that the broader understanding has come to me.

So, in addition to the earlier takeaway, I’m left with an even more important lesson. It’s admirable to desire and work towards a world which has left racism, sexism, homophobia, etc. behind. However, until we get there, it’s not right to let the vision of that better world make us fail to give due recognition to people whose success comes a little (or a lot) harder because of the world we’re actually in.

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.

Building a Minecraft Modpack

I’ve been a huge fan of Minecraft for about seven years now. However, the basic game, while fun for a while, does tend to lose its interest after a while. Fortunately, there’s a huge universe of free add-ons, called “mods”, created by the community at large. In fact, there are so many that you couldn’t possibly just add them all to your game. So, the question is, how do you select which ones you’d like to have in your “mod pack”?

1. Choose a theme

I always start by choosing a theme. The easiest theme is to pick one mod you especially want to try out, and then select a bunch of other mods which complement that mod. So, for example, the last modpack I built started with a very realistic railroading mod called Immersive Railroading. From there, I picked a mod which adds a bunch of Victorian-age technology, some mods which add more food and crops, some which add more realistic biomes, and so forth. However, everything I added was required to fit the theme of Victorian-age railroading.

There are, of course, a lot of other ways to select themes. Perhaps you want a modpack based around space exploration, or one based upon super realistic wilderness survival, or exploring magical realms. Whatever you pick, let that be the guiding principle around all the rest of the choices you make, because there will be a lot of choices!

2. Select your Minecraft & Forge versions

Minecraft releases updates periodically which then requires the authors of each individual mod to make adjustments to their mods. For minor version updates, these are usually minor changes, but between major version updates, these can be quite substantial. For example, the changes between versions 1.7 and 1.8 were so substantial that the massive Lord of the Rings Mod is still only compatible for Minecraft 1.7.10, which was released in June 2014! All else being equal, my rule of thumb is to pick the newest version of Minecraft which has been out for 6 months. However, if a certain mod I really want to use is only available for older versions, I’ll fall back to the newest version it supports.

Nearly all mods these days rely on Minecraft Forge, a low-level interface for mod programmers to interface with the game itself. If you’re interested in building your own custom modpack, you’ll also need to pick which version of Forge to use. My rule of thumb here is to pick the most recent “stable” version available for my chosen Minecraft version.

3. Select candidate mods

The first phase of your many, many choices will be to pick out a bunch of mods which might be a good fit. I usually do this by going to the CurseForge Mods List, filtering by the Minecraft version I’m using, and sorting by most popular. I’ll briefly consider whether each mod might be a good fit with the theme of my modpack. If so, I’ll download the version which fits my Minecraft version.

In this phase, I almost always wind up with way more mods than I could reasonably fit into the modpack. I also wind up with a bunch of mods which might seem to fit the theme, but wind up not. Or, I might wind up with a bunch of mods which provide nearly identical functionality. Thats fine at this stage, but we’ll want to start narrowing things down in the next stage.

4. Mod exploration

Next, I’ll take each mod, one at a time, or in small groups which are closely related, and try them out. I often do this in creative mode so I can just tinker with the stuff the mod adds, and form my own ideas about how well it fits the modpack, and whether it’s a fun addition to the rest of the pack. I particularly try to weed out anything which seems too buggy, poorly balanced, or duplicates too much from another mod I like better.

As you’re working through this stage, you’ll often find a variety of errors and problems. Frequently, it will be that the mod you selected requires some other mod which you now need to go find and install. Sometimes, this will turn up a mod which requires a newer / older version of Forge than you’ve selected. In that case, you need to be very careful about upgrading / downgrading as you might run into even more problems with other mods which were happy with the version you already had!

I also try to make sure I fully understand what each mod does during this stage. This will often require tinkering with the config files to see what options are available, whether items I don’t like can be eliminated, and whether various things can be made easier or harder. I’m also looking for how well each mod interacts with related mods. For example, if I’m adding a mod which uses electrical power, I try to figure out if it can interact well with the primary mod(s) I’m using to provide it.

5. Down selection

By this point, I’ve got a pretty good idea of what each of the mods do, and how well they integrate with the other mods I’m considering. At this point, I’m trying to pick one and only one mod to serve each of a bunch of various functions in the game:

  • tweak the game’s UI
  • alter fundamental game dynamics
  • control terrain generation
  • control ore generation & add new ores
  • add additional biomes / control biome selection
  • add additional mobs: passive & active
  • additional trees, plants, flowers, crops, etc.
  • control mob spawning
  • add electrical power (if applicable)
  • add a system of magic (if applicable)
  • add helpful items to the game
  • customize recipes & remove items

Of course, one can’t always isolate each of these functions to a single mod, but the goal is to at least get down to a set which don’t directly compete with one another in strange ways (e.g., Dynamic Trees adds cool growing trees… but they don’t work with trees added by the Forestry mod).

This is the stage where you make the hard choices of which ones win out, and which get removed. It is often the case that a whole bunch of mods all work together very well, and some one mod has a bad interaction with just one of them. Sadly, this pretty much always means that you have to nix the “some one mod”.

6. Configuring by layers

If you take all the mods you’ve selected and activate them all at once, you pretty much always run into a mess of errors and incompatibilities. I like to tackle this problem one layer at a time. Using the list from step 5, I add in all the mods which deal with each item in the list at once, and then start up the game. Hopefully, you already worked out the hard crashes and incompatibles abck in step 4, so the problems you run into now are just ways in which these mods interact that you simply don’t like. Go back to the config files for each mod, and fine-tune the settings until that layer is working just as you like. Then proceed to the next layer.

With each layer that you get working to your satisfaction, backup your complete setup. It’s very easy to accidentally introduce problems which don’t become apparent for a while, so you definitely want to be able start over from the last thing you had working pretty often.

7. Play testing

Once you have the configs all set, it’s time to really test things out. There are a number of things I’m looking for at this stage. Some of them can be tested in a creative world (usually much faster and easier), but many can only be tested in survival (where the availability of resources and chains of recipes become important). Here’s a list of things I’m looking for as I do my play testing:

  • Is it easy to stay alive in survival through the first full day?
  • If certain resources are key to your various mods, are they readily accessible?
  • Are resources which are intended to be rare actually hard to find?
  • Do mods which are supposed to interact with one another actually do so successfully (e.g., do the HarvestCraft plants work with your Agricraft crop sticks)
  • Do mobs (active & passive) show up where and when they are supposed to, and in acceptable numbers?
  • Do you get crashes when you do anything, or visit certain places?
  • Does the overall world generation match your expectations / purposes for the modpack?

Ideally, you’ll be able to pull together a few people to play the modpack a bit on their own (both in creative and survival) before committing to using it on your server world.


I hope this helps make the rather daunting process of putting together a substantial modpack a bit easier! It usually takes me about 20–30 hours to get all the way through this process for modpacks with around 100 mods in them. For an example of a modpack I put together this way, check out Brunel on GitHub. Enjoy!

Is blaming the victim always wrong?

I’ve noticed this strange pattern of how people talk to one another about certain kinds of crimes: most especially rape against a female victim. The dialog usually starts with someone (almost always a man), saying something like “she was dressed too provocatively”, or “she shouldn’t have drunk so much”. This is immediately following by someone else (usually a woman) saying something like: “she should be able to dress however she wants; it doesn’t give anyone the right to rape her”.

First, I think we can all agree that there is no such thing as a right to rape anyone, for any reason, at any time. Doesn’t matter where they are, what they’ve been doing, how they’re dressed… full stop. No one is morally allowed to rape anyone else. If we can agree on that point, then we can also agree that it is in no way a woman’s fault for getting raped: no matter how she’s dressed or what she’s been doing.

It’s rapists who are at fault for raping. We should focus on teaching them not to rape, or, at the very least, providing some massive disincentives to do so. Right? Right. Of course. Rapists shouldn’t rape.

Now that we’ve got that settled… everyone will be fine, right?

Of course not.

Immoral people will always exist, and while we will always condemn immoral actions and try to educate / reform the people to commit them, that doesn’t actually do any good for someone already victimized by a criminal.

That raises the question of what are our moral obligations to looking after ourselves: especially in a dangerous situation. Let’s change the example. Let’s say I (a man) am walking through a bad part of town, at night, alone, in a smart suit with gold cufflinks. And, I get jumped. They take my wallet, cufflinks, and phone. They beat me up pretty well, and knock out a few teeth. Hell, let’s say I even get raped by one of the thugs, who happens to be gay. What responsibility do I bear for this event?

Clearly, I am not guilty of assault, robbery, or rape. I did none of those things, and the guilt for all of them lies completely on the thugs. Am I guilty of anything, then? Yes. I’m guilty of failing to properly assess the danger of my situation and taking sensible precautions. I have a moral responsibility to myself of looking out for my own person and property. In this case, I failed to do so.

It is crucial to differentiate between the level and nature of moral guilt here. The thugs are, without question, far more guilty of a much worse action. They deliberately, and purposefully, initiated violence against another person. On the other hand, I carelessly neglected my own safety. On the one hand, you have a egregious fault of morality, and on the other hand, a minor lapse—even if it had severe consequences. The difference in guilt here is so extreme as to practically bear no comparison.

I think this is the essence of the strange verbal exchange which started this essay. One mentality looks at a crime victim, and thinks the victim should have done more to protect themselves. The other looks and the criminal, and says we should prevent crime.

Both of these are correct stances. Both parties did something wrong. However, since these are not remotely equivalent wrongs, it is outrageous to focus one’s attention on the minor fault committed by the victim, instead of focusing on the immeasurably greater guilt of the criminal. And yet, one routinely hears more attention given to the women’s clothing, activities, or appearance after a rape than on the criminal.

So, yes, it can, sometimes, be proper to blame the victim, but absolutely not for the crime. At best they failed to take some necessary precaution (though even that doesn’t apply in most cases). They can—in no way—be blamed for the crime itself. The moral culpability for the crime is always 100% on the criminal.

Process is not a four-letter word

As a software engineer, I’ve worked with a lot of different development processes over the years, and I’m a pretty big fan of a number of them. Also, as a Getting Things Done (GTD) fan and advocate, I have a pretty rigorous process I’ve imposed on myself for doing my daily work. However, I constantly hear my colleagues decry “process” as an unnecessary burden, and look to eliminate it whenever possible. I think this attitude is somewhat mistaken at best, and actively harmful at worst.

Let me start, though, by being clear what I mean by “process”. A process is the means by which something gets done. Using that definition, if you get anything done at all, there was some process by which it happened. It could be a good process, a bad process, or even just plain trial and error. It’s still the way it got done.

So, process clearly isn’t actually the enemy here, since we all like to get things done. Really, the problem my colleagues are reacting to is having a bad process with too many unnecessary, laborious, or complicated steps. This is definitely a problem, but not the worst one you could have.

The worst is having no process at all. Of course, that’s not actually possible, so really what this means is that your process is made up as you go along, on the spur of the moment, each time you try to accomplish something. It may feel good not be restricted from tackling the job in whatever way occurs to you, but you’re very unlikely to take the optimal path from concept to completion. Instead, it’s very likely that pieces will be missed along the way, thrown back in haphazardly, not completed in time, or in the wrong order, and stakeholders will be unaware of what’s going on, or when to expect results.

The worst part of this ad-hoc process is that you’re doomed to repeat the same chaos every time you do it again. Since everything was made up on the spur of the moment, you’ll most likely wind up doing it a completely different way next time. Any lessons learned about what worked and what didn’t (even if you’re able to recall enough of what you did to try to analyze it), won’t be applicable the next time.

The essence of process improvement is repeatability. If you can reliably repeat the same sequence of steps each time, you now have a chance to: 1) clearly understand what you did, and 2) deliberately make changes the next time.

So, one step better than total chaos is what most people think of when you say “process”: a clunky, cumbersome, set of steps which create a lot of unnecessary busywork for those trying to accomplish the goal. I say this is still better than no process at all because it is repeatable. That means, you can tweak the process each time you repeat it to make it better.

The very best processes, of course, are those which only include exactly as many steps as are necessary to ensure the right work is done, done well, and all the right people know what’s going on at each step along the way. The problem is that it’s not always possible to predict what steps those are, and whether those will continue to be the right steps in the future (e.g., as the team grows, or the problem gets more complex).

That leads you to the real goal: to create a process which includes a means of improving the process itself. There are many examples of such processes (SCRUM, Kanban, etc.) when they are practiced well. In those cases, the built-in self-correcting nature of the process allows the details to change to adapt to new circumstances.

Of course, this ideal implies a few failure modes. One is to adopt a “we’ve always done it this way” sort of attitude which fails to allow for refinement, growth, or adaptation. Then, no matter how good or bad the process is at any given moment, you’ll never get better. And, as times change, the process will suit the current situation worse and worse.

A second failure mode is to change lots of thing with each repetition. It is very hard to successfully and consistently change a habit: even when you’re only trying to make one small change. This becomes nearly impossible when you pile on too many things at once. And, even if you managed to do it, it’s very difficult to judge which changes had what outcomes. Better to keep things simple and tackle one change at a time.


As I said to start, a “process” is the means by which something gets done, and any time something gets done, there was a process by which that happened. Instead of treating “process” as a four-letter-word, I think we should embrace it. Whatever process you’re following for whatever goal you have, start by striving for repeatability, and then—bit by bit—keep making it better.

Organizing Members of a Class

In all the coding books I’ve read, I don’t recall any of them specifically talk about organizing the different members of a class.  However, in all the code I’ve read, the lack of any standard or order to how members are organized has been the single biggest obstacle to feeling at home with a new codebase.

The reason this matters so much has to do with our brain’s limited ability to keep track of a lot of things at once.  If we can only keep a few things in our head at a time, then it becomes hugely important for the readers of our code that we provide a hierarchy which doesn’t demand they understand more than a half-dozen or so sections at a time.  Moreover, it’s super important that these be immediately recognizable, and that they be in a consistent order so that they can be easily found.

Using Dividers to Create Hierarchy

The way I create an immediately recognizable sense of order is to create visual markers which clearly mark each section of a file. So, for example, let’s consider just the bare framework of a module in Python which contains two classes:

from some_package import a_module




class TheMainObject(object):

    def __init__(self):
        # do constructor stuff

    # Properties #################################

    def alpha(self):
        return self._alpha

    def alpha(self, value):
        self._alpha = value

    # Public Methods #############################

    def calculate(self):
        # calculate a value here

    # Private Methods ############################

    def _private_calculation(self):
        # do some private calculation


class SomeHelperObject(object):

    # etc, ...

The first section (lines 1–3) contains all the imports. One of my favorite things about Python is that this gives you a complete listing of external dependencies, and an exact listing of where they are all coming from. Someone reading module can, in an instant, scan this very first section to see everything that’s coming in from the outside.

Next, I put in a full-width marker line with no label. As this indicates the top level of your hierarchy, it should be the full line width your team allows. That way, it’s immediately clear that you’re moving from one top-level part of the hierarchy to another when you see one of these lines.

The next section contains a few constants. These are clearly to be used across all the major sections of this module, and possibly even outside it.

Next, we have the class initialization section for the first class (lines 11–16). This is where the actual class declaration lives, along with any constructors. The semantic meaning of this section, while not explicitly labeled, it pretty clear: we’re setting up the class here.

Next, we have a subdivider labeled “Properties” followed by all of this class’s property declarations. If we had multiple properties here, they would each be listed in alphabetical order (more on this later). It’s important to note that this is a sub-divider, and is therefore shorter than the primary dividers since it represents the second level of the hierarchy. It’s important that it be enough shorter (15–20%) than the primary dividers that it be easy to see the difference even at a quick glance.

Next are the public methods, followed by private methods. As additional members of the second layer of the hierarchy, they use the same dividers. This pretty much covered your bases for most languages.

Sequencing and Sorting

With the visual hierarchy in place, then next thing I consider is the ordering of each element of the hierarchy. Since code is read far more than it is modified, my general approach here revolves around attempting to make the code as easy to read as possible. To that end, it’s important to keep the various levels of the hierarchy in as predictable and clear an order as possible.

For the top level of the hierarchy, we’re talking about sections for defining classes, constants, imports, and (depending upon your language) free-standing functions. In many languages, you’re required to list imports first, plus, that ordering has the advantage of making it clear what this code depends upon, so it’s useful to keep them up front. Next, I list the constants which are going to be used throughout this file. Next comes the primary class in the file (if there is one). Finally, come the sections for helper classes. In most cases, the part of the file you can readily see without scrolling down contains the imports, constants, and the start of the primary class section. So, in a single glance, the reader of the code can easily see what is the primary purpose of this file and what its dependencies are.

In the second level of the hierarchy, at least for a class, we’re mostly looking at various groupings of methods. I arrange these sections in order from most public to least. The reasoning is that a reader of the code is most likely to want to use the class, and then to inherit from it, and finally to actually change its implementation. This ordering addresses those various needs in order.

The third (and final) layer of the hierarchy consists of the members themselves. In 99.99% of cases, I simply sort these in alphabetical order. It is extremely tempting to try to order these in some “logical” order, but I have found that almost always leads to chaos. The reason is pretty simple. At first, the “logic” is pretty clear. The original author knows what the rational is, and puts things in that order. However, when the next author comes along, perhaps the logic of the ordering isn’t super clear. Maybe the next author is a little lazy. Perhaps they need to add a member which doesn’t fit into the logical scheme the other members follow. Inevitably, though, members start to be added wherever it “feels” like they seem to fit: or merely at the end of the list. Sooner or later, the only organizational scheme a new author can discern is: random.

Alphabetizing the list of members solves all these problems. It’s obvious from very brief inspection what the scheme is. That makes it obvious where to find an existing member, and where new ones should be added as there is only one correct place for each member. Moreover, it helps keep code diffs very easy to read and understand as there is a lot less movement of code from one change to another. Finally, it makes it extremely easy to tell whether a certain member is present or not (e.g., whether a certain method has been overridden).


I have worked in at least a dozen different languages from PowerPC Assembly to C++ to Python to Go. In each one, I apply the principles of establishing visual hierarchy and creating an objectively correct ordering of elements in the file to ensure that the ultimate goal of making the code obvious and readable are satisfied. It doesn’t matter what the language is, whether it’s Object-Oriented, or what other conventions the language encourages. I find applying this framework makes my code immediately recognizable and earns praise from other developers for being among the most orderly and rational code they’ve ever seen.


Want to see these techniques in practice? Check out some of my code at

What I’ve learned in 20 years with my wife

In a little over a year, my wife and I will have been married for 20 years. I was 21 years old when we got married, and 17 years old when we started dating. So, it’s been more than half of our lives that we’ve been together. And, unlike many couples we’ve known, we’re even more happy together now than we’ve ever been. I’ve been reflecting on why that is, and there are a number of things I attribute it to.


We both have a deep and reverent respect for one another. Ask anyone who knows us: we are two very different people. Instead of making this more difficult for us, though, I find that we often hold one another’s differing abilities in awe. To a large degree, I think that’s possible because we both have a great deal of respect for ourselves, and we’re able to view our partner’s superior talents with delight and admiration, rather than feeling threatened by them.

Likewise, we each have very different struggles. When one of us feels the need to improve ourselves in some way, the other is invariably sympathetic, honest in their feedback, and kind in that moment of vulnerability. And, when that person makes progress, the other is there to cheer them on, and applaud their success.


It’s terribly clichéd to say that the essence of a long-lived, successful relationship is communication, but that doesn’t mean it’s not true. What I always find dissatisfying about such advice, though, is that it’s not nearly specific enough. What isn’t said that that the most important part of communication is for each person to really, actively, listen when the other person is talking. This is most especially true when the other person is sharing an uncomfortable truth, either about themselves, or about the relationship.

If I’m the person doing the listening, that means that I am actively trying to understand my wife’s point of view before formulating one of my own. Most importantly, I keep quiet while she’s talking. At intervals, I might echo back what I think I’ve heard, and ask for her to correct anything I’ve misunderstood. I might ask clarifying questions where I’m uncertain. I’ll often ask her to elaborate on certain points I think may be connected.

Most especially, there are a number of things I do not do while I’m the person listening. First, I do not deny the truth or validity of her opinions and emotions. I might question facts, but if there’s any disagreement, we immediately turn to some source of actual evidence, or just let that point go. We both try to avoid the desire to be the one who was “right” and “won” the point. I also try not to jump in and “solve” the problem until she’s had her full say. Even then, I try (not always successfully), to ask her what sort of help (if any) she actually would like, before offering suggestions.

And, to be clear, we both play both roles here. There are plenty of times (more often, in fact), when I’m the one bothered by something, and I need someone to listen while I work through it aloud. In such times, my wife is invariably a patient and insightful listener.


Since the start of our relationship, we have faced the world as a united team. In fact, when we first got engaged at 18 and 20, we faced a fair amount of skepticism by standing together, and deciding how we jointly wanted to respond. Countless other examples have followed: when I got a new job out of state, deciding whether to have kids, and many others. No important decision is made without talking it over together first, and we value each other’s advice and opinion so well that we will often consult each other on relatively minor issues too.

Part of that teamwork, though, is trust in the other person to follow through as a member of the team. This applies both to what we say we will do (e.g., I look after our investments, while she looks after our health care), and what we say we won’t do (e.g., spend large sums of money, have relationships outside our marriage). This isn’t blind trust either: after all this time, we both have given and received ample evidence in big and small things that the other person is worthy of being trusted.

Deliberate Time Together

We are both people who get very engaged in our work, projects, and hobbies. We have careers, a house to manage, a son to raise, and more than enough to keep every hour of the day overflowing with things to do. However, pretty much since we both started working full time, we have deliberately maintained a weekly date. We’ve usually made it some kind joint lesson or another (e.g., flute, clarinet, ballroom dance, singing), or an activity we both enjoy (cooking, dining out). We generally change the activity at least once a year, either as circumstances change, or just to keep it from getting dull.

One of the most important aspects of these dates is the time surrounding the activity where we can talk. It has proven essential for us that there’s enough time that you get past the “How’s your day been?” level of questions and down to the longer-term, difficult, or uncomfortable conversations. I remember that a lot of these happened around when I came out. Over the past couple weeks, these have been about our son’s transition into a simultaneous High School / College program where he’s struggling a bit. These are the kinds of conversations which cannot happen in the ordinary rush of day-to-day life, and we have found it essential to deliberately carve out space to make sure they can happen.

Deliberate Time Apart

Just as we deliberately plan time together, we also deliberately give each other space to be individuals. Not all activities, friends, and hobbies need to be shared. Again, this seems obvious, but I also see plenty of couples where one person feels left out or hurt when their partner wants to go do something on their own.

As an example, when our son was a toddler, and my wife was the stay-at-home mom, there came a point where I could tell that she was very much in need of some time off. So, I planned a trip which had her drive away, alone, in her car with a box of envelopes with numbers on them. This lead her through a scavenger hunt to pick up some of her favorite treats on the way to a weekend stay in a lonely B&B on the coast of Washington state. She had nothing to do, no obligations to anyone, and everything planned out for her in advance. A few months later, after I’d just gotten a new MINI Cooper and finished a stressful project at work, she arranged a similar trip for me high up in the back roads of the Cascade mountains with a new book. We were each thrilled with our own trips, but would not have enjoyed the other person’s.

As another example, I enjoy playing video games (something I share with my son), but they make her motion sick. She loves singing in a chorus, but that’s just not my thing. Every once in a rare while, we’ll share in those activities, but mostly we’re very supportive of the other person spending some time alone with their hobby.

Physical Intimacy

Yes, sex is definitely important in our relationship. However, there’s more to it than that. Anyone who has seen us together will attest that we are constantly touching each other in small, loving ways which have nothing to do with sex. Hugs, kisses, holding hands, snuggling in our big armchair to watch a movie, or even just a light caress as we walk past one another are constant and daily occurrences. This is a constant reinforcement of the sense of closeness and intimacy we share with our favorite person.

As for actual sex, we apply the principles above. We have different levels of interest at different times, we each react physically to different things, and we each are different in desire to try new things. We negotiate those differences by respecting each other’s limits (while still asking for what we each want), actively listening to what the other person likes, and being deliberate in setting aside time to make sure that part of our relationship doesn’t get buried in the daily grind.


I’m positive there are a bunch of things I’m missing, but I feel like these are the most important ones. Of course, these are the things I think have made the most difference in our relationship with our particular personalities. I suspect, though, that most couples will find these principles apply to them as well.