On how to keep your confidence as a developer

Before I dived into the vast ocean of information technology, I sold matresses. While this was no fulfilling job, it pushed me to interact with people on a level that was previously unfamiliar to me.

Not only did that help to make me a better speaker, it also boosted my self confidence in many ways. With every little success to celebrate, the next one tasted even sweeter.

After 'How to win Friends and influence People', I have recently started to read 'The Art of Public Speaking' by Dale Carnegie, a founding father of teaching interpersonal skills to a broader audience. The first chapter asks you to write a two - minute speech on the topic at hand which inspired me to write this article. And while it came without the focus on coding, I felt it might draw a good picture. So I started to read more about confidence, cowardice and what these two do to people - it would turn out to be one of these rare occasions where I would learn something profoundly useful from outside the IT-world which I could project back into it.

What is confidence?

Confidence is the belief to achieve what the mind can conceive. It empowers one to push themself to their limits and accompolish a set goal.

What is cowardice?

Cowardice is the belief (sometimes the trait) due to which an individual responds risk-aversive to a perceived danger. That means as much as: If the brown thing ahead of me has sharp teeth and comes closer very fast, I should probably run.

What does this have to do with coding?

Be honest with yourself: When was the last time you were a 100% confident your way of coding was the right one? After all, there are plenty of people to proof you wrong about it. Some of them might have a justified cause, others might just be unfamiliar with the way your approached the problem at hand. And then there are the troublemakers.

In the April of 2021, I've encountered an article on dev.to that described the hyping Tailwind.css more or less as a sacrilege of modern web technologies. This post received a lot of reception by putting some of the framework's problems on a huge pedestal. While the author probably meant well and had some valid points, I'd like you to imagine the following situation:

• You're halfway through with a project using Tailwind (or any other technology, really) and are confronted with a trashing like that.
• Fast forward. Your team and you completed the product. You're responsible to deliver the sales pitch and present your results.
• Still, he message of the article still lingers in your thoughts - are you in for a big opportunity or a monumental pile of technical debt?

You get anxious - was the stack you chose a good decision? If you yourself are not convinced of a product's backbone technologies, then how will you convince others?

Be well prepared

Do your research homework. And, after deciding for a certain technology, stick with it. There was a reason why you've chosen it in the first place. If you happen to stumble into a statement as described above, see it as an opportunity to grow. Try to (humbly) proof that you do have a valid point.

Be confident in yourself and your decisions, or others won't be either

Not all of your decisions will ever yield the expected results. Despite your best efforts, the opposition might be right and you'll suffer setbacks and severe damage. So pick up the pieces, reorganize, and then move ahead. Not taking a shot will surely spare you the misery of missing, but also the joy of hitting bullseye

Be the guy that keeps pushing forward

You have probably heard one of the following two statements in a corporate meeting:

• "That one senior has been doing for decades, he's probably right when he says we should do it his way."
• "We've been doing this forever, so we'll keep doing it".
• "Your approach will cost us too much innovative effort. Never change a winning team"

Standing still does no good. The tech industry is a fast pacing one and keeping up with the customer's demands becomes increasingly difficult. The competition is unyielding and unforgiving. If you don't make a move, they will.

On the other hand, in a business context, change always comes at a cost. Especially in jobs concerned with development, resources are scarce and expensive. You cannot confidently move forward into five different directions at once without introducing vulnerabilities and causing collateral damage.

You might be wondering which of the two is better. For most of the situations, I'd say:

Focus on the next step at hand.

Do a single thing at once.

Rather ask for remission than permission.

One moment though. That doesn't mean that you should put on your helmet and move through that brick wall head-first. Instead, if a good idea pops up, pause a moment and:

• Involve teammates. Including those who might be sceptical. Ask for their opinion.
• Make sure to understand the consequences of the wall's destructuring.
• Try to understand which sledgehammer would get the job done.
• Decide on where to start tearing. And then do it.

Once you get started, take no prisoners. Follow your plan and get the job done. If then something goes wrong, take it as a valuable lesson.

Be humble and courageous

No matter how good your way of coding, or getting things done, might be, there'll be people who disagree. However, as long as you keep an attitude that makes you stride for improvement, trust me when I say that you'll be fine.

To wrap this article up, I'd like to again get back people who express themselves like the author of the mentioned article. And while it is a counterexample, I'd like to state: Please don't be that guy. Try to be humble. With that, I don't mean to say that you should not offer critical feedback or speak your opinion, just that you should do it in a sophisticated and friendly manner. Try and encourage people to achieve what their minds can achieve.

Out of curiousity, I've been waiting to publish this post, to see if his words are actually good for something. The followup described an RFC Airfoil, an alternative to Tailwind. The repos he created was touched last the weekend after his followup post.

Speaking towards the author (and anybody who ever wrote a similar article):

I mean you no offense, but I find blowing such a bomb and then not delivering weak. If your intention was clickbait, good job, well done. For the next time, please take note what these posts do to people who already are in doubt.

In a nutshell

The next time you're confronted with a situation that makes you feel anxious, try and apply these principles. Remember:

• It's okay to be anxious, even when you're well prepared.
• Be confident in your decisions. Remember why you made them.
• Don't succumb to bad mouth and toxic people, rather ask for feedback and opinions.
• Failing is not a sign of cowardice. It's okay to be wrong.
• If you're convinced, be courageous - ask for remission rather than for permission.

This post was originally published at https://blog.q-bit.me/on-confidence-and-cowardice/
Thank you for reading. If you enjoyed this article, let's stay in touch on Twitter 🐤 @qbitme