«
»

Web Handyman For Hire

Yeah… and I’m gonna need you to do that again, tomorrow…

OK, I know it’s been a while since my last post but I have an excuse.

I took on a web development gig where I’m creating new sites as well as updating sites developed by others. (Well, mostly the latter actually.)

If you’ve ever had to support someone else’s code (or even edit your own, six months later), you’ll know what a crapshoot joy that can be.

Since most of the websites are written in scripting languages I don’t know (!), I’ve had to get up to speed very quickly on several languages, in addition to learning the architecture of the environments in which they’re hosted.

It’s a lot like being a web handyman in an apartment building – you have no idea what’s going to go wrong next, or how crappy the last guy’s work was, but if (when!) anything goes wrong you’d better get it fixed pronto!

Yeah… Lot’s of fun.

So how am I coping? Here are a few pointers.

1. Find reliable resources fast

If you can’t rely on your own mastery of a language, you need reference material to remind (or inform) you of proper use and syntax. For PHP, I love php.net and W3Schools.com for syntax help. The comment section on php.net can often steer you exactly to the solution to your specific problem, but you can get lost in there too.) Plus, where appropriate, PHP.net includes both procedural and object-oriented example code snippets.

For ASP classic (yes, that was no typo), I’ve found that W3Schools.com can help me translate my “native” PHP into the ASP equivalent. (Don’t get confused by them referring to everything a vbscript.) Cold Fusion “fans” can use Adobe’s livedocs site.

2. Document what you learn

You’re going to be like that vaudeville guy spinning the plates, keeping lots of customer sites up a running. You don’t have time to re-learn how to spin each plate every time. So, every time you learn something new about one of your orphan sites DOCUMENT IT.

Chances are the sites you support weren’t documented very well (if at all), especially if more than one code monkey has been working on them. So when a customer has a data problem that you solve, make note of how you fixed it. When you’ve spent ten hours tracing through a convoluted function, summarize it. You get the idea.

Every hour you document will save you many hours down the road. Really, if the code is a bitch to read, why would you make yourself do it more than once?

3. Adjust your approach

This one may raise some hackles, but hear me out. When you’re creating your own app or website, you can make it as beautifully crafted and perfectly architected as you want. When you’re playing in somebody else’s sandbox, though, you’re going to have to stop trying to be perfect and focus on getting the problem solved.

So maybe the original developer didn’t organize things exactly the way you might have. That’s no reason to insist on rewriting everything just to get a simple fix made. Eventually, every website is going to be tossed – either the owner goes belly up or they ask for a total redesign. Take THAT opportunity to be perfect, but in the meantime just get the problem solved.

Similarly, while in your heart of hearts you want to be working with cutting edge technology, that won’t matter when your customer needs a fix to her ASP classic website. (Yes, I said classic.) To paraphrase a recent US Defense Secretary…”Do the job you have, not the job you want.”

I hope my observations help a few of you who find themselves in similar straits. Do you have any other suggestions (apart from run away!) that might help? Comment away.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>