I recently lost a job, pretty much because my previous employer expected miracles from an entry level coder. I was tasked with reading years worth of code developed in a sloppy manner (by another coder) in a production environment where I quite literally could not debug without disrupting somebody. There were no test servers implemented. You have probably all realized that it is a lot harder to read code than to write it. (gripe over, now comes the question...)
The question is, in C#/Visual Studio how would one debug in a manner which is non-intrusive to the business environment (Remember, this is "Production") ? Does attaching to process, and attaching to a specific browser only debug for that particular browser? (there are so many features in Visual Studio it's hard to know exactly what is possible some of the time). Are there any other techniques I could use next time around to develop in a full production environment when creating a test server in the short run is impractical?
Also how does one cut through the bs- code and get the the heart of the matter when analyzing a project which is literally hundreds of files? Perhaps there is a project file system structure that could be explained for general web projects?
If you are faced with a previous coder who took all sorts of rabbit trails in his code, ex technologies which are not ever used how do you quickly learn about those technologies in time to be effective? I perhaps focus a little bit too much on reading in books, and quite frankly they take too long.
Let's squeeze one more question in, is it possible to be a "free-lance" coder, how does that work exactly? Is it practical?