There are certainly a lot of ways developers can be "underconfident" in the form of impostor syndrome, etc.
But overconfidence is also an issue. Care to share some observations of this?
For further actions, you may consider blocking this person and/or reporting abuse
vent incoming
I think one big thing I've noticed is people offering unsolicited advice that tends to be there to make the advice giver feel good instead of the recipient, and that's usually inappropriate for the level of the recipient.
I get a lot of "explanations" of things in response to posts I put online that are kind of insulting. For example, I've had both the concept of Git and an explanation of what a pull request is recently, which while helpful for someone starting out, isn't relevant at all for somebody who makes a ton of pull requests and has for years. Lots of unsolicited code reviews of stuff too, I've even had my own code explained back to me! I know what my code does and why, that's why I wrote it!
Couldn't agree with this more. It's so insulting, but you can't respond in kind for fear of being labeled "emotional" or "hysterical."
sub-vent because I think we've probably had similar experiences.
Something I find myself doing when I write tutorials is adopting a voice of someone who's a little more confused and a little less experienced than I actually am because it gives me an in to write explanations of important concepts.
Writing informative content online is REALLY HARD because you're trying to explain something to a broad-leveled audience. So I often cope with this by creating a stand in persona of Past Me (who is ignorant and made some mistakes), and Current Me (who knows better). But people who don't understand that this is a bit of rhetorical artifice aimed at increasing readability take this as an invitation to talk down to me. Which is baffling, since I had enough domain knowledge to write the tutorial! Why do people feel the need to approach me online to helpfully explain elements of the tutorial that I wrote? 😡
Sorry for the vent. This topic just makes me so mad.
Totally agree -- it's so hard to deal with. It is super hard to deal with, people always say to ignore those people, but it's so hard to accept that someone thinks you are less talented/experienced than you are. So tricky to navigate.
Giving feedback in a way that is actually helpful is a really hard human communication problem, I think. I think if advice can be framed in a way like, "Oh, we had that same problem and here is how we solved it..." It can be helpful. But yeah, I totally feel you. I catch myself about to give advice and If I ask, is this helpful? The answer could easily be no. That's hard to wrap your head around.
Any tips for improving feedback, advice from your perspective?
Thanks for venting.
I think a lot of times you have to ask yourself: Am I giving this advice to help others or for my ego? Then SIT on that for 30 minutes. You probably think you're helping others when really you're just trying to boost your own confidence and ego.
BTW when I say you, I don't mean you directly. Just you in the general sense.
A lot of unsolicited advice comes from the assumption that someone hasn't thought through their code or decisions. Asking someone first what their thoughts are on "X" or what their motivation was for doing "Y" is usually a better way to go about it because then you're not making assumptions and it may lead to learning lessons for the target and/or yourself.
You also have to think about the culture. For example, PRs have are asking for advice by nature.
In 30 minutes you'll able to give a ton of useful advice. Nice that you have 30 minutes spare while coding, but some of us definitely not.
At the same time I see your point, and absolutely agree, but this is only question of professionalism/egoism. Professionalism should be automatic.
One of the biggest things I see folks get overconfident about is assuming that they know enough that they can stop listening. I've had so many instances where I've talked in a meeting and gotten cut off before I could finish my sentence, only to have the speaker address something completely different than the point I was about to make because they just assumed they knew what was about to come out of my mouth. Or engineers and designers starting to break down tasks and start work before they even completely understand the feature they're supposed to be building and just run away with their assumptions.
We collectively could save so much time if we just shut up and listened just a little bit longer when our colleagues speak!
(to be clear, nearly everyone I know - including me - is guilty of this at some point. this is not a subtweet of a specific person)
hehe.. probably ticket estimations, whether that's time or effort. Usually the estimate is too short or small respectively. I think devs can gauge how difficult a task is in isolation but sometimes there is some oversight or extra implementation required elsewhere.
Most of the overconfidence I've seen is related to security and encryption and usually due to ignorance. Devs tend to think their site is unhackable until it's hacked.
Golly I can't imagine thinking my site was unhackable. Making dev.to open source was definitely in part out of paranoia that the longer we remained closed-source, the more hackable we became. 😳
To be fair, making a site open source would and could shed light on more ways to hack it but at the same time, it allows more people to spot vulnerabilities and contribute to making it more secure.
Like someone once said, if you don't follow Kerchoff's principle you may delude yourself in having something secure when in fact it's not.
Closed source is just security through obscurity
lol
I didn't learn much about security and distributed systems at university, but the one thing I learned was "it's harder than you think, so consult a professional!" xD
I see this in the form of the expert beginner. When you stop learning or think you know it all, you fall into the expert beginner phase. Until one realizes there's so much they don't know, they'll be stuck there.
Another way to phrase this is when people think they can no longer learn from others. They tend to think they're the expert and should be the one teaching all the time. A good example is people giving unsolicited advice (see the great discussion in this post).
Our industry can be tough. We're expected to know so much. In a way, we might even be trained to act like an expert even when we're not. However, admitting you don't know something is a huge step toward growth. Change is hard. If you're not accustomed to saying, "I don't know," it can be tough to change that.
The best medicine I've found for this is to keep an open mind and always look for ways to improve. Be confident in your abilities but know when to pull back and admit your shortcomings. A good team won't fault you for that.
Great to see someone post some Erik Dietrich/Daedtech links in here, he's an excellent writer
This goes hand in hand with the Dunning-Kruger effect which was brilliantly put by Socrate where he basically said: "You're more knowledgeable when you know what you don't know".
Additionally to that, in those days, the notion/concept of admitting one's ignorance (ie. saying "I don't know") is more often than not a source negative criticism and what not.
I worked with a few devs who were at a very beginner level, but they worked with non-technical people for many years often over 10.
Somehow these people managed to never interact with better devs than themselves and have the feeling they know everything because they know more about tech than their non-tech co-workers.
It's tough to work with these people when they're much older than you because they think they are "wise" and you are just some young hipster.
You want a rant, cause this is how you start a rant
Nah I'm kidding, but what I've observed and experienced first hand, my rant would boil down to the following:
They don't listen! Like nothing, nada. Like why even bother hiring employees or being part of a team if you're going to dismiss everything they say or recommend because you know better? And they're not dismissing juniors. They're dismissing anybody who they don't admire or consider equal.
This is a huge issue, especially if/when they reach leadership positions.
rawrawrawrawr
As all bad things, it comes in 3:
1.The "Too Senior To Learn" Syndrome, there are a lot of senior developers in my team (myself included) and some of them just discard everything junior devs says, they don't even bother to double check.
A lot of overconfidence in their skills. And sometimes this leads to stop learning something new or updating their knowledge and probably will not accept new ideas.
It's like having a very very very skilled Java 6 developer and you come with your brand new streams and multicatch sentences and he will say "Hey, that's for losers! do your 20 lines for implementation instead!" .
I have seen developers assume the way they solved a particular problem is unconditionally the best way. (And I have been this dev at times.) I think that usually these devs are well-meaning. But they are discounting the possibility that the other team's constraints might be radically different. Which can make their solution impractical for another team. For example, suggesting that another person should solve their problem with microservices because that worked really well for you. But the other person is at a small company whereas you are in a large organization with multiple teams.
The particular variation of this problem that I dislike the most is in people who write articles and present at conferences for a living. I have observed sometimes the code they write doesn't have a life outside of the demo. It doesn't face the ongoing challenges that come with external users requesting unforeseen things. But for the sheer fact that it demos well, a conference attendee or internet reader will put some of these strategies in their code bases. And they have to learn the hard lessons of why it doesn't work under real-life usage. You can pretty much assume that vendors demoing their products are doing this on purpose. But I've seen it a bit in trade publications and tech blogs too.
Something I see a lot and I was guilty of as well, was how certain they are they can solve a problem.
Dev is sure they can solve it, then struggle for days.
I'm sure that given enough time they'll get it solved, but their struggle begins to make the team nervous and invites poor management to step in.
So, I give a TTH (Time-To-Help). Set a line, in minutes, where you work on a problem without making progress before you go ask someone for help.
Another one I see, similarly, is a confusion around information, knowledge, and experience. I meet lots of developers who read a blog post and claim they, "Know," some given topic. This is before they've applied it, tried it, worked with someone that has gone through it before. They'll develop a belief that they have the knowledge and experience behind it.
Getting a drivers license doesn't make you a good driver.
Ah, pretty much anytime I write any code I think it's gonna' work correctly the first time. It never does.
I don't know if this counts, but when I was a student, I know two groups of people who either have internships or not. Those that have internships usually give "advice" to those that don't in a condescending tone and would end the "advice" with this kind of phrase: "You'll just have to wait until you work to understand what I mean."
The over confidence I've observed in myself is the standard dev "of course my code works right" stuff, especially as I've gotten more senior. The way I protect myself against it is on every PR I have a standard template I make myself write out : not just what am I changing and why, but how did I test it and what docs needed updates. The act of writing out the testing has made me realize stuff I missed, and more than once I found a bug when I went back to do the testing.
Generally speaking when someone says they never make type errors I can't help but think it requires a massive amount of overconfidence/arrogance to think that's actually true.
In approximately 17 years of programming I've never met or seen anyone 'smart enough' to not make these kinds of errors and somehow I've now stumbled upon the first?
Hmm...that's a hard one cause I hardly meet one who has overconfidence. If i were to point out of a developer who is really overconfidence that I had encountered.
I think the type of confidence might be the snobbish type. Which sticks to their dogma or mindset.
Questioning and refusing to take in new knowledge or information.
Which only gives you a single answer or solution to problems which is in the form to be my way or the highway type of solution?
Rose colored glasses - "that system I designed a decade ago is great, it should be really easy to code against." *Narrator voice: "it really wasn't"
This is a bit of a meta-answer.
I sometimes see developers gain confidence because of their peer group cheering them on, and it's not necessarily a good thing. I mean, of course being positive is a good thing, but there's so much these days that gets blamed on impostor syndrome, and I've seen people I know tweet about how they're overcoming their impostor syndrome and they're actually good at their job, when I've met them, read their code and wouldn't accept it in a pull request.
It's not common, and it's outweighed by the positive side of things, but it's something I've noticed.
The most sure sign of overconfidence I often come across is oversimplification. In other words; stating that complicated things are, in fact, very simple and will only take a couples of minutes to fix/get done.
Statements like: "It's only data, put it in a table." or "How hard can it be?" raises a flag that a person might not fully appreciate the full scope of the problem or underestimate the development process.
Too many people have overconfidence over their vision of clean code and how their version is the best. While it's great to have people caring about such an undervalued feature of the code it is still very subjective what clean code actually is.
I hear a lot of "comment every 3-4 lines of your code" and "if your function has more than 50 lines of code it has to be broken down into more functions". While that has its advantage, people often (not just forget, but) completely ignore the drawbacks in light of their "great advice".
The worst example of this was an applicant for a senior developer position that I had to interview. His overconfidence in his ideas, opinions and methods being the sole correct ones was really toxic. While he wasn't really bad at coding, his arrogance was so annoying that we unanimously dismissed his application.
Developers who constantly brag about hacking into one system or another if they can't remember (or don't have) a password. Pretty sure my eyes rolled so far back in my head that I saw my brain when the web developer on my team said that to me when he couldn't remember his Salesforce password.
Sure, go ahead and hack Salesforce....
One of our .Net Architects has been in the field for a very long time, and such feels he is very much above my team who a form of "Shadow IT" using a low-code environment. It wasn't until when I was looking at his screen as he was looking for an issue that I asked a question, about a language I don't know, because I saw some similarities and asked for some clarification that he realised that whilst I may not be able to code like him, I certainly think like one.
Anyone who writes a comment that starts with "Actually..."
Actually... that's a pretty good example! :-D
The over-confidence is always subtle. Instead of indulging in explicit arrogant behavior and name calling, they use subtle passive aggressiveness to express their feelings!
On the other end of the spectrum, we have those suffering from perpetual imposter syndrome! They think that they are a nobody and good for nothing while hiding and suppressing all the creativity and knowledge within their subconscious. The imposter syndrome won't let them have even the slightest of confidence, and that leads to inaction. This loss is both theirs and humanity's.
I work with a lot of people (all different kinds of egos). I have to admit I'm an unsure developer, the one who will never be 100% sure she can do it. But that being said, I believe it's better not to assume you will make it (to the finish line), instead of the opposite.
Good balance is
Always stay humble. Be gratefull. Be kind.
The one that irks me the most is the belief that the value of coding trumps everything else at the company.
Designer bringing us a Sketch file that will require a few more hours or some wonky CSS workarounds to implement? Better compromise the design. Have to maintain the quality of the code base!
Client emails requirements that outside of what we predicted? Well, they'll have to make changes and concessions in their process then. Have to maintain the quality of the code base!
Boss wants us to make changes similar to what the client wanted. Business goals be damned! Have to maintain the quality of the code base!
The company is out of business because of low product quality and an inelastic response to changes in the market?
Oh well, the codebase was probably low-quality and legacy at this point. Best to rebuild from scratch anyways.
Conflating "ten years of experience" with their own "one year of experience, ten times"?
When devs read an opinion piece on how to do something and mistake it for gospel never to be questioned.
This component doesn't need tests. Let's disable them. (Next day: fallback...)
Overconfidence - nobody can beat medics. Software developers are way behind them.
Front end dev here. I had an interview with Microsoft. I didn't prepare one bit since I am good at my regular day job. Couldn't answer simplest of questions like, "What is DOCTYPE".
Pushing a minor bugfix without testing. :D
I'm overconfident in my time estimates for tickets.
The belief that my code > all other code
Dilbert was exactly this five years ago:
When a dev fully commits to the first solution that pops into mind and is 100% certain that's the best solution.