I'm busy! Most of my time is spent using analytical techniques, or on course work, and when I switch over to programming mode I need to generate code quickly. Since, the Primary Investigator for the lab I'm in doesn't care if I'm using TDD or an abacus as long as I get results fast.
I've read "TDD by example" and found it quite helpful. I subsequently bought "Refactoring: Improving the Design of Existing Code", "Design Patterns: Elements of Reusable Object-Oriented Software", and "Working Effectively with Legacy Code" but these book are large and the prospects of jumping into them now is daunting!
The conversational style and flow of "TDD by example" made it easy to incorporate into my schedule. But, I don't know how to work in these other books and in which order; it seems that each is just as relevant (I'm in a kind of Dining philosopher deadlock - I'm waiting for each aspect of my programming toolkit to improve but their interdependency has me either gridlocked or loosing time to context switching - sorry for the analogies :) ). e.g. I have legacy code that needs to be refactored and covered with tests, I need to push forward using TDD (but I never do), I need to code with design patterns so I stop reinventing wheels.
Is there a good way to break down these required reads into byte sized chunks and a way to do so while applying their techniques to current projects (personally, I loose the information if I can't apply it right away)? Do I focus on one book and complete it? Do I need TDD first then refactoring and design pattern skills (but 'chicken and the egg' all these unit testing books talk about design patterns and refactoring as if I know them backward and forward)?
I've read the best tutorials for beginners but it doesn't explain how I integrate this into a busy schedule. And, I read programming in a scientific environment but again it misses the mark of how do you add these techniques when you already are behind on time.
Given the description of what you do, I would first start with questioning the assumption. I don't know anything about the complexity of your programs, but if your coding consists strictly of generating calculations and it is kind of "script-level," meaning that for a given piece of code you could just as easily throw it out and rewrite it as keep it, then a lot of these techniques are overkill. I think TDD (perhaps a paired down version that kind of combines in integration testing) will always be valuable, but beyond that, not necessarily.
If however, you are really designing software systems (and at least some of what you might be doing might qualify even if all of it does not, for example database model, input screens, result distribution) then I would say read enough of these books to get started, and don't worry about not doing it right all the time for starters, just make sure you are making measurable progress every week.
By the way, design patterns can be useful to read about how similar problems are addressed, but don't "design using them" instead of something else. Your design may not be good on its own, but patterns come from real-world design, not the other way around. So you can certainly see more object oriented solutions that what you may be doing, but don't worry about if what you are doing fits a design pattern. Make sure that what you are doing is good maintainable design on its own terms, and the patterns will flow from that.