There are probably many different thoughts on when you should introduce certain concepts to a new (or junior) software developer. Before they start coding, during the coding (see pair programming) or after some coding. You can't introduce them to message queueing, standards compliance or layered architecture in the same day or week. Their head will explode.
Before they start coding, every developer should read Code Complete by Steve McConnell. That's a given. Currently in it's second edition (note: I prefer the first edition), the information here is so fundamental and so common sense. I might even argue that a good hire would already have this book on their bookshelf.
To be honest, during the coding, a junior software developer should rely on their tools, their team lead AND the documentation. Learning to rely on documentation, understand it and question it will improve their code. Learning to trust your tools, i.e. understand what they are telling you, will make you into a craftsman. Learning to ask for help from your team lead will keep a junior member on the team. No kidding.
After some coding, I would recommend reading this excerpt of Chapter 29 of Pattern Languages Of Program Design by Harrison, Foote and Rohnert. Probably the most entertaining chapter of the book, it is chock full of descriptive examples of systems with little to no design, such as:
often takes on a life of its own, despite casual structure and poor or non-existent documentation... Systems and their constituent elements evolve at different rates... The class of systems that we can build at all may be larger than the class of systems we can build elegantly, at least at first... architecture frequently takes a back seat to more mundane concerns such as cost, time-to-market, and programmer skill... Individual portions of the system grow unchecked, and the lack of infrastructure and architecture allows problems in one part of the system to erode and pollute adjacent portions.... some engineers are particularly skilled at learning to navigate these quagmires, and guiding others through them. Over time, this symbiosis between architecture and skills can change the character of the organization itself, as swamp guides become more valuable than architects... Maintenance needs have accumulated, but an overhaul is unwise, since you might break the system...