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
Top comments (69)
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.
As evident by all the CoC drama, I think tech is also plagued by people who have no concept of how to communicate civilly or that people's feelings can get caught in the crossfire so to speak.
"Interesting that you chose solution X. We tried that initially but found out that it caused problem Y when we set up our CI system, so we had to resort to solution Z"
Versus:
"Why are you doing X? It's going to cause problem Y in CI. You need to do Z instead"
I know all of you have seen plenty of the latter, and not enough of the former. They both say the same thing in wildly different ways.
It doesn't have to be 30 minutes. My point in saying that is because people always give unsolicited advice without thinking about it. If you are forced to give yourself some time to respond, it's less impulsive and can be better phrased or helpful.
This can go for a lot of things too, not just giving others unsolicited advice lol.
As I said, I have understood your point. But I can also understand the human factor (ie when you, as a teamleader, are under pressure and constant stress, and you have to do XXX merges per day, you have 20 incompetent juniors in your team etc. - in situations like these, some people can easily lose nerves, and i totally understand it, although I do not think that this is professional behavior).
In a professional setting, it's a bit more understandable. But I have both gotten it outside of work. It's infuriating :(
Yes in this case it is totally understandable as it is nothing more than bitching. I'm sorry, that it's happening to you, but as Bryan Lunduke said, sometimes programmers_are_evil(). Big egos and so on. In my community (information security people) it is not much better, believe me.
Thank you Lindsey, I'm definitely guilty of both commenting to feed my ego (here on dev.to) and not spending enough time to think about how I want to respond or if I should respond at all
There is also human factor. If you keep repeating version 1. 50x per day, you might just lose nerves and choose version 2. instead. I have understanding for it, especially in cases when person who does the merges has huge incompetent team (which, sadly, often happens).
I think that online I would only give feedback if it is requested or very obviously needed (like an error or incorrect information in a blog post). In addition, just check out the person's profile real quick to see if the person is brand new or somebody who has done this for years, and don't just judge on their picture! Just cuz I'm a blonde chick who has been told that I look like a teenager, I've still been writing professionally for 5 years (not saying you would of course, but I have had that happen).
Please read again the answers from the perspective of someone who is trying to understand the causes why someone would reject unsolicited feedback.
I will make a non-requested feedback here. I hope it surpass the barrier of previous emotional experiences and reach the practical side:
It might be not nice but, in practical terms, you'll get more knowledge from those that criticize your work that from those that are always agree with you.
The people that break paradigms use to question every info that you give. That's their natural behaviour. Even when they are not humble sometimes, you can benefit from them.
Many of the most important stuff that I have learn in my life came from my students. The masters use to be old people with a lot of knowledge, but the new people carry the objections that generate paradigm-breaking ideas.
No matter the level you reach, no matter how good is the result of your work... you come back some years later and think "I could made that better".
So everybody could try to correct anybody. That seems not polite, but think that many people who think the same way could be corrected, once the discussion come to an end.
The commitment should be with the other readers and how they can profit from the discussion.
The others might not be aware of this topic, or they do and they don't matter. At the end, they need to make a tremendous effort trying to decorate the message for the social conventions. And programmers trend to be more nerd than social, because they invest most of the time behind a PC.
In practical terms, there is also a lot of redundancy. Some comments complain about the "Actually", but what about the "I think"? It is not redundant ?
Why should someone say "I think" just to be polite ? All that you say is because you think that. If we would be so strict to differentiate the personal opinions, then other assertions should have a bibliographic reference (like in articles).
Here you can see an example: You both answered with I think, to correspond the super cautious answer from John Bull that uses two consecutive I thinks tanking extra care of not make any insult. Think about making this effort in every POST for 10 years...
At the end that is a matter of education, many people have invested a lot of time on this topic and they have already recorded that in hardware. For them is not an effort, and they would be rewarded for sure with better positions, opportunities, etc. But you should not let that the other comments affect yourself emotionally.
I think that the technical communication works better if everybody strips the social conventions and it is assumed by default that everybody comes with the same intention of learning from the discussion.
Sometimes even happen, than the message is very polite but the idea is not clearly stated. The key is trying to say it in the simplest form, don't put you barriers to ask and do not offend anybody.
There are a few posts here which are actively soliciting critiques (most recently
Resume Review
Kim Arnett
I feel you.
This is why I do not post my articles on reddit. The dev community on reddit is toxic.
The criticism isn't a reflection on you or your code but the community itself. I read a lot of Eric Elliot's article comments because they remind me that everyone is criticized and harshly.
Here's an example: medium.com/javascript-scene/famili....
^ The top comment even begins with "Actually". 🙄
People seem to be very quick to blast out a comment proving how absolutely wrong the author is and demonstrating their superiority. Commenters love to flex and show off, not realizing they aren't contributing to a discussion.
But authors not always 100% right. So corrections should be expected. Even Eric Elliott's articles are heavily corrected: medium.com/javascript-scene/functo...
But a lot of corrections seldom contain empathy. The corrections seldom contain the intent to contribute, help, and improve.
That being said, I believe the community on dev.to is an improvement over others I have seen. But we still have a long way to go.
Yeah, I actually have a thread about me on Reddit and how I'm not experienced enough to give advice. Lots of incorrect personal information about me in there too. It was a terrifying experience and something that really hurt me.
It's one thing to call out incorrect technical information so that readers know something is incorrect, but different opinions or incorrect critiques is BS. If you're going to critique someone you have to be 110% knowledgeable on that topic.
Also, they didn't have critiques of my writing (which I would be fine with) but just critiques about me as a person.
Wow, that's messed up. I'm sorry to hear :-(
I never used reddit. I always try to stay 100% clear of toxic Internet communities. Dev.to is luckily different (for now).
Do you think what happened to you was actually mansplaining and misogyny?
I think our male-dominated tech industry is especially harsh, presumptuous and judgmental towards women. They may feel threatened in their "I was first here" alpha status.
Thanks! To be honest, yeah. I think the way I look, my age, and my gender all play into that. As well as the fact that I talk a lot about beginner topics since I teach programming for my job. But I also see it happening to men in the industry sometimes, so it extends past those factors!
I think mansplaining happens and it may more frequently to women. But I have seen the same things happen on Eric Elliott's articles. I would consider him one of the most knowledgeable people in the JavaScript community. But people are still eager to point fingers and say "YOU ARE WRONG".
I'm sure you are right. And that might be unavoidable.
It was getting me down for a bit also, but after reading the comments on Eric Eliott's articles, I realized that it also happens to the best.
So it's really less a reflection of the author and more of a problem with the community.
But I agree that there are definitely people that will get it more than others. And even if we don't like it, humans always judge someone on appearance.
Having this discussion is healthy and this may contribute to a tipping point that creates change in the community.
Keep blogging on.
Agreed. It's important to keep the discussions about it going. It seems we live in times where people tend to lose the ability to empathize with each other. I personally think the Internet is to blame for it to some degree. Antisocial and toxic behavior is quite normalized there, and it seems to be spilling over to meat space :-/
I guess I can relate to what Ali and you mention. A couple of years ago I wanted to participate in the C and C++ tagged areas of Stackoverflow, but the leading community figures there set the bar way too high. There is a lot of intellectual snobbery going on. Didn't want to be part of it, and also made me very hesitant to jump in and help out others there, in fear of being attacked by some of those community members.
It is largely for this reason that I've always been afraid of blogging, at least until Dev.to came along. The funniest thing to me is a lot of troll devs like to point out issues like: your article is hilariously inefficient or sooooo slow or suuuuch a memory hog (which is weird because I never remember sharing what the hardware requirements were). But my personal favorites are the times when dev snobbery sets in a bit and a comment launches into how people like me are destroying programming. They "prove" this, by rewritting my code snippet to use a feature or library of the language core that does the exact same thing. To which I always think: Well actually, according to your response, the Python Core team and I seem to agree on how to solve this problem and go about it the exact same way. Meaning that my code is on par with the code written by those who built the language itself. Therefore, my solution is not wrong, simply tardy. That doesn't make me a bad programmer, it makes me a questionable project manager and, seeing how I never claimed to be a project manager, I fail to see how your argument is relevant...
Yes, giving good advice is hard.
I stopped giving advice that people didn't ask for years ago.
If I work with people, I try if their stuff works with mine, tell them about bugs and keep my mouth shut.
I would probably think differently if I had any obligations to their code, but luckily I only have to look for myself right now, so it's not worth the trouble.
So now along with mansplaining, we have devsplaining. lol
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)
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
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.
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.
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.
Great to see someone post some Erik Dietrich/Daedtech links in here, he's an excellent writer
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.
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.
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 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.