The answer to your question would occupy volumes. But hopefully I can give you some good pointers.

First off, a good technical spec starts with a good nontechnical spec. I would recommend a book on Use Cases. Your biggest battle will be to convince nontechnical people around you to produce specifications that lend themselves to a good technical specification. Take the challenge on as you would any good technical problem: Evangelize, inform, educate, and push them to do what makes your life easier. Induce them in any way that you can to produce use cases in conformance with a use case template that you find useful.

Secondly, I would adopt an OO approach to coding. This not only has advantages insofar as it improves your coding abstraction, but there are a gajillions tools available to software engineers who adopt the OO approach. Read a book on UML. I've found "Using UML: Software Engineering with Objects and Components" by Perdita Stevens to be a good introductory text. If you don't use some commercial product like Object Domain or the (in my opinion overpriced) Rational Rose in the workplace, try Dia, an excellent open source UML modeling tool. Also consult other sources of engineering knowledge, such as the "Gang of Four" book on design patterns.

Finally, I would be patient. Absorb as much as you can. Continue to familiarize yourself with proper techniques as you develop in your career. But recognize that the ability to write a good technical spec comes as much if not more from experience than from textbook knowledge. You may find that you only apply a fraction of what you learn in the workplace depending on such things as time and resource constraints. But you have to learn it all in some capacity to know which fraction to apply.

Hope this helps :-)