I have always given myself credit for particularly one thing, and that is that I can be fast as hell in development. Not until recently I have come to understand, with some help from both my employer and fellow co-workers, that being quick is really not that good.
This is what I have realized:
- Try to avoid copy-pasting code. Sure you can benefit from rewriting a lot of similar lines of code but more than often you will end up correcting stuff. A great example is copy-pasting SqlCommand.Addwithvalue("@ParamName", value) into 20 or so lines thinking you might just replace "@ParamName" with something else for each line. You do that, run the debugger and find out that you have forgotten to replace 1 parameter name. The extra amount of time needed to locate this is questionable in relation to the time you could have spent REALLY writing correct lines.
So instead of copy-pasting often used piece of code, figure out a way of putting the data into a function or array. Typing each line individually with care and ease can also do the trick. It is so f*****g frustrating to go back and correct so small and simple errors.
- Never ever ever show a version of your app to a customer if you are not 200 % positive it won't crash
Need I say more? Customers hate faulty software, even if the bug is insignificant in your eyes.
A conversation could go something like this:
Software: "BLING! Reference not set to an instance of an object."
You: "Oh…that…"
Customer "Hmm…" (starts looking at his watch and trying not to reveal his annoyance)
You: "Oh yeah that is really not that big of a deal… the client entered an invalid value that caused tiny runtime error in the dataaccesslayer…easy to fix not a biggie."
He does not care about your bugs, all he cares about is whether what you are showing him looks SOLID or not. And if that means you cannot demo your übercool new feature then so be it. Maintaining the customer's confidence in you and (most importantly) your company is way more important than your own technological accomplishments.
The point is to not put yourself in a situation where you start making excuses.
- "This website? I can have it done in a week". Think again.
When approximating deadlines: Think of the amount of days you think you will need. Double it. Think again. Double it once more and add some days. Shit happens when you least expect it, just try to not have it happen within 1 day of delivery.
- Consider your place on the techno-curve
As Steve McConnell mentions in Code Complete, it is truly important to think about where you want to be in the techno curve. New technologies are born each day and even though they might seem cool they are still babies and babies have a tendency to get sick.
Try narrowing down the techniques that will be used in your project and stick to it unless you have valid reasons not to. For example, instead of using AJAX all over the website think hard about how the project would benefit from it.
There are obviously much more I can write about this topic but the main subject here is that there is no need in stressing yourself throughout a project just to impress your employer or customer.
posted @ Monday, February 26, 2007 9:24 PM