Tips To Improve Your Coding And Project 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
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!
"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."
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!.
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!
0 comments:
Post a Comment