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.