Today's Posts Follow Us On Twitter! TFL Members on Twitter  
Forum search: Advanced Search  
Navigation
Marketplace
  Members Login:
Lost password?
  Forum Statistics:
Forum Members: 24,254
Total Threads: 80,792
Total Posts: 566,471
There are 762 users currently browsing (tf).
 
  Our Partners:
 
  TalkFreelance     Business and Website Management     Articles From The Experts :

Tips to Improve Your Coding and Projects

Thread title: Tips to Improve Your Coding and Projects
     
    Thread tools Search this thread Display Modes  
Prev Previous Post   Next Post Next
12-21-2006, 05:13 PM
#1
Village Genius is offline Village Genius
Village Genius's Avatar
Status: Geek
Join date: Apr 2006
Location: Denver, CO
Expertise: Software
Software: Chrome, Notepad++
 
Posts: 6,894
iTrader: 18 / 100%
 

Village Genius will become famous soon enough

  Old  Tips to Improve Your Coding and Projects

Coding:

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. Mapping out for any one man project should be a word document with a layout of your database and what each file will do. As this may seem obvious, the only reason it is such is because you just thought of it. It wont be nearly as fresh when you come back tomorrow.

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 wont be in 10 days when you have a bug that needs fixing.

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 is done, typing it out every time not only makes the code messier, it makes it hard to edit. Should you have a header that every page has, you make it to what the client wanted, but it had one mistake that the client wants fixed. It will be a no problem deal if you use includes.

To each its own, don't make two things in one file.
There is no crime in making allot of files for a project. All you can possibly do with this is make the code easier to manage and edit should it be expanded in the future. If you have a file, lets say its for a forum that gives the interface for a post edit and does the back end functions, it should be two files.

Never reinvent the wheel.
You will have projects that have the same function in part, it is not a crime to take the code from an old project and modify it, it gives the client better code and saves you time. I use the same code from a project I did about a year and a half ago for entering text with preserving break lines and converting BB code to HTML on about half of my projects. Why? Because its rock solid code that works every time, all I would do should I remake it is remake the same code, possibly some bugs with it. Similar projects mean similar code, whether you take advantage of it or not.


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 slack time. 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, when you are tired and on caffeine, your code gets messier and messier to the point you cant read what you just wrote.


Never go into a project you cant or wont 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 cant do this, or raise your price. The client will either leave you or never use you again and give you bad reviews. Ive turned down many high paying projects because I did not know how to use the script they wanted modified.

Keep the client updated.
I cant stress enough how you must keep the client updated on what progress is being made. I would never go back to a programmer who tries to avoid contacting me on whats going on. I would want a programmer who messages me when I come online on whats being done, even if it is not a complete module being finished. I would want to know what you where working on.

Never compromise your price.
I have had clients come to me with a CMS project for $300, I was in a little money crunch and that $300 looked real nice. At one point I would have said yes. Just take into consideration what you are doing to yourself. You are working just as hard on a project for less money, and when a project for a fair price comes up you must turn it down. It goes past that however, if somehow it goes public that you gave a cut rate job, there will be people left and right asking you. 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. They want a gem for what little they gave you.

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 wouldnt do an addition for free. Clients dont know how it works, even if they think they do. You would be suprised 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.

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. I might also add the returning clients will pay well because they know you aren't a scam.

New tip
Don't give your work with a promise of later payment
About a month ago I had a return client come to me, multiple project history, 100% trustworthy. It was a mail script for a smallish amount of money. When I complete 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 didn't want to start a fight. It has been about a month now and he doesn't reply to my messages. I got scammed by a client who I had a rather long history with. The moral of this story is 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 dark on me even with a extensive history over $35.

Happy programming!


Feel free to post this anywhere so long as there is the below line.
Written by Village Idiot of TalkFreelance .

     


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

  Posting Rules  
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump:
 
  Contains New Posts Forum Contains New Posts   Contains No New Posts Forum Contains No New Posts   A Closed Forum Forum is Closed