Confidence

I love this topic. I've definitely been in a situation where I'm just making small fixes to a project that has so many issues that it feels like there's no end in sight. Or it took much longer than I thought it would to ramp up on a technology. It's hard to not internalize that difficulty and think it's your fault. But technology is weird and doesn't usually make sense.

At those times I try to focus on the small improvements I've made, or on the concepts I've learned, even if I have a lot more to learn. It's easy to ignore how far you've come when your destination still isn't that close.

I think feeling a lack of confidence is a natural reaction when you care about your work but you don't see the results you want. But sometimes the technology you're working on is just to get the business to the next stage, and it doesn't need to be maintained forever, or you just need to understand a certain aspect of a new technology and not the whole thing in and out. I've found breaking a big intimidating goal into smaller more achievable goals helps.

If you're stuck on an issue, switch contexts and get some easy wins. Walk away from what you're doing and tackle some small things. That's actually a benefit of having a bunch of open issues - there are probably a few trivial ones you can knock out quickly. Even if they aren't high priority, go close a few small issues. You'll feel better every time you close one, and as a bonus you'll give your mind some time away from the issue you're stuck on. You'll find yourself more refreshed when you switch back and you're more likely to solve the problem.

The same is true for trying to grok something that is more difficult. Take a step away and find ways to build yourself back up before returning. It's also helpful to find "real world" examples of the tech in use. Often documentation or tutorials are purposely simplified to "prove" how easy something is, which makes them near useless when transferring that idea to a real world problem.

I totally disagree that tech is weird and doesn't make sense. You might have to look into the history of a tech, and find out why it was created, what problems were they solving, and what prior work existed that it was improving or was based on, but it almost always makes sense in those contexts.

For instance, why does Ethernet have the ACK response and a sliding window? Look at the Aloha network that existed before it and it makes perfect sense. Look at it out of context and it might be hard to understand.

I'd suggest to any junior dev the first thing you do when learning a new tech is to read on its history.

Finally, comparing yourself to others is okay, but again it should be in context. I've been writing JS for decades. I wouldn't sit down and try to write a JS interpreter. There are a lot of people with more skills in that area than I, and that's okay. Similarly, I don't expect our juniors to write code at my level or be able to see code smells as quickly as I can, and I hope they aren't feeling bad when they compare themselves to me. They should be making the comparison, just like playing people better in chess than you is the only way to get better, but you shouldn't feel badly if you're not on the same level.

You should be careful, as already stated, to evaluate not just where you are but how much you've progressed. Two people may both be juniors but one is 22 and has been writing code since they were 12 and the other is 35 and has been writing for 3 years. That's just not a fair comparison to put on yourself.