Programming is an art. I [You] do a lot of business that starts off with "…and my developer just isn’t around anymore…" Dozens of statements could come before or after that but no of those statements change the meaning. Quite simply, you are [I am] about to look at someone else’s code and that person may be an expert programmer or a newbie borrowing snippets from other people’s examples. The code may be documented correct or incorrectly or not at all. Regardless, you [I] have to work with that code no matter its state or quality.
If you are a professional software developer, or aspire to be one, you will need to know a lot of of things. Various maths, stats, languages, frameworks, methodologies, tools, etc. Fads and buzzwords will come and go, all during your career. You’ll master some, ignore some, laugh at some. … You have got to be able to read other people’s code. [Source, Design by Gravity, How to Read Other People’s Code — and Why]
Worthwhile read by Christopher Schanck
Rule 417: You will work every bit as hard or harder on small, low budget jobs as you will on large jobs.
Note: This rule is unbreakable.
Between 2am and 6am I can knock out a bunch of work! No phones ring. Even the dogs don’t need walking. Since I got up at 2am and have been diligent in my work, when Cathy woke with a migraine this morning, I was able to send her back to bed and move my work upstairs. Being upstairs with one eye on the children and one eye on the screen slows me down a little but conceptually I could take 4 hours off (realistically I need to keep pounding keys hard and fast) but the stress is off. I don’t think I could do this from an office.
The mental exercise of jumping from one project to another at a rapid pace with breakneck deadlines is like making a bootleggers turn at interstate speeds particularly when the environment of each project changes slightly or even drastically such as CF with MS SQL to CF with MySQL to ASP with MS Access. I’m sure this either good for me or the seed for a tumor.
Every now and then you get a phone call that goes something like this "That code you wrote for us a year (or more) ago doesn’t work anymore. We were thinking of doing more work with you but if we can’t get this fixed we may have to go with someone else." The proper answer is "No problem. That will be $x per hour to troubleshoot since we do not currently have a contract." The real answer is usually "ok. I’ll look into that real quick." because a) you know darn well the real answer will send them packing b) you are a nice guy and like them and c) you haven’t yet reached a level of financial stability to be blowing off customers (note: you’ll fix c if you use the real answer more often).
When your code doesn’t change and after a length of time it suddenly doesn’t work, the problem is almost always with the web host or the client. Sometimes they have discovered a very well hidden bug but rarely. In my case, the permissions on the directory which the application used to upload files had changed to not allow for uploading. How do permissions magically change? They don’t.