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.
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.
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.