Not trying to understand a problem. When something goes wrong with the software you're developing or the tools you're using, your first instinct should be to figure out what went wrong and why it went wrong.
Some junior developers have a tendency to jump to possible solutions without trying to understand the problem. This is a common tendency when the problem is too complicated to be understand -- it's why we tell people having trouble with a computer or electronics to power it off and on, or reinstall -- because these are solutions that fix lots of problems, and they can be a cost-effective use of time. But what they don't do is tell you what the problem is. And when your job is the creation and maintenance of software and there's a problem with the software or a problem with the tooling, it's valuable to you to understand the problem with the software or the tools, and jumping to solutions won't tell you that.
Of course, sometimes it's hard, extremely hard to find the problem, and I understand that sometimes you need to make decisions about whether it's cost-effective to continue to diagnose the problem. It's ok to make those decisions, but they should be conscious decisions.