Usually it means you think in terms of Tactics instead of Strategy.
Let me give you a clear example - take a look at this Code Review question and some of the first few answers: https://codereview.stackexchange.com/questions/88190/survivor-programming-challenge
There was a lot of focus on tactics there. Whether to use Arrays, ArrayLists, or whatever. How to form the loops. Removing vs Flagging. Etc, etc.
But I was the only one who said, "Wait, let's step back for a second. What is it we're trying to do, and what's the best way of doing it?" Everyone else was focused on Tactics instead of Strategy.
And that's ultimately the Endgame for quality software engineering: continuously trying to see if you can solve the problem better by making it one level more abstract:
- Level 1: "Well, this uses two loops and a recursive function call..."
- Level 2: "That recursive call is expensive though. But if reorder it like..."
- Level 3: "But this function isn't needed, because when we do this sort of request..."
- Level 4: "Why is this request serviced in this code? The floobar process already handles..."
- Level 5: "Wait, the business area needs this because of X. But wouldn't it be better to accomplish X through Y instead of what we're doing?"
When we jumped from 1 to 2, we improved the run speed of a program. When we jumped from 2 to 3, we not only improved performance, but we also removed unnecessary code. When we jumped from 3 to 4, we reduced the proliferation of duplicate code company-wide. And when we jumped from 4 to 5, we improved how the fundamental method the business needs were met.
You can't always do this. Sometimes you have to actually program in level 1. But... as you get more experienced, you'll find that the more time you spend in the upper levels and the less time you spend in the lower levels, the more productive/valuable you'll actually be.