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.
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.
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.
"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.
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.
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.
I heard impostor syndrome was en vogue at Google. That strikes me as the other extreme, unrealistic (low) confidence. Which is still damaging. Haven't worked at big G though, so I can't tell.
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.
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.
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.
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.
Parallel to what I mentioned, if you are driving in an open country road with nothing around you, you don't have to be as careful as if you're driving in rush hour traffic on the highway where everyone is trying to get home. You can be less cautious on the open country road and still be confident you won't get hit by something.
As humans we have a finite amount of resources, whether it's time, concentration...the key is to pick wisely and balance.
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.
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! :-)
"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.
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.
> 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.
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).
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.
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.
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.
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...
> 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.
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.
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 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.
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.
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.")
That's what I thought, you could be confident in the limits of your own ability, as opposed to being delusional that everything will always work perfectly!
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.
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.
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.
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.
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.
> 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.
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.
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).
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.
'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.
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.
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.
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.