question

Tsk tsk. Honestly... sooner or later you need to learn that there are circumstances where it is BRILLIANT entertainment to eschew such things as: - Meaningful commenting (trust me, you're better off commenting only insofar as it involves commenting out vast blocks of unneeded SQL, but never say why). - Sensible attribution (if you've copied someone's code and it's better than what you could write, pass it off as your own). - Meaningful object names (instead go for col2, col2a, Col-2b, COL_3) ...and so on. Consider the following situtation. You decide to set something up from scratch. You're not formally qualified to do database work, but your boss is not "techo" either and doesn't get the significance of the deficiency. And it looks like fun. All those neato green ticks and progress bars whirring away in the installer. Databases are so cool! So you convince your boss you can save him or her $80,000 over the next three years if you have a stab at it yourself. You take the plunge and make a bit of a pig's breakfast of things. Because you're only accountable to the IT equivalent of tepid custard, you can drag this situation on for years. "It runs slow because we have slow hardware." "The problem's not the database, it's the user." "It's a very complex question..." Then one day... you get promoted (oh yes you do, cos you're the hero who set up "the system"). Now you can start to cash in and have some real fun. This is when you recruit some poor feckless sap into your old position; he or she will be COMPLETELY at your mercy. Because there's no doco, no orientation, no handover, they will have a choice between: 1. Spending days forensically picking through your spaghetti, to get even the most mundane and basic tasks done. Remember they will work hours of unpaid overtime early on just to make a good impression. 2. Grovelling to you to show them what your code is supposed to do. Now you get to roll your eyes and look with annoyance at your watch. Give them a few snippets of code that look related to the problem at hand, but in fact are not. Ultimately they'll lurch back and forth hopelessly between both options and you'll be able to ride in on your white horse and save the day endlessly, all the while winking at YOUR boss and explaining in that oh so avuncular way, that "the newbie is taking a while to settle in, but I'll sort him/her out." With any luck you could get yourself a payrise as well as the promotion. "We had no idea you were so indispensable Smith, until we saw that prize fool that came in after you. And he/she came with such good references too..."

+1 GPO. Very droll. Next (serious) question should be "What's the best way to deal with substandard work you've inherited?" Apart from giving people a good laugh, there's not much value in badmouthing the previous incumbent because 1. You don't know the pressure they may have been under to put code into production. We've all delivered stuff we weren't totally happy with. 2. We all learn (hopefully). Ever gone back and looked at code you wrote six years ago? The chances that you have not learned better ways to do things should be remote. 3. They may be perceived as a valued member of the organization, in spite of the mess they left you. 4. Whining won't fix anything. All I can suggest is "Keep plugging away and try not to stoop to the levels you've inherited."