loading...
markdown guide
 
  • Try something even if it's hard.
  • Celebrate that you did it! 🙌
  • Remember to celebrate your small wins.
  • Be kind to yourself and be your own personal cheerleader, especially through failures.
  • Remember to appreciate and thank others so they can appreciate themselves.
 

Celebrate that you did it! 🙌

@jess 's weekly wins threads are great for that 😄

 

I actually just looked at an old project I built last term at school, and while it isn't much to gauk at professionally, it reminds me that at one point, I never thought I could build it. Now I am writing code that connects to a SQL database, designing GUIs, and writing Java with the confidence that I can do this.
When I try to instill confidence in others, I like to learn what they know by getting them to explain to me what they're stuck on. My purpose is to show them that they likely understand more than they think they do but aren't progressing because they're stuck thinking they'll never progress. It usually gets the gears turning in their minds or at least gives them some pep talk.

 

Looking back on old things is a big big big one for me. Just thinking about where I used to be and how far I've come since then is always a big one.

 

One main thing I realized one day when I was struggling with learning c++ data structures is how long I went practicing c++ without even knowing what a pointer was (this was junior high and early high school). It's interesting to realize how easy the concept is and yet how hard I thought it was back then.

 
 

Accepting the fact that "Its ok to not know everything" and "I can learn it and do it" gives me confidence.
Pretty sure it does to others too

 

That first one is a big relief if you feel overwhelmed (especially since there are always new things coming out that suddenly get hyped up as "the future of X development"). It really is ok to not know everything. Heck, it's ok to use (and like using) a toolset that's a popular subject of ridicule.

 

For me is setting up personal small goals and small achievements daily, for example building some html/css stuff in codepen and so on. Let's just be serious, at work we can't have&work on projects that we like, and in time that is going to kill our creativity and personal confidence.

By doing small(and very small) projects i managed to increase my confidence, my skills and i increased the difficulty of my goals

E.G from this small card design codepen.io/FlorinCornea/pen/PgWEOo to a small app for gradients gradient.corneaflorin.ro/

And the good part is that you loose confidence again, you can start over with the small goals

Worked for me :D

 

I build my confidence by practicing writing code (especially something I'm new at). I also get a new perspective on things like 'imposter syndrome' from the awesome people I follow on twitter.

Mentoring helps build confidence in other programmers and in me, too. Communication, especially about how to ask the right questions, sharing tools, resources - that's what I try to do.

 

Don't over think. It makes you and your program ugly and sad. Also your team mates get mad if you think over something this much.

"Simple" is the key.
JDIS (Just Do It Stupid) principle bruh, we need to follow that.

 

Watching someone more senior than you make a simple mistake, surely helps the imposter syndrome... and is a good reminder that everyone makes mistakes.

Looking at old code, also, almost a breadcrumb learning path!

Low crash ratings 🥰

 

I really enjoy building the confidence of others. This is how I shape my developer relations program and advocacy work that I do. Talks, tutorials, blogs, etc. should distill complex information down to a digestible level without dumbing it down. I often introduce new language or jargon to folks first so that they can learn how to "speak the language" before trying to write code. From there I help them scope out small, manageable tasks. Confidence is easier to find with a sense of completion. Then you celebrate the completion and move to the next task.

 

Practice and doing things build your confidence. Even if you do small projects that boosts your confidence. I struggled a lot during school to write code and no one could clear my questions.Since, I started working I have been doing things I never expected.
I can make web apps now :)

 

I let my team work in a blameless environment.

I protect them from outside forces trying to circumvent this and point fingers. I'll take the blame personally if it makes the outside force feel better about their own bad habits, but then I'll quickly set them straight on it, regardless of their title or hierarchy.

I code review and encourage peer review. And I coach them on removing hubris and attachment to their creations, and taking feedback positively as just another challenge to smash.

So that gives them freedom to try things, fail, iterate, succeed, and celebrate. And if anyone tries to interfere with the environment I've set up, I get loud. :D

 

Ironically it was how I accepted that I'm terrible at developing which provided the turning point. Not fake modesty, a true acceptance that I suck. Sure most of my sentences start with 'I may be wrong' but it gave me the confidence to say... pretty much anything... because I may be wrong and I'm fine with it :)

 

Applauding the simple things, I think. Sometimes I gain a new perspective from someone else's code. When I see someone do something in an elegant way, even if it's only 1 line of code, I like to applaud the fact that it only took 1 line of code to do the job.

 

I try to lend confidence by giving kudos when a developer has helped me out in the past. It reminds them that they are a great part of the team and that they are valued.

I try to build personal confidence by trying new things. Helping others with their tech issues helps too.

 

Confidence, in a way, is self-esteem and self-trust.
It means you are aware of your knowledge, skills and surroundings: there will be people specialized in this sub-domain, others with a specific language, and others might prefer the human side of things, but everyone is an expert in its domain, if you know that you are the man of the situation for what you do then you are good, if it is not the case, find what makes you happy and what you enjoy to do around the Dev practice.

It also is about the reactions you have when an exterior event occurs, if somebody is judging you by what you do or what you are (of course it's about the person judging because it is rude), your confidence shows itself in the way you react to said judgement. The less you care about judgements, the more you gain in confidence.

Regarding confidence to others, I'm pretty simple: you already gained my trust and you are someone important and very interesting, from this point you can only lose it (but don't worry, it's hard to lose my trust). In lending confidence, I listen to the other, give credit where it is due and rightfully speak about various subjects besides developing and code, because I believe people get confident when they speak about themselves, not about what they do !

 

Firstly, developers always can do better than they are aware they can. I am one example of this.

I once took a project I didn't even understand properly. I only just told myself "I will sort it out". And I did just that. I delivered the project and got a five star rating.

Reminiscing now, I just see how much I underrated myself. And that gives me so much chill pills. I've been too harsh on myself. I was my own enemy.

 

Repetition and practice is how I build confidence. I heard once that you need to do something 10,000 times to master it. When you have solved a problem many times then solving it and similar problems will come naturally.

Helping others is harder but showing others ways to do things without belittling them could help. Confidence is an individual state and cannot be given, only nurtured in my opinion.

 

Let other developers write something first what he thinks is correct based on his knowledge. Then follow a 1-1 code review and suggest if there are any changes. If at very first we start commanding do this or that, otherwise a general human tendency would trigger and he might feel as if he knew nothing.

 

When it comes tackling things that I might not have immediate confidence in, I try to remind myself that often trying something, even if it is wrong, is the best way to learn whether I need to try something else. The sooner that course correction can be made, the easier it is to build confidence.

When it comes to code, I try to build tight feedback cycles into everything I do. I find the more I can get into the habit of making a small change and quickly seeing the result of that, the better my development cadence and therefore the easier it is to gain confidence in a path.

To lend confidence to others, I try to encourage both of the aforementioned things: fail fast to learn quickly and find ways to make feedback loops tighter.

 

We observe that a healthy culture and good tools you can rely on are the key to the developer's success.

If you are interested to learn more, you can check out these two articles:

 

don't think about it, just follow your passion, confidence will follow as well

 

Another way to gain confidence, is to write some code (small project, 100 lines) and get it running. But make sure to NOT get it reviewed by somebody.
That's utter bliss 😌. I feel like king in my own kingdom.
After many days, when I feel alone in my own kingdom, then ask somebody to review code 😛

 

Writing/preparing knowledge-sharing presentations help a lot. It helps me to understand better the topic and understanding it better boosts my confidence.

Micro-tasking also helps. What I mean by micro-tasking is that I break down goals into tiny chunks that don't take a long time to implement. As such, I can develop momentum.

Having few but key daily goals also serve to build momentum, after all, confidence.

 

High 5 people who had solved a difficult programming problem that they had spent hours or days on it

 

Honestly just collaborating and teaching others.
Really helps improve my confidence in a given area and hopefully, theirs too.
Not to say I don't feel out of place when it comes to working on large established projects.

I think the double-edged sword in computer science is you never know everything, always learning and I find as long as you are honest with your employers and colleagues when you can't do something it really helps your mental well being, knowing your limit, sadly many workspaces actively work against this and expect employees to be the master of every area of their profession with no exception.

 

I once worked for a major computer manufacturer at the operating system layer. They wanted me to code up support for file saves that had three letter extensions. I did the work and eventually the change went to world-wide distribution. A week later, the bug came back that any files without the extensions wouldn't save. Ouch...

My resolve was to read every book in their library on testing. Since then, I use testing to prove each check in. Full confidence in hand.

 

Usually I work on projects with familiar domain for me. I love games and cloud applications. So usually I build projects based on systems and technologies I saw in games and try to build things like that on cloud native services.
It's an inspirational way I have to be creative and explore new ways to build software.
Usually I suggest to people to build something based on something they love. It will make them happy to look resources around and make that project possible.

 

To build it first you have to commit many mistakes, and learn from them. What you've got to be sure is to learn from those mistakes to become a proficient and confident coder C:

 

I have a short list from past experience:

  • Looking back on things done.

  • Appreciation from someone you respect.

  • Cracking a tough job interview.

 
 

For me personally it was building stuff that works. Even of it's buggy or doesn't cover edge cases.

For me professionally it was good monitoring in production and a fast CI/CD pipeline. 🙃

 

Every time I get a job offer, whether I take it or not, I feel pretty good. Nothing more validating than "We suspect you're good enough at this that we're willing to give you a lot of money for it."

 

I will say by building more projects. Involving yourself in a Dev community. Contribute to open source. Code code code.

 
 

A fellow developer's words. Like what you did is right (or pointing out a mistake instead of judging)

 

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. No one likes a developer who say can do it and then screw it up.

I lend confidence to people by being honest about their weaknesses, so when I say something good about them they believe it.

 

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.

 

I just got to know that someone got insecure because I might anytime beat him. Surely, I have restarted with double the pace and will beat him in half the time.

Classic DEV Post from Apr 3 '19

How do you feel about chasing internet points, badges and the gamification of everything?

I'll admit up front, I'm chasing the dev.to 16-week streak posting badge and am...

Ben Halpern profile image
A Canadian software developer who thinks he’s funny. He/Him.