“Can’t” Is No Word for Software Developers

When I write those words, I’ve been working 9 years in software development. Those years have taught me technical stuff, but also a few things that are not about code itself but that leads to good code, and to more.

Those non-technical things aren’t taught at school or in C++ books. Nevertheless, I consider them just as important to produce good code. They’re especially valuable since it took a while of professional experience (at least for me) to figure out.

This is one of those few posts of Fluent C++ that doesn’t show any code snippet, but shows you something necessary be a good software developer, in my opinion.

It’s about the word “can’t”.

The C-word

I realised the importance, frequency of usage and impact of the word “can’t” by reading Game Changers. It’s a book which is not about software, but about improving various aspects of one’s life. It’s written by Dave Asprey. In this book, Dave synthesised his takeaways from podcast interviews with hundreds of individuals that changed the game in their respective fields.

In one of the first chapters, Dave recommends to ban, partially or completely, some words from our vocabulary. The first one is the word “can’t”, and it’s to ban completely.

When you say “can’t” you’re creating a limit, even if an unconscious one. You’re blocking yourself and others from achieving great things.

There is virtually nothing that we “can’t” achieve. Some things we haven’t figured out yet. But with thinking, time or energy, a lot of things we deem unreachable are in fact within our reach.

To prove his point, Dave encourages us to watch around us how often we or the people we interact with write or say “can’t”. I’ve tried, and we do say it a lot. I said it a lot.

“We can’t do that”

As a team lead one of my roles is to assess the feasibility of developments, break them down into smaller bits and find a path of execution.

I used to say expressions such as “this we can do” or “this we can’t do”. But this is a terrible way to express oneself.

If you think you also say “can’t” sometimes, let’s see how we can do better. Let’s consider the various situations where a developer says: “I can’t do that” and try to see what we really mean, and how to go beyond the arbitrary limits we fix for ourselves.

We won’t have the time to do that

If you think that there is too much to achieve given the constraints you’re given (time, budget, etc.), say so explicitly but without the word “can’t”.

“Can’t” creates an unnecessary limit. If you think the project you’re working on won’t give the desired results, it’s a time to negotiate with the business people (PO, PM, insert your favourite acronym here) of the company. One way is to identify the features that matter the most and deliver them first. Or check if some features are quick to implement to get their desired outcome.

But in any case, leave the possibilities open.

We don’t know how to do that

When you’re asked to implement a feature or fix a bug, if you tell that you don’t know how to do it, you convey a completely different message than if you tell that you can’t.

If you don’t know how to do something, there are ways to move forward to help you acquire that knowledge. For example you can agree to allocate a time to figure out a way, for example by:

• analysis the existing code,
• brainstorming between developers,
• discussing with architects,
• finding a similar feature and analysing it,
• asking more experienced developers,

But if you say that you “can’t”, you’re closing the door to any step to move forward and eventually succeed in implementing the desired feature.

We’re downright sure that this is impossible

I once had (in essence) the following conversation with an architect called Damien:

– Jonathan: “I need to implement feature X, but with the framework Y that this code uses, it’s impossible.”

– Damien: “Is it?”

– Jonathan, thinking that “impossible” is in fact not far from “can’t”: “You know what, let me double check and get back to you.”

I was convinced that framework Y wouldn’t support feature X but, for all the above reasons I was also convinced that nothing is impossible for a software developer.

So I dug into framework Y, read more documentation, stepped through the code, thought, stepped through again, read again, thought again, tried, failed, thought again, asked around, tried again, and finally… succeeded.

I had found a way to implement feature X with framework Y.

This was a delightful experience for me who went beyond what I thought possible, for my PO who got what he was hoping for, and I think that Damien was happy too.

There is nothing specific to me, Damien, framework Y, feature X or my PO. This story can happen to any software developer. Our main tool is our thinking, and it can achieve more that we think (I realise now there is a recursion in this sentence, right?).

If you think something is impossible to achieve, think more and try again. There is a good chance it’s within your reach.

“This can’t be”

Another situation where we could be tempted to use the word “can’t” is when looking for the cause of a bug.

Some of the longest bugs to analyse are those where the root cause lies where we don’t think to look. In those cases, we’re so convinced of our assumptions that we think, or sometimes say aloud, that some things “can’t be”.

If the problem is that something we thought couldn’t be actually happened, the longer we stay convinced, the longer the debugging session.

When debugging, it is important to realise that the execution of code is too complex to fit in our brains, that’s why we have computers in the first place, and everything we think about how the code behave is assumptions.

We need those assumptions, otherwise we’d spend an infinite amount of time examining each detail. But an efficient mindset for debugging is to assume that everything is possible, and to assess the likelihood of each assumption.

Once again, the word “can’t” doesn’t help. In debugging, “can’t” can only lead to a waste of time and energy.

“Can” will make you friends

Beyond its dramatic effects on your achievements, the usage of “can’t” can have an impacts on your relationships with other people of the company.

As John Sonmez explains it in his excellent Soft Skills, the job of software developer is a social one. We spend a sizeable part of our day interacting with other people: other developers, QAs, business people, etc.

Greeting the request of somebody with a “I can’t do that” isn’t the best way to foster relationships. Compare it with “I’d like to help you, but I’m currently missing X, Y and Z to achieve what you’re asking, how could we get those?”. Doesn’t that sound better?

In conclusion, ban “can’t” from your vocabulary altogether. Pay attention to when you’re about to say it, or when you write it in an email. If you currently use this word, this change will make you see another aspect of software development.

You will also like

Share this post!Don't want to miss out ? Follow: