Thank you for your patience.

  – The Cashiers Book of Standard Curses


This is a confession.

It’s aimed at those people I have worked with who have described me as “patient.”

I am writing this to confess that I am not patient, nor have I ever been patient.



There is however a limit, at which forbearance ceases to be a virtue.

  – Edmund Burke


I hit rock bottom early in my career.

I had lost my job and was having terrible difficulty finding a new one.

I was seriously considering that I didn’t have what it took to be a software developer. The other software developers I had been working with (who hadn’t lost their jobs) were far more skilled than I was. Also, in the months that I had been looking, I had only managed to land three job interviews.

And I had burned through most of my savings.

But, I continued to apply for software development positions. I didn’t know what else to do.

Eventually, a company I interviewed with did hire me as a software developer.

Patience, n. A minor form of despair, disguised as a virtue.

  – Ambrose Bierce, The Devil’s Dictionary

A few weeks after I was hired, “Bang” was added to the team (I’m de-identifying him as “Bang” because I don’t know anyone with that name).

Bang’s title and job description were identical to mine. He was supposedly more experienced than me since his previous job was more like the one we now shared.

In spite of this, I was promoted to a technical lead position about two months after starting. I was initially uncomfortable with this position which didn’t help with my self doubts about being in the software development industry.

My very first act as a lead was to explain and assign a bug to Bang. The bug went along the lines of “when client code does X with this API it crashes.” I explained the bug to Bang and told him that his job was to solve it.

Quietly yet confidently Bang shook his head and said, “No.”

My first act of leadership wasn’t going as I had expected.

“What do you mean ‘no’!?” I asked.

“The bug says it only crashes if the client code does X – so don’t do X!” was his response.

I was dumbfounded. Nothing like this had ever happened to me. Bang was an experienced software developer. That’s supposed to mean something.

So I had to explain to him how bug reports were triaged by a team of managers and directors, how this bug had been looked at carefully and prioritized, and how it was his job to fix the bug.

“You don’t get to say ‘no’,” I told him.

This was a conversation that never should have happened.

And the honeymoon period with that company soon ended. It was a startup that had one customer and one opportunity to produce a success, and this made the environment very intense.

“There is no plan-B,” the CEO had told us.

I didn’t want to be out of work again.

And I wanted to do right by the people I was working with – 99% of them seemed to be good, professional and honest people.

Me and the rest of the team (we were all new) flourished under this pressure. Except for Bang – months went by and he fell behind.

A frequent pattern I observed with Bang is that he’d ask me for help, I’d give him a good-quality response (like here’s-how-you-do-it or read-this-section-of-this-document or look-at-this-sample-code), and instead of following my instructions he’d stare at me like I had told him to buzz-off. Then he would say “thanks,” get up and leave, and then disappear for three or four hours. I used to find him hiding down in the stairwell or leaning up against a wall outside sleeping.

I’d explain potential solutions to him. I would draw diagrams. I would write out pseudo-code. I did everything short of actually coding for him. Nothing worked.

He was unable (unwilling?) to master simple logistical problems that the rest of the team had picked up during our first week or two:

“Dan! Dan! Dan! Dan! Dan!”

“My network connection is down.”

“My device isn’t authorized.”

“How do I do a production build?”


Beware the fury of a patient man.

  – Publilius Syrus

Things got very intense as our release date approached. One weekend we were all at work, and Bang’s device notified him that it was currently not authorized for network access. He immediately turned to me.

“Dan!?!!?”

“Take it to Bob,” I said. Bob (de-identified name) was part of the DevOps team. The DevOps team had agreed to have someone in the office from 10AM to 2PM on weekends. I looked at the clock: 1:50PM.

Bang just stared at me.

“Take it to Bob!” I shouted. “He’s leaving in ten minutes!”

This was one of the few times I have ever lost my temper in the workplace. Bob was leaving in ten minutes and Bang was failing in his usual manner at an absolutely critical moment.

I had to repeat myself several times before Bang picked up his device, walked it over to Bob (who was only about 100 feet away) and handed it to him.

It may seem harsh that I lost my temper over this, but this was the second weekend in a row we had given up for this project. We had also been working 12 to 16 hour days (some people were actually spending the night at work) for two weeks straight. A month before, we had gone through a similar crunch in order to prepare for an important demo.

This incident was an epiphany to me. I suddenly realized that everything I had ever tried (and failed) to teach Bang I had (a) either taught myself or (b) had been trained on with minimal effort. If I told another member of the team that the solution he was searching for was in this-document or that-sample-code, he would thank me and go look at the document or the sample code. Bang would thank me and get up and leave. I finally realized that there was nothing I could do to help him. Dan helps those who help themselves.

I gave up on him.

The following Monday was still intense. Bang asked me how to do a production build for the fifth and final time.

There’s an ancient Klingon proverb that says, “there’s no such thing as a stupid question.” My retort to that is, “a stupid question is a formerly intelligent question that’s been asked too many times.”

So I said, “Bang, you’ve been working here for months – you should know how to do that by now.”

I went back to work without helping him.

A short time later, Bang notified me that his network connection was down. My response was, “Why are you telling me this? It’s not my job to fix your network connection. You know who to speak to about this.”

I went back to work without helping him.

On Tuesday, Bang was fired.

He’s the only person I’ve worked with closely that was fired for being unable to do his job.

I had two very distinct emotional reactions to the firing of Bang.

The first was real sympathy. It must have been humiliating to go home to his wife and child that night. I disliked working with him but I did not dislike him personally. If he’d been a decent worker, I’d have liked working with him just fine.

But my second reaction was one of relief. Absolute and enormous relief. The fact was that I sat right next to him and he drove me absolutely insane. Nothing but “Dan! Dan! Dan! Dan! Dan!” and nothing I could do to help him. I couldn’t help but feel that my employer had saved me from this near constant harassment. I was very thankful towards our team’s leadership.

Working with Bang and my persistent failure to make him productive had only amplified my feeling that I didn’t belong in the software development industry.

Bang was a parasite. I don’t choose that word as a pejorative, but rather to be descriptive. Bang consumed my time and produced nothing but frustration.

In contrast, I’d describe my relationship with good software developers as symbiotic.

When I showed new hires how to do a production build, they learned how to do a production build.

When I showed Bang how to do a production build, he learned “if I want to do a production build, all I have to do is ask Dan.” Ask Dan is usually the wrong thing to do. Even though I’m great at helping people with design and troubleshooting, usually the right thing to do is at least try to solve the problem yourself.

I learned a few things from this experience.

First, there’s nothing wrong with me. Seriously. This was my first experience being in a leadership position. Every time I had failed to help Bang, I interpreted that as my own personal failure. I thought it was my fault. It wasn’t. It was a problem with Bang. I had to learn this.

Second, my time is important. At any given moment, I am working on something that at a minimum is important and frequently is critical. In order to help a colleague, the first thing I need to do is stop whatever it is that I am doing. Consequently, if I spend time on my colleague, I want to see that time translate into their productivity (which translates indirectly into my own productivity). That being said, I want to say that one of the most rewarding parts of my job is helping and mentoring other software developers. I’m actually a really easy guy to work with.

Third, I learned to differentiate between helping someone do their job and doing their job for them.

I’ve met other versions of Bang since – I can now spot them quickly. And I’ve learned to avoid them. I don’t volunteer to help them, and I don’t go to their desk.

Fourth, I learned to give up quickly on people. In Silicon Valley we have a saying, “fail fast.” What that means is identify a failing path and give up on it sooner rather than later. That way, critical resources (e.g. competent software developers) can be reallocated to potentially profitable projects instead of wasting time on projects destined to fail.

I feel the same way about some human beings.

So, that’s my confession.

To those that have ever come to me for help, or those that I have taught, trained, or mentored; and who also would describe me as “patient” – be aware that that was all on you. You were pleasant and professional people to work with. I enjoyed helping you and teaching you.

To those that I have given up on: you know where you stand.