Tips to Improve Your Coding and Projects

Village Idiot · 12-13-2007, 03:49 AM

I originally wrote this article over a year ago. But after going though it I fixed allot of mistakes in grammar and composition. I also added a few things.

Programming:

Plan out what you will do before you do it.
This may seem trivial, but the hour you spend doing it will save you many hours down the road. I have learned this the hard way many times. As this may seem obvious, the only reason it is such is because you just thought of it. It won’t be nearly as fresh when you come back tomorrow. I have a full guide on planning projects here.

Make your variable names as descriptive as possible.
It doesn’t matter if the variable ID doesn’t exist, if it is with a bunch of results with result_ before it, make it result_id. This will make easier for you or any future programmer to do it. I have had to work on code where everything wasn’t well named; it was a major, multi-hour pain.

COMMENT YOUR CODE!!!!
This is by far the most important one. No matter how bleeding obvious the code looks now, it won’t be in 10 days when you have a bug that needs fixing. Comment your code for other programmers and yourself. Don’t be afraid to put long comments where they are needed, they do not affect speed. Just don't go overboard, comments explain what you are doing. Don't write a small novel over what this code did to get here and its background.

If a piece of code is used allot and may be changed, make it an include.
This is one again I have learned the hard way with deadlines just hours away. An include means one change and it’s done in every file. Typing it out every time not only makes the code messier, it makes it hard to edit. Lets say your page has a header that goes into every page. You present it to the client and he finds one error. This could mean a 25 file fix up if you don’t use includes. But if the header file was an include, it is a no problem deal.

To each its own, don’t make two things in one file.
There is no crime in making allot of files for a project. If you have two different parts that are in the same process (a forums reply box and the file that actually posts it for example), use two different files.

Don’t reinvent the wheel.
You will have projects that have the same functions in part. It is not a crime to take the code from an old project and modify it, doing so gives the client better code and saves you time. I use the same code from a project I did about a year ago for a user system. Why? I use it because its rock solid code that works every time. All I would do should I remake it is rewrite the same code, possibly some bugs with it. Similar projects mean similar code, whether you take advantage of it or not.

Don’t overuse OOP
Among programming techniques, Object Oriented Programming is a pile driver. Insane power and ability, but extremely resource intensive and large. Using OOP takes a long time to process and run. The flexibility and power it provides should one be used for pieces you will reuse on large projects. If the project isn’t large, OOP may be overkill. If that piece of code doesn’t need to be reused frequently, it may not need to be an object.

Project:

Set realistic deadlines.
NEVER give a deadline you don’t think you can make, all that can do is make the client mad and you stressed. It is better to give a deadline you think you can beat, because if you make it better the client will be happier. Should you not make it early, you have time for the unexpected. The other reason you should do this is most-nighters. There is nothing harder to edit then code made by a programmer in a time crunch, even if that programmer is you. I have done most-nighters to meet deadlines before. When you are tired and running on caffeine, your code gets messier and messier to the point you can’t read what you just wrote.

Never go into a project you can’t or won’t do.
This one is bad you both you and the client. If you don’t think you can do a project, don’t try to. What will happen is you spend extra hours trying to do this, you will eventually say you can’t do this, or raise your price. The client will either leave you or never use you again and give you bad reviews. I’ve turned down many high paying projects because I did not know how to use the script they wanted modified.

Keep the client updated.
Updated clients are happy clients. I would never go back to a programmer who tries to avoid contacting me on what’s going on. I would want a programmer who messages me when I come online, telling me what’s being done. Even if it is not a complete module being finished, I still want to know it’s being worked on.

Never compromise your price.
I’ve had clients come to me with a CMS project for $300. In a money crunch, $300 sounds awful nice, you might be almost inclined to accept. Just take into consideration what you are doing to yourself. You are working just as hard on a project for less money. When a project for a fair price comes up you must turn it down because you are busy. It doesn’t end there though, if somehow it goes public that you gave a cut rate job, there will be people left and right asking you for a cut rate job. You don’t want a reputation for that. There are people who will pay the higher price for a good job. It is better to wait for a good one to come then to compromise your pricing standards.

I have also found that the ones expecting cut rate jobs are the hardest clients to work with. A low price either means they have no experience in what it takes to make a site like they are asking for, or they just don’t care. Either way, a bad price is a warning sign of a hard to deal with client.

Don’t work for free
This could be categorized in the same place as the previous tip. But I feel it deserves its own paragraph.

Any programmer who has been in the business for a while has had many people asking for free work. Generally they are broke kids looking for a free script. They generally make promises they never intend to keep, the common ones I hear are

When the site makes money you will get X% of it
I am outsourcing you, if I like your work many paying projects will follow
This will look great on your portfolio. We will both become rich off of this!.

All these have problems. One and two require the unchecked honesty from the client over money. Legally speaking, he could run with your code and there is nothing you can do about it. The final one is true, but if you need to expand your portfolio, you should not do it for someone else. If you need an extra project to show clients, do it for yourself or a paying client. That way you maintain the rights to the code and can use it whenever you want.

Make your terms clear before the project start.
I have had clients mad at me to the point where they left me even though I had the upfront fee. All because I wouldn’t do an addition for free. Clients don’t know how it works, even if they think they do. You would be surprised at what clients have asked me to do for free. The best way around this is to make it as clear as you can what you will do, what you will not do and what you will charge more for. I make sure all my clients read my policies before I seriously consider doing the project. That way if something comes up you have something on your side so he had no right to get mad.

Give the client his moneys worth, always.
No matter who gets the short end of this, give the client what he paid for. If the job takes half the time you expected, he will still give you full money. But if the project took longer then expected, still do a job to its fullest. Happy clients return to a programmer that gave them what they wanted, it is good for future jobs to keep your standards high. Returning clients generally pay well because they know you aren’t a scam.

Always have an upfront
When I was just starting things to program professionally, I had a return client come to me for a project. I did multiple projects for him before, easy to work with and trustworthy. He wanted a mail script for a smallish amount of money. It was a fast job, so I didn’t require an upfront. When I finish, his paypal isn’t working, since he outsources me he has a deadline and needs to relay this to his client. He offers me hosting in return for the money, but I don’t need hosting so I decline. I then tell him since I trust him I will give him the files if he will pay me when he gets it fixed. We agree and he gets the files. He stayed in contact for about a week with excuses I didn’t really believe, but I didn’t want to start a fight. It He never replied back. I got scammed by a client who I had a rather long history with. The moral of this story is always charge upfront and never give out the work until you are payed. Even clients you trust could go bad over it. I should also add that the amount was $35. Yes, he went bad on me even with a extensive history over $35.

Happy programming!

If you like this article, please digg here
http://digg.com/programming/Tips_to_...cts_and_Coding

Find this article and others like it at http://tips.justanotherportfolio.com/

maZtah · 12-13-2007, 11:22 AM

Great read. Thanks for sharing!

bdm · 12-13-2007, 12:04 PM

Very nice read indeed.

Thank you.

sjaq · 12-13-2007, 01:56 PM

These are some great tips.

Thanks

sketchMedia · 12-14-2007, 12:22 AM

Thanks for the article, good read indeed.

one thing i will add tho, while i agree you should comment code, i believe (and was always taught) not to over comment, there isnt a single thing worse than code that is obstructed by a small novel being written about a simple function or a an echo for example, you need to implement some common sense on that.

Karl · 12-14-2007, 01:42 AM

Very nice article. In addition to sketch's reply, I recently read an interesting alternative to commenting (a trait of eXtremeProgramming, I think), whenever you need to add a comment to a block of code, add that block of code to a new function and name the function something that explains the code (like the comment would have).

ibndawood · 12-14-2007, 05:48 AM

Quote:

Originally Posted by sketchMedia

there isnt a single thing worse than code that is obstructed by a small novel being written about a simple function or a an echo for example, you need to implement some common sense on that.

lolz...Agreed!



thats the best explanation for commenting

ibndawood · 12-14-2007, 05:51 AM

oh! I forgot to say..Great Post mate!
Thankz

Village Idiot · 12-14-2007, 02:57 PM

Commenting section revised, thanks for the advice.

Thanks for the compliments all.

bdm · 12-17-2007, 01:27 PM

Quote:

Originally Posted by sketchMedia

one thing i will add tho, while i agree you should comment code, i believe (and was always taught) not to over comment, there isnt a single thing worse than code that is obstructed by a small novel being written about a simple function or a an echo for example, you need to implement some common sense on that.

I once worked with someone who commented EVERY line of Javascript he wrote.

javascript Code:

<!-- assign the value of 1 to a -->
var a = 1;

<!-- assign the value of 2 to b -->
var b = 2;

Haris · 12-17-2007, 02:28 PM

Quote:

Originally Posted by bdm

I once worked with someone who commented EVERY line of Javascript he wrote.

javascript Code:

<!-- assign the value of 1 to a -->
var a = 1;

<!-- assign the value of 2 to b -->
var b = 2;

Pure insult of other programmers.

Nor · 12-17-2007, 03:28 PM

Quote:

allot

should be a lot.

Quote:

Always have an upfront

I disagree I feel the clients should see the code in action(php wise) before they pay, then get the code. (never do this with javascript or html, always provide screen shots if your coding someones template).

Village Idiot · 12-17-2007, 03:37 PM

That means you have never been screwed by a client who decides he doesnt want to hire you after you do 10 hours of work. Without an upfront, all your work is to waste. An upfront keeps the client with you. All my clients pay an upfront and the rest after seeing it.

Nor · 12-17-2007, 03:54 PM

Quote:

Originally Posted by Village Idiot

That means you have never been screwed by a client who decides he doesnt want to hire you after you do 10 hours of work. Without an upfront, all your work is to waste. An upfront keeps the client with you. All my clients pay an upfront and the rest after seeing it.

Nice assumption but false, I've never got screwed. People believe how they want to handle clients they way they want. Based on your article doesn't mean everything will follow your ways. And a waste? Not really more of another experience you can do a lot with the code tthat you created sell it and adding it to your portfolio saying that you've did that before. Unless your coding PHP as a life time goal a major business then sure why not, other then that no I feel that way isn't a need. PHP is a hobby not a job the extra money helps out some. Note I've done upfronts before and other times I do it my way it just depends.

Haris · 12-17-2007, 04:05 PM

Quote:

Originally Posted by Nor

Nice assumption but false, I've never got screwed. People believe how they want to handle clients they way they want. Based on your article doesn't mean everything will follow your ways. And a waste? Not really more of another experience you can do a lot with the code tthat you created sell it and adding it to your portfolio saying that you've did that before. Unless your coding PHP as a life time goal a major business then sure why not, other then that no I feel that way isn't a need. PHP is a hobby not a job the extra money helps out some. Note I've done upfronts before and other times I do it my way it just depends.

Zend and other expert PHP companies won't be impressed. Some people don't take internet earnings as a hobby but live on it.

Your point is invalid. Sorry.

Village Idiot · 12-17-2007, 06:36 PM

Quote:

Originally Posted by Nor

Nice assumption but false, I've never got screwed. People believe how they want to handle clients they way they want. Based on your article doesn't mean everything will follow your ways. And a waste? Not really more of another experience you can do a lot with the code tthat you created sell it and adding it to your portfolio saying that you've did that before. Unless your coding PHP as a life time goal a major business then sure why not, other then that no I feel that way isn't a need. PHP is a hobby not a job the extra money helps out some. Note I've done upfronts before and other times I do it my way it just depends.

There are a couple problems with your post
1. 99% of the projects I do are stuff I already mastered. I don't learn anything form them.

2. Most projects I do have code which is too specific to reuse in another project. They normally don't dump you at the end, so you are suck with a useless half done application. This has happened to me before, more then a year and ive never been able to resell or reuse a single line in it.

3. I don't need another project on my portfolio, it includes all I need to get business.

I program for a living, so my methods have to be more serious then someone who programs for fun. But hobby or not, why shouldn't you use the smartest methods to make money?

Nor · 12-17-2007, 06:43 PM

I'm not saying the smartest method is wrong, I'm saying in most situations the smartest situation isn't the choice I always choose. But I see your point.

Village Idiot · 12-17-2007, 06:44 PM

Any client who is not willing to pay an upfront isn't worth working with.

Nor · 12-17-2007, 06:45 PM

True......

TerrorRonin · 12-17-2007, 08:48 PM

Great tips, i'll take them into account :)