Commitment

Different domains have different relationships with commitment.

In Theatre, commitment is assumed. It’s so common to have someone who is “passionate for the theatre” that it’s completely taken for granted. And as economics will have it, anything that is greatly abundant is worth little and wasted without a second thought.

In Retail, commitment is irrelevant. Like many other domains that lived through the era of “Scientific Management”, team members are seen as interchangeable parts. It is assumed that these parts will do anything other than their job if left alone, and any level of sincere interest in the work is regarded as annoying or suspicious.

In the world of agile teams, however, commitment is essential for developing effective and valuable software. It cannot be defaulted to null, and must not be wasted by assuming its ubiquity. It must be deliberately cultivated and harnessed.

There is a big difference in the level of quality between “I am laying down sandbags sequentially because my boss tells me to” and “I am laying down sandbags to prevent flood waters from carrying away my house and family.”

For the past few weeks, I have been working on a project at 8th Light pro bono for a client. If you ask me what I’m doing I would say “We are building software that will enable Los Angeles youths to improve their lives.” That’s a far cry form saying “We are building a rails app that satisfies contracted requirements.”

Yes, there are still contracted requirements. But those requirements are communicating something greater than the sum of their parts. As engineers, we need to keep that bigger picture in mind. As we work to satisfy the word of the law, we need to take another step and ask if we’re fulfilling the spirit of that law.

That requires a level of attention that simply fulfilling the requirements does not. It requires taking time to consider the ethical ramifications of what we will be building. It requires having courage to raise concerns to the client. It requires suggesting alternatives even if those alternatives mean less short-term gains. It requires a sincere desire to bring value to the project.

It’s easy to be intimidated by a client, or to allow them to hire my hands without my heart, or to shut down and let my boss be my brain. But if I don’t commit, if I allow the world to dictate the terms, then I will end up hurting myself, and since my software will be touching thousands or even millions of lives, I will end up hurting them too.

If I was building software for aircraft guidance systems, that enormous responsibility would be obvious. If my method divides by zero, the plane crashes and people die.

But in the project I’m working on now, that’s equally true. If I don’t make this app right, there’s going to be one more kid out there who won’t have an opportunity. And If I allow myself to not engage, to not ask hard questions, to not fight for the user, then it could be thousands of kids I let down.

As software engineers, we sometimes fail to see past our terminals. We don’t write code for the compiler. We write code to help people. That’s why we have to commit.

And though I have a client sample-size of one, I can see that committing to the work in this way has helped to earn our team his respect and trust. That’s valuable.

But it’s not just me. It’s 8th Light. My teammates, Andrew and Tom bring a level of experience and professionalism that I can’t help but admire. Working in this environment supports and cultivates my commitment.

8th Light is so named because of an old Japanese proverb. There are seven lights in a rainbow that you can see. But there is also an 8th Light that you cannot see, but that you feel inside you. Commitment is clearly part of the frequency of that 8th Light.

I can’t wait to find out more as I continue my apprenticeship.