What you may have here is someone who may be utterly lost in the details and is not abstracting away from them well enough to keep in mind the primary goals. A example of this kind of problem would be someone who when driving, instead of looking far ahead, looks down at the road immediately in front of the vehicle in an attempt to stay between the lane lines. This will work well when the road is straight but not so well when the road curves, and of course if they're that focused on the lane lines they're almost certain to miss the cross street at which they're supposed to turn.
High-level Goal Summaries
One thing you can try is to ask the developer to first write a high-level summary of the task to be accomplished. This should be no more than a few sentences; if the task is large enough that it requires even a couple of paragraphs, break it down into several different tasks. (If it's complex enough that it can't easily be broken down into independent tasks, you should probably assign it to someone else for the moment.)
Review and discuss this summary with the developer before they start in on doing the work itself. While in the long run you should not be writing the summary for the developer (the point of the exercise is to have them practice extracting high-level goals from the full set of high- and low-level information they're encountering), at first you may need to walk them through the process by showing them how you would write it so that they can see examples of how good summaries should look.
Once the task is "done" (in the developer's opinion), they should compare the result with the summary they've written and decide whether the goal has been achieved. Only then should they come to you where you can make the same evaluation and, if your evaluation of "doneness" doesn't agree with the developer's, you can have a discussion about that.
Writing these summaries is likely to be quite difficult, and the junior developer may not have the skills to do it. As Edsger Dijkstra said, "Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer." Unfortunately I have little advice to give in developing the language skills necessary to do this except "compare your attempts with a lot of good examples and practice a lot."
Once this basic concept is working, there are two things you can add to these little "stories" to help continue the training and improve results.
The first is a checklist of further requirements that need to be met that are not part of the high-level goal. This is where you work on issues with forgetting details and being sloppy. Some of these would be specific to individual tasks and should be kept with the summary for that task, such as "ensure buttons are properly aligned and centred" when the task involves adding a new button to something. Others will be general items that apply to everything that you introduce step by step, such as "ensure there are no misspellings" or "ensure indentation is consistent." All of these things should be in a a form that can be walked through like a checklist; the developer should check each item before declaring the task complete and you should go through each item with the developer and, if any of those requirements are not met, discuss with the developer why they felt those requirements were met. You'll want to add general items very gradually; ideally after concentrating on a new general requirement for a few weeks it will become automatic and can then be removed from the list.
Eventually, as the developer gains the ability to understand these details, you can introduce the higher-level goals that motivate these details. For example, code formatting is not important in and of itself: it's something you do in the service of the goal to better communicate with other developers. (This is essentially moving along the Dreyfus model levels of skill acquistion, described by Benner as novice, advanced beginner, competent, proficient, and expert.)
The second is a brief analysis of the business goal of the task. This is essentially a higher-level version of "looking at the road far in front of you"; developers will do a better job of implementing things if they understand the business goals (which are often, in the end, the only reason the developer is implementing anything at all). I suspect that this is something your junior developer will not be ready for for some time, but keep this in mind as one of your long-term goals and if you happen to find that introducing it earlier works (perhaps the developer really does pick up understanding of business stuff easily and knowing business goals would better motivate them), do so.
The techniques I've described above are not something just for junior developers; good senior developers do the same thing, though often in less formal ways. My internalisation of the "communicate clearly to other developers" goal makes things like ensuring my code is well formatted an automatic action. The summaries I described above may be just in my head, but there are plenty of programming situations where my serious work didn't really get started until I stopped writing code and instead started writing up a header comment in the file explaining the overall goals and how the code structure helped to achieve those. And there are plenty of commits that got a good rewrite (or even just got deleted) after I'd "finished" them and attempted to write a comment message explaining to the other developers what I was doing and why.
Just as writing code forces you to confront misunderstandings that you didn't see or glossed over when you were whiteboarding pseudo-code, writing down a summary of a goal for someone else to read does the same. So train your junior developer to write these out, ensure that they make sense to someone else, and compare what they've done to the summary after they're done.
When they achieve some compentence in this, gradually add to this other points that will help them remember to address details that they forget and learn about the larger scope of what they're trying to do.
Metaphorically, teach them to drive by looking at the horizon ahead of them, rather than the bit of road immediately in front of them.
In the end, this may or may not work. You may not do this well enough yourself that you can teach others, or they may be unable or unwilling to learn. In that case, the best solution might be to move them to a job other than software development (or engineering in general) where managing technical details and getting them all to correctly serve high-level goal isn't a central component of the job.