Most developers start out their career with an aversion to knowing the failure modes of the software that they write. They treat the software that they write as their baby, and don't like to see it get hurt. This isn't necessarily a conscious decision but more a subconscious mind-set. So when I am coaching a junior, one of the things I concentrate on is breaking them out of this mind-set.
The “Try to break your design and your code” mind-set should be applied throughout the process of developing software from the initial design in your head to implementation and testing. When I design an algorithm on paper, after ensuring its correctness in a normal scenario, I then start trying to break the design. This usually entails thinking about data which could occur but that might not fit the normal scenarios, to thinking about what would happen if say the process failed with a thread abort exception, to timeouts in the database or other external failures.
During the implementation phase my attempts at breaking my code are centered around the automated tests that I develop, I can physically test the design resiliency when receiving strange or bad data, I can throw exceptions from calls to data layer methods, run load tests to test the behaviour under load.
When I am reviewing the design of an algorithm of a colleague or of another team I use a line of questioning technique to test the correctness of that design. I usually have to warn the person that I will do this because it might seem that I am being very negative or attacking their design personally but what I am doing is I am trying to find all the failure modes of that design. Hopefully this test of the design occurs before the implementation but unfortunately many times the implementation has already been completed and the design errors in the solution need to be scheduled.
Another benefit of using this line of questioning technique is that the developers who are open and want to learn can see this thought process of questions and can then apply the technique to their own work.
Those developers who are not open, especially the developers who are defensive, can be agitated by this line of questioning. With these guys I have to work harder to explain the reasoning behind the questioning and that it is in order to validate the design and not an attack. But the better developers, meaning the ones with a better attitude, greatly appreciate someone coming in and trying to break the design and learn this technique to better their future designs.
So while this mind-set is not overly common in junior developers, it is a skill that can be taught. The best way I have found is to go through the process of breaking their designs through lines of questioning and in talking with that developer about that line of questioning and why we do it. Usually the developer can find the solution themselves with a few more well placed questions. This tends to stick in their minds better than being told what to do.