I don't think it's something you have to build. It's either there because of years of experience fixing problems or it's rightfully not there.
I'm going to guess you've never dealt with imposter syndrome like most developers have then. If so, then count yourself blessed. Even the extraordinarily skilled and experienced developers I've been privileged to know have to wrestle with imposter syndrome and a lack of confidence.
No one likes a developer who say can do it and then screw it up.
Everyone makes mistakes, but in my years as a team lead and internship supervisor, I've found that the person who can make mistakes, break the build, and learn from it, consistently produces better work than the "never makes a mistake" developer; the latter is usually (in my experience, always) immune to experimenting, growing, and learning.
I lend confidence to people by being honest about their weaknesses, so when I say something good about them they believe it.
There are already plenty of people who are happy to point out everything a young developer does wrong, and then some. The healthy approach is to give both positive feedback and constructive criticism. Just being "honest" about someone's weaknesses, without caring about how phrasing impacts someone's self-esteem, does more harm than good.
And no, this isn't some flimsy "feel good" entitlement philosophy. I expect my interns to do their absolute best, and I can be quite tough on them when they don't! However, there is a significant difference between tearing someone down and building someone up. The people I've trained over the years do know what they're doing now, but more importantly, they have enough confidence to not lie about their skills or tear others down.
And by the way, usually it's the people who are regularly torn down by people happy to denote all their weaknesses to them who wind up overstating their skills and grooming their ego, just to compensate for the crushing weight of condemnation everyone happily piles on.
No never really dealt with imposter. I think it's just a real feeling experienced by over-compensated US developers. You get imposter because you definitely know you are not providing 120K value in a year being barely out of school. But I could be wrong!
Yes I agree developers who break the build end up becoming a better developer in the end. But I hope they don't start their career doing contract work.
I think I meant the same thing as you said. Didn't really mean that I point out someone's mistake to hurt their feelings. I meant it in a context of code review rather than unsolicited advice.
I think it's just a real feeling experienced by over-compensated US developers.
Nope. People all over the world experience it the same, including hobbyist open source developers who don't get paid at all, students who actually are paying for school or the bootcamp, and even extraordinarily talented and skilled developers with decades of experience.
You get imposter because you definitely know you are not providing 120K value in a year being barely out of school. But I could be wrong!
That is absolutely not the cause. Imposter Syndrome is seldom based in reality; it's an overactive critical self voice. You need to read (not comment on...read to learn instead) the articles on this site about it. There are a lot of them from people of all backgrounds.
Didn't really mean that I point out someone's mistake to hurt their feelings.
Seldom is the intention to hurt someone's feelings; almost always, the person doing the damage thinks they're being "constructive". It flows out of a lack of awareness of how one's words affect another.
Usually no one is more aware of your weaknesses than yourself, but we're usually the last person to tell ourselves positive things. (If one is seldom aware of one's own weaknesses, that should be an internal warning of an oversized ego.)
I meant it in a context of code review rather than unsolicited advice.
Yep, and code reviews are where some of the worst damage occurs. This is true of both formal reviews through pull requests or what have you, or informally in the context of asking for help. Code reviews too quickly turn into a reenactment of middle school dodgeball, where the reviewer(s) try to feel better about their own coding skills by ripping into someone else. "I'm just providing honest feedback" is the favorite self-justification for this.
When I code review, while I'm honest about what needs to improve, I keep two things in mind:
(1) Phrasing matters! I am to teach, rather than criticize. Be patient. Choose words that make the code the problem and target, rather than the coder.
(2) I look for at least one positive thing to point out in every review. Code is seldom devoid of anything good. I'll usually highlight a technique I learned from the code, a superb comment, or a clever (in a good way) implementation decision.
By the way, this is exactly why interpersonal skills are so important in programming. The most technically proficient developer becomes nothing more than an obstacle to their team when they lack the interpersonal skills necessary to communicate clearly and constructively with their peers (of all levels), clients, and users. Words matter.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm going to guess you've never dealt with imposter syndrome like most developers have then. If so, then count yourself blessed. Even the extraordinarily skilled and experienced developers I've been privileged to know have to wrestle with imposter syndrome and a lack of confidence.
Everyone makes mistakes, but in my years as a team lead and internship supervisor, I've found that the person who can make mistakes, break the build, and learn from it, consistently produces better work than the "never makes a mistake" developer; the latter is usually (in my experience, always) immune to experimenting, growing, and learning.
There are already plenty of people who are happy to point out everything a young developer does wrong, and then some. The healthy approach is to give both positive feedback and constructive criticism. Just being "honest" about someone's weaknesses, without caring about how phrasing impacts someone's self-esteem, does more harm than good.
And no, this isn't some flimsy "feel good" entitlement philosophy. I expect my interns to do their absolute best, and I can be quite tough on them when they don't! However, there is a significant difference between tearing someone down and building someone up. The people I've trained over the years do know what they're doing now, but more importantly, they have enough confidence to not lie about their skills or tear others down.
And by the way, usually it's the people who are regularly torn down by people happy to denote all their weaknesses to them who wind up overstating their skills and grooming their ego, just to compensate for the crushing weight of condemnation everyone happily piles on.
No never really dealt with imposter. I think it's just a real feeling experienced by over-compensated US developers. You get imposter because you definitely know you are not providing 120K value in a year being barely out of school. But I could be wrong!
Yes I agree developers who break the build end up becoming a better developer in the end. But I hope they don't start their career doing contract work.
I think I meant the same thing as you said. Didn't really mean that I point out someone's mistake to hurt their feelings. I meant it in a context of code review rather than unsolicited advice.
Nope. People all over the world experience it the same, including hobbyist open source developers who don't get paid at all, students who actually are paying for school or the bootcamp, and even extraordinarily talented and skilled developers with decades of experience.
That is absolutely not the cause. Imposter Syndrome is seldom based in reality; it's an overactive critical self voice. You need to read (not comment on...read to learn instead) the articles on this site about it. There are a lot of them from people of all backgrounds.
Seldom is the intention to hurt someone's feelings; almost always, the person doing the damage thinks they're being "constructive". It flows out of a lack of awareness of how one's words affect another.
Usually no one is more aware of your weaknesses than yourself, but we're usually the last person to tell ourselves positive things. (If one is seldom aware of one's own weaknesses, that should be an internal warning of an oversized ego.)
Yep, and code reviews are where some of the worst damage occurs. This is true of both formal reviews through pull requests or what have you, or informally in the context of asking for help. Code reviews too quickly turn into a reenactment of middle school dodgeball, where the reviewer(s) try to feel better about their own coding skills by ripping into someone else. "I'm just providing honest feedback" is the favorite self-justification for this.
When I code review, while I'm honest about what needs to improve, I keep two things in mind:
(1) Phrasing matters! I am to teach, rather than criticize. Be patient. Choose words that make the code the problem and target, rather than the coder.
(2) I look for at least one positive thing to point out in every review. Code is seldom devoid of anything good. I'll usually highlight a technique I learned from the code, a superb comment, or a clever (in a good way) implementation decision.
By the way, this is exactly why interpersonal skills are so important in programming. The most technically proficient developer becomes nothing more than an obstacle to their team when they lack the interpersonal skills necessary to communicate clearly and constructively with their peers (of all levels), clients, and users. Words matter.