Skip to content

One of my biggest pet peeves is when another developer tells me that they can’t do something, but offers no explanation or doesn’t investigate to see if it’s possible.

I’m the type of person that when presented with a problem, I obsess on how to solve it. So when a developer would tell me that they couldn’t do something, I would google around until I found a solution. I’d show those solutions to the developers and I was consistently surprised by their responses:

“Oh, I didn’t know that”

“That’s too much work”

“That looks really complicated”

“We don’t have time for that!”

That’s when I realized that “I can’t” isn’t what they actually meant.

Nothing is impossible

When a developer tells you they can’t do something, they’re not actually saying it’s impossible.

Him: When a user takes a photo, the app should check whether they're in a national park… Her: Sure, easy GIS Lookup. Gimme a few hours. Him: …and check whether the photo is of a bird. Her: I'll need a research team and five years. Description: In CS, it can be hard to explain the difference between the easy and the virtually impossible.

With development, nothing is technically impossible, but some things are out of reach right now. I purposefully used this comic as the joke might fly over the heads of some of the youths. (fly…get it?) We can now identify if a picture has a bird in it thanks to machine learning. This 6-year-old comic predicted when we’d be able to do this.

Understanding “can’t”

So what do developers really mean when they say they can’t do something?

It’ll take too long to do

This reason typically comes from a more seasoned developer. They are well aware of possible solutions that would solve the problem. However, they have self-determined that it will take too much time. It’s totally valid to have that opinion, and more often than not, it’s probably the right one. The problem is that they’re making a business decision without including the rest of the team. They might not be aware of how financially-critical something is to develop for the organization. Just because something is difficult, it doesn’t mean you should always pick the option that’s the least amount of effort. Doing difficult things is often what can put your organization miles ahead of competitors.

It’ll take too long to learn

There’s a curious pushback in our industry from a subset of people that think they can learn a language or two and never have to learn anything again. You might be able to get away with that if you’re doing COBOL for an antiquated system, but for the rest of us, that’s not realistic.

Even if you do code in one language your entire career, modern languages are continually evolving, the tooling around it is constantly getting better, and we discover better ways of doing things.

A large part of becoming a senior developer is becoming good at learning how to learn and find solutions. It’s often said the difference between a junior and senior developer is that they’re better at Googling things.

I don’t know how to do this

This type of “can’t” comes from two different types of people.

The first one is typically a more junior developer that’s fresh out of school or a bootcamp where everything they learned was explicitly taught to them. “I can’t” is simply an acknowledgment of their current skillset. They never learned that it’s their job to figure things out themselves.

The other type of person is afraid to share that they don’t know something. There’s not a single day that goes by where I don’t feel like I don’t know what I’m doing. Since everything in development is constantly changing, we have to continually learn new things.

We need to become comfortable being uncomfortable.

It’s unreasonable to put the expectation on yourself that you should know everything or think that others will think less of you for not knowing something.

It’s a bad idea

Rather than debate the merits of an idea, a developer can sometimes shut down the entire conversation if they say something isn’t possible as the other person often doesn’t have enough technical understanding to put up a challenge.

We’ve all known that person that consistently has bad ideas. It can become draining to talk them out of their ideas and it’s sometimes outright impossible if that person has some authority.

Saying “we can’t” is the easy way out, but we need to be professionals. Otherwise, you’ll lose all credibility if it’s ever found out that you intentionally misled them.

I’m overworked

There’s a lot of developers that aren’t in a great working environment. If a developer says something will take 3 months to do, they’ll be asked to do it in a month. Saying that they can’t do something is often just a defense mechanism that’s developed to keep their head above water. If you’re in this situation, all I can say that I’m sorry and I hope you can find a better job.

I didn’t say that

It’s a truism that when we play telephone things get changed along the way. A developer might have given a full explanation for pushing back on something, but the only thing that was relayed was “the developers said we can’t do this.” If you heard it second-hand, talk to the developers directly to get the full story.

Yes, we can…

When someone asks if we can do something, I try to never say “no” outright.

I usually start with “what problem are we trying to solve?”

You’d be surprised how quickly the conversation changes. Quite often, they’re trying to solve a non-issue, their solution doesn’t solve their problem, or numerous other options will solve the problem better. Understanding the problem allows you to solve the problems together as a team, so you don’t ever have to use “can’t” as a defense.

As a developer, I know it can feel like a waste of time to explain yourself when the other person isn’t technical. They don’t have to understand the technical reasons, but they must understand your rationale.

I always try to phrase things in terms of cost/benefits. I explain the different options, walk through how long each solution will likely take, and discuss the cost/benefits of the solutions. Then we determine together what’s the option that feels most appropriate based on current priorities. This is how business and product people think, so you need to communicate in their language if you want them to understand you.

Conclusion

In the end, I suppose I have to thank those developers that said “I can’t”. I used to be more on the design side of things, but them telling me “I can’t” drove me to learn development to prove that we could.

Thanks to Jan Jorensen for contributing some good points to this discussion.