
Why lack of confidence can make you a better programmer - itamarst
http://codewithoutrules.com/2016/08/03/self-confidence/
======
barrkel
This cuts both ways.

You need a lack of fear to delve into the unknown to fix the root causes of
things, to follow a thread all the way through an application and not make the
minimal local change that invariably hurts the overall design of the software.
This is how maintained software rots: lots of local changes without regard for
the global design. Making the bigger change (usually not actually bigger, just
more global) is required to keep the architecture supple.

But you need to be concerned about breaking stuff. Everything you touch, you
need to look at what relies on it. If testing is insufficient, it should be
beefed up beforehand. Often testing is at the wrong level and is too closely
linked to implementation changes, preventing the more global change required.
It's less fear, though: more like paranoia combined with obsessive, iterated
list-making + list-checking.

The worst thing is when you find yourself hours or days into a task only to
hit a blocker - finding out that doing the right thing will be a lot harder
than expected, while doing the hacky short-term thing will be unreliable or
fragile or otherwise difficult to maintain.

So you need to start out with a research phase. Think through the code changes
required for a local change, look at the component parts, consider how they
could change to make a more global fix, then look at their dependencies, test
coverage, etc. until you're confident the task can be accomplished. Think
before acting.

Acting without enough thought and planning is the biggest problem I've found
with junior devs. I've found it at both extremes of the "fear" discussed here:
some devs that had no fear and made big global changes without considering the
knock-on effects, who broke all sorts of other bits and pieces along the way
that weren't central to their task so they never even checked them (these devs
generally don't last long); and other devs who hyperactively make local
changes, use a lot of copy and paste (including tests - the code turns out
functionally correct), and generally seem really productive, but are actually
generating technical debt.

------
dworin
There's actually a lot of research about confidence (and an entire pop-
psychology book on the subject).

The basic finding is similar to what the article says: too much confidence is
bad because it makes you miss things, but so is too little confidence if it
makes it hard for you to do anything. The trick is calibrating confidence and
how you react to under/over-confidence.

In a situation of low confidence, you want to take action to grow your
confidence by getting feedback, learning new skills, or collaborating to get
new ideas. When you have too much confidence, you need to figure out what
you're missing or get a more realistic perspective on where you are.

For better or worse, there's also social value in projecting confidence (not
arrogance, but confidence) in certain situations.

~~~
matwood
I feel like my confidence is usually in the right balance. I have enough to
feel like I can build something, but not so much that I refuse to test and
check that it works. On new projects where my confidence is lower, my first
few PRs can take me forever as I examine every little detail for correctness.

------
50CNT
"unrealistic self-confidence" is usually termed arrogance. If you are an
arrogant programmer, you will make mistakes of judgment because you're acting
on wrong assumptions.

Regarding actual "self-confidence" based on a proper assessment of self-
efficacy, I find it makes me a better programmer. It allows me to experiment
and play more freely.

When I was a wee young lad, I used to be very scared of the command line. I
read that you could really mess up your system with just a single typo. This
imagined danger held me back from learning things. With my unfounded fear,
even testing something like "python3 script.py" would make me double guess
each character I wrote.

Now, I know that I can just reinstall the system if I mess up. Or play in a
VM. There's negligible danger to that. With prudent precautions, I can afford
to be bold with it. Pull up a virtualbox, and do a "rm -rf" and see how it
burns. I believe playing with a system, breaking it and fixing it is necessary
for getting a feel for it. You can't do that when you're scared our doubtful.

~~~
marcosdumay
There's a fine line between enough confidence to know your precautions are
sufficient for playing up with the system, and not enough confidence to know
you need sufficient precautions.

When destroying a local system on a VM, the line is very easy to find. When
developing components in a large system, it's almost impossible to locate.

~~~
50CNT
I think large systems would benefit from "playgrounds" as well. Staging
servers are a thought in that direction, but they're a very serious matter
designed to root out failures before they destroy a production system.

I think it might be useful to have a playing server/system as well, similar to
the staging server which houses the version currently in production with mock
data, intended for rapid testing and iteration or playing through failure
scenarios. Let's see if we can put feature X into it. Let's see what happens
when Y fails catastrophically. Let's do a practice deployment with one of the
devs. Let's see how quick can we get it back up if the cleaning lady pulls the
plug by accident. That kind of stuff.

------
fma
It's not about confidence, it's about being careful. If you don't give a crap
about your software you test less, have less code reviews, don't ask for
second opinion.

If I'm writing a tool for the dev team, I'm not going to scrutinize the code
as much as something that will be deployed and will cost $$ if there's
downtime. Also withing the software itself, some components will be
scrutinized more than other, because their failure have larger impact.

Throughout the whole process I'm the same confident developer, I'm just more
careful and place more scrutiny where appropriate.

~~~
pcurve
I agree. It's about being careful, methodical, and anal. But I also think that
if you are nailing it on the head all the time and confidence is riding high,
you may slip.

~~~
dasboth
I prefer to think of it as "defensive coding" rather than something related
directly to self-confidence. Same with driving - I'm confident in my abilities
but drive under the assumption that everyone else on the road is
unpredictable.

~~~
busterarm
I'm with all of you on this, but unfortunately I've worked for way too many
bosses on tiny teams who don't want subordinates asking a second
opinion...they just want everyone to work headphones on, ship quickly and then
go home.

Being careful and trying to rubber duck first and code second has gotten me
into some hot water with a couple of them. It's frustrating.

------
Unklejoe
You can also think of it like this (which is kind of the opposite):

I am so confident in my abilities (or lack thereof) that I know when something
is simply out of my realm and I should seek the advice of someone more
knowledgeable than me.

Being confident isn't the same as being arrogant.

~~~
arethuza
I learned that lesson early as a graduate student - the Prof (UK sense) I
worked for was one of the brightest people I've ever met and he was also one
of the first people to say when he didn't understand something.

Of course, there is the "play the daft laddie" tactic that I do all too well!
:-)

------
zamalek
"I don't know," one of the hardest three letter sentences to say in
English[1], one of the most important to say, as well as one of the most
rewarding (time to learn).

I don't think it's about a lack of confidence, it's just awareness about how
far your knowledge extends and honesty surrounding that.

[1]:
[http://www.amazon.com/dp/0062218336](http://www.amazon.com/dp/0062218336)

~~~
charlesism
So true. If I need advice from someone (for instance, a doctor or mechanic) I
never really trust them until I've heard them use the magic sentence a few
times.

------
amelius
This reminds me of this quote:

> The competent programmer is fully aware of the strictly limited size of his
> own skull; therefore he approaches the programming task in full humility,
> and among other things he avoids clever tricks like the plague.

(E.W. Dijkstra, in 1972)

~~~
svckr
This is from "The Humble Programmer" of which I was reminded too. I think the
term humility captures the essence of what the author is saying better than
"lack of confidence".

You can be confident in what you know, all while humbly accepting that there's
a lot you don't know (and even more you don't know you don't know).

------
proteinbased
I like the writing style and assume this piece is well-intentioned. However,
speaking as someone who had confidence problems all his life I think what he
describes as (over-)confidence was actually confidence mixed with arrogance. I
think confident people can not really be generalized, as confidence can be
based upon many things. They might even be perfectionists. (no mutual
exclusion here) But when arrogance and superiority feelings, and "I have done
this for so long, I can do it in my sleep"-feelings kick in, it's where it
gets dangerous.

------
kstenerud
There's a HUGE difference between confidence in yourself, and confidence in
your process. Every process needs a healthy dose of skepticism, because it's
simply not possible to handle all angles. That's why in construction there are
inspectors. You WILL miss things; that's a given. That has NO bearing on your
self-worth, and has nothing to do with self-confidence unless you let it.

Confidence in yourself, that you'll reach your goals and succeed despite any
fuck ups, well that's a good thing.

------
alimg
OP is pointing towards being self-critical of your own work makes you a better
programmer in general. Well, lack of confidence makes you more likely to be
self-critical but in my opinion, self-criticism is a step for being confident
of your work.

------
qwertyuiop924
I suffer from confidence problems. But there is one thing I am confident
about: Sooner or later, the application, whether it's one I wrote or not, WILL
break. So I have an almost compulsive need to understand how EVERYTHING works
before I do ANYTHING. This is both a blessing and a curse...

~~~
cubano
> Sooner or later, the application, whether it's one I wrote or not, WILL
> break.

And of course there is the corollary...that it almost surely will be rewritten
if its something that is truly useful to the business and its bottom line.

~~~
qwertyuiop924
No, somebody fixes it.

------
avindroth
There is a subset of confidence that will make you a better programmer: self-
reliance (i.e. Confidence in your being).

Self-reliance sticks around even when you lose everything. You lose your
house, money, job, partner, career, etc. and if you can still build yourself
back up, you are self-reliant.

Most confident people are confident in something they have. Money, fame,
house, looks, diploma, knowledge, etc.

The self-reliant, however, lives from the first car of his very own train of
life — money, fame, or anything else do not precede him. Even when he loses
everything, he is still in the front, navigating.

Those confident in external things will falter when they lose those very
things that are leading them.

Perhaps lack of confidence can make you a better programmer. But lack of self-
reliance bodes fear of the unknown.

~~~
pop8row9
I like this very much; it reminds me of Dr. Manhattan.

------
atemerev
I am confident that my code will fail spectacularly someday. This is why I
think a lot about possible failure modes, but I am also quite confident there
will be some I didn't think about, and they lurk somewhere awaiting the
opportunity to manifest themselves.

Which is why I invest heavily in alerting and monitoring services, but I am
confident that someday, they will fail me too, or two bugs simultaneously
somehow will create an illusion that everything is fine (and report it to
monitoring), but it won't be fine.

I accept the inevitable. Compared to the fact that someday I (and everyone
else I know — I don't believe in mind transfer and biological immortality)
will inevitably die, this is a small thing to accept.

I work in high frequency trading.

------
Kinnard
The phrasing here is interesting, I think you need confidence to expose your
mistakes and weaknesses in order to learn and grow.

People who lack confidence are more likely to cover up their weaknesses and
ignore their mistakes.

This is the thinking behind the growth-mindeset/fixed-mindset paradigm:

[https://chrishildrew.files.wordpress.com/2014/03/fixedgrowth...](https://chrishildrew.files.wordpress.com/2014/03/fixedgrowth-
copy.jpg) [https://www.farnamstreetblog.com/2015/03/carol-dweck-
mindset...](https://www.farnamstreetblog.com/2015/03/carol-dweck-mindset/)

------
Practicality
I think most of the criticism here is simply based on the overly broad use of
the word "confidence."

There is an interpersonal "professional" confidence, which is needed to
function in the business world (although as many mention, you need to avoid
arrogance so balance is needed).

But the article is referring to a different kind of confidence: The belief
that your work is automatically good. Nobody needs that kind of confidence,
because no one's work is always correct the first time.

Lacking the latter confidence can give you more of the former, as after you've
double/triple checked your work you can confidently assert the quality of your
work.

------
duaneb
I would be convinced, but the Op didn't sound confident in their argument.

You need confidence at the end of an iteration cycle. Continually vouching for
code on which you're not confident is stressful and would lead to burnout.

------
mathattack
Finding the right balance is very important. Projecting confidence is
important for leadership, and winning arguments. Overconfidence is a fatal
bias. [0]

In some fields (Sales?) overconfidence can spur achievement. In many others
it's dangerous. ("The US housing market will never drop", "We can make up the
time by efficient testing", "Their party will never nominate that clown.")

[0]
[https://en.wikipedia.org/wiki/Overconfidence_effect](https://en.wikipedia.org/wiki/Overconfidence_effect)

------
meira
Double check isn't lack of confidence, but experience of knowing what can go
wrong. Actually, this is confidence.

~~~
shriek
Also, getting up at 2am in the morning gets tiring after a while.

------
rezashirazian
For me, anecdotally confidence is not a constant value. Regarding most things,
specially when it comes to programming, it starts out with a somewhat high and
overinflated value. I jump in with all kinds of wild and crazy ideas. Then
when I start working/learning it starts to sink fairly quickly. As I learn how
little I know, it sinks lowers and lower. Then it stays down for sometime as I
work get through an initial learning curve.

After some time, when I see things lining up and working as expected, it
starts to come back up but it never reaches the heights I had initially. I
lose the enthusiasm and courage for wild and crazy ideas. Which is a shame
because if I can teach myself to retain my enthusiasm as my confidence sinks,
when I'm actually capable I'd be more brave.

------
kazinator
The program code is not _yourself_. Self-confidence in the area of programming
doesn't mean that you believe your code, or your change to it, are correct;
it's the belief that you _can_ transform requirements into code, that you
_can_ debug it, that you _can_ understand some complicated thing and make a
meaningful change, and so on.

If you think that the code you wrote must be correct because you're a hotshot,
then you're taking self confidence beyond the "self", projecting it onto
external things connected to you. It's not that you have too much self-
confidence, but that it has the wrong scope.

------
klagermkii
I feel that the self-confidence that is important is not in regards to
specific coding skill or the quality of the code itself, but rather the
confidence that no matter how the project goes I will be able to find a way
through the problems. It may not involve the greatest method of solving it,
and I'll probably be able to look back with hindsight and learn a lot, but one
way or another I'll be able to see it through.

To me that mindset is very different from thinking that every piece of code I
write is particularly amazing, it just helps free me from some of the
paralysis of worrying about going down dead-ends.

------
dahart
This is an important point, but I say it slightly differently. This may be an
entirely irrelevant distinction on my part, but I'm very confident that I'm
producing bugs. If I'm writing code, bugs are happening.

The one reason, in my personal experience, that I've benefitted from calling
it confidence in bugs rather than a helpful humility and lack of confidence in
my ability to produce bug free code is that it's easier to sell testing and
code safety structures to managers, who never seem to enjoy budgeting for time
that doesn't produce new features.

------
segmondy
The title and subject is very poorly framed. I want programmers to have
confidence, however, what I also want them to have is humility. Lack of
humility can limit your programming ability. It's possible to be both humble
and confidence in your programming ability.

I've seen lack of confidence limit programmers in most cases than not. They
refuse to try new technology because of the unknown. They are afraid to learn
new things. They are afraid to fix things. They are afraid to speak up and let
other's do the speaking for them.

------
0xmohit
> Why does doubting yourself, lacking confidence in yourself, make you a
> better a programmer?

I prefer to say it in a slightly different manner.

Ask yourself: could I have implemented this better? Better can imply more
efficient, readable, in terms of design ...

Essentially realizing the fact that one might not have done a perfect (or even
a _reasonable_ ) implementation and that it might be possible to improvise
upon.

I've often found myself redoing pieces after thinking about the
maintainability, readability aside from worrying about functional aspects.

~~~
initram
It reminds me of my Freshman college English class where the teacher had to
teach the class not to turn in their first draft of papers. Reading each
others' papers, you could really see that just going over it once and
correcting things made a huge difference in quality and coherence.

------
nikdaheratik
Alot of the time, it isn't _myself_ I need confidence in, but rather the code
and the system it runs on. Sometimes this can be fixed by working with it
until I understand it better. Other times, not so much.

The end result is you either get comfortable enough with what you're working
on that you can figure out where it will likely break, or you move on to
another project (maybe more quickly than you normally would).

------
jroseattle
I get it -- lack of confidence yields doubt yields double-checking, verifying,
testing, not taking things for granted, etc. It's a means to an end. It boils
down to effort and thoroughness. As a programmer, that's always been true over
the course of time.

In the end, confidence (to me) is about how one personally feels. IMHO, the
great thing about programming is that it removes personal feelings from the
equation.

------
Cozumel
'I finally became a better programmer when I learned to doubt myself, to doubt
the software that I wrote.'

How about just actually, I dunno, LEARN TO CODE! I see too many of these
articles and they all come down to the same thing, people not taking the time
to actually learn the fundamentals, how to program, concisely, systematically,
methodically etc, to learn the language and tools they're using.

------
ageek123
I think this article confuses self-confidence with humility. They seem to be
arguing against arrogance, rather than against self-confidence. You need both
self-confidence and humility to be a good programmer.

------
rajadigopula
I strongly disagree. Every programmer must be confident about their code. I
code and I can explain how each and every line work, and I organise it to be
simple and side effect free. This helped me produce literally maintenance free
software for so long. This only comes from the confidence of saying "I know
exactly what my code does!".

People who doubt their code or design usually end up bad programmers as they
are not sure what their code does and it's side effects and they constantly
seek other's opinion in the name of 'better implementations' \- but there is
no right design in reality, all one can do is produce small, concise, to-the-
point side effect free functions that does solve one and only one problem at a
time.

------
factorialboy
The world is full of confidence but lacking clarity. I am indeed also one of
them. Confidence without clarity is a curse.

------
known
You mean cynical?

