There’s a lot of discussion inside the CS world about imposter syndrome. For good reasons: It’s a topic that resonates with a lot of programmers. We’ve all felt inadequate or unprepared compared to our colleagues.

However there’s a flip side to imposter syndrome: cockiness. It’s not quite as common but every programmer has certainly come across someone who is cocky. Someone who claims that they can get stuff done very quickly, who underestimates problems, who may claim that they understand a topic which they don’t. Maybe this person is you. I admit that I can be a bit of a cocky programmer. I’ve also put a lot of work into not having this cockiness constantly on display. While a little confidence is great for accomplishing tasks, cockiness can quickly become condescending or rude.

You may be thinking at this point, “But wait! I’m not cocky. Why should I read this post?” Well voices in my head, even if you may not be cocky, there are plenty of programmers who are. Which can lead to this common situation:

Sasha and Adrian are programmers working together on a project, say a website in React. They’re at approximately the same skill and experience level. The only difference? Sasha is cocky while Adrian is not. They decide to discuss the implementation plan for the site:

Sasha: This project doesn’t seem too bad. I know React, I’m good at CSS and the requirements are super easy. We don’t even have to implement a mobile site! We can get this done in a week, easy.

Adrian: (thinking) Oh man, Sasha thinks we can get this done in a week? I don’t know…I’ve done a React project or two but I don’t know it. I have some background in HTML and CSS but I’m not an expert. Plus there could be unforseen complications with the site. Sasha’s probably just really good at front-end.

Adrian: Ehh, I don’t know man. A week is not a lot of time. I’d say we should allocate three weeks.

Sasha: Three weeks? That’s a lot. C’mon, this is like my third React project. I can teach you React if you need.

This may seem like an exaggerated conversation. I guarantee you it’s not. You can have two people with comparable skills and get two completely different estimates for a project. It’s why estimating programming time is extremely difficult.

Handling Cocky Developers

What this implies for those of us who are less cocky and more measured in their self-estimates is that just because someone comes off the better programmer doesn’t mean they actually are. Just as the smartest person in the room is not necessarily the person who speaks the loudest, the person who is most confident may not be the most competent.

If you come across a Sasha, someone who is extremely confident, try to gently probe to see if they’re actually as good as they claim. Adrian could, for instance, ask a few questions about CSS to see if Sasha really knows what they’re doing.

Adrian: Could we go over the CSS conventions we’re going to use? Should we do BEM? Or we could use a CSS in JS library.

If Sasha is as good as they claim:

Sasha: Oh I’m not a huge fan of BEM. Generally I use a CSS in JS library, either emotion or JSS, because they automatically handle the modularization problem that BEM solves via convention.

Or if they’re not:

Sasha: Huh. I don’t really know BEM. I’ve mostly worked with SASS.

Bear in mind this may take a little time and deviousness. Cocky developers sometimes don’t like admiting they don’t know something. If they suddenly become aggressive, condescending or very opinionated, it could be a sign that you’re hitting a topic they don’t really know. Don’t take it personally. That’s their weakness, not yours. If Sasha responds with:

Sasha: Wat, no. Don’t use BEM. It’s so stupid. Nobody uses it anymore.

Adrian may be tempted to acquiesce, as Sasha appears to have a strong opinion on this and therefore seems to know a thing or two about BEM. That’s not always true. Adrian should lightly press on, ignoring the insults (whether purposeful or not):

Adrian: Hmm alright. Could you outline why BEM isn’t so great?

It could very well be that Sasha does have a good point and just isn’t presenting it well! That being said I’d say that if someone quickly resorts to generalizations and exaggeration in a discussion, their argument probably doesn’t have legs. If this is true and Sasha starts stammering out weak arguments, then we’ve successfully figured out that Sasha’s cockiness doesn’t translate into actual technical knowledge.

Once we’ve established this, Adrian should decide whether or not to follow Sasha’s point. A poorly informed point can still be right. Besides Sasha is most likely embarrassed, and acquiescing on a minor point could help them get over their embarrassment. The point of this exercise is not to “win” or gain dominance over your fellow developer. It’s to gently push back when working with a cocky developer.

Cockiness can also be a sign of inexperience. Programmers who lack work experience don’t always understand the amount of time it can take to go from idea to implementation to release. I’ve known my fair share of developers who claim they’re almost done when the code has not been tested, reviewed or even run.

When someone says that their code is “done”, I’m mildly skeptical unless I know them to be meticulous. I usually ask a few polite questions to double check that our definitions of “done” line up.

Checking Your Cockiness

If you’re reading this and Sasha’s lines are hitting a little too close to home, you could be a cocky developer. As I’ve said before, I’ve been guilty of cockiness.

How does one keep their cockiness in check? First, try to listen and adapt instead of dismissing. Perhaps Sasha could have responded to Adrian’s concerns with:

Sasha: Three weeks? That seems like a little long to me. Could we go over how you arrived at that figure? I agree we could be a little more cautious with our estimate.

Upon hearing that, Adrian could feel less overwhelmed or intimidated. It’s important to open a dialogue with your fellow students or colleagues, instead of dismissing or creating conflict. Even if you believe that three weeks is the most outlandishly pessimistic estimate in the history of the world (which it isn’t), it’s worth appearing open and receptive to it.

Another good route is to ask a question. Perhaps Sasha could have started the meeting by asking Adrian what their plan is for implementing the site. If I feel like I’m being too overbearing with a developer, I try to find a way that I can learn from them. Every programmer has good ideas or additions.

Try to avoid getting angry or aggressive like in the previous section. It’s okay to not know things. I’ve found that the best people in any field are the ones who ask endless questions, who aren’t afraid to ask the dumb questions. If you find yourself getting emotionally heated, try to lighten up and laugh at yourself. It’s really not that important.

Ask yourself if you’re missing anything or forgetting any potential issues. It’s possible the Adrian’s on your team know something you don’t. Make sure you’ve gathered the project requirements and understand the problem you’re trying to solve. Dunning-Kruger effect is a common explanation for cockiness: You don’t know what you don’t know. If you believe that you’re an expert in an area or understand something entirely, there’s a chance you’re not seeing the bigger picture.

Balance

Being cocky is not always bad. Some people associate cockiness with being a jerk. They can certainly go hand in hand; many jerks in programmer are overbearingly cocky. But there are people I know who are just genuinely very confident in their abilities. And that’s not a bad thing. You need a certain amount of cockiness to tackle ambitious projects. People like Linus Torvalds or Richard Stallman are definitely a little cocky.

Likewise caution is profoundly important as well. You need caution and self criticism to write better code and to ensure correctness. Every good programmer has a checklist of potential issues or problems with their code.

A good programmer should strive for a balance of caution and cockiness.