Timeline for How to become a "faster" programmer?
Current License: CC BY-SA 2.5
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 27, 2010 at 18:32 | history | migrated | from stackoverflow.com (revisions) | ||
| Nov 21, 2009 at 9:53 | comment | added | user1249 | Use Test Driven Development to document exactly what your code CAN do. | |
| Oct 5, 2009 at 13:12 | comment | added | markh44 | This is a real tricky one. For, me it's a 0 - +1 for avoiding perfection but -1 for "just make it work". Just making code work generally results in a mess - which will come back to haunt a project. | |
| Oct 5, 2009 at 13:02 | comment | added | hasen | -1 I'd say that this is exactly what causes maintenance nightmares and horrible delays down the road. | |
| Sep 16, 2009 at 14:50 | comment | added | Dimitri C. | +1 Very good remark! Writing "good enough software" is something I have learned over the years. | |
| Sep 11, 2009 at 21:07 | comment | added | mrueg | If you're stuck at one feature, work on something different. | |
| Sep 11, 2009 at 17:14 | comment | added | David Thornley | Often, increasing quality implies increasing speed. If you take a little time to get it right in the first place, you might save more time in testing and debugging. | |
| Sep 11, 2009 at 15:06 | comment | added | Mayo | I've seen it happen repeatedly. Developers get hung up on the last 1% of a given feature and then play catch-up and fall behind when attempting to complete the remaining features. Complete what is expected of you first, then go back and polish it. | |
| Sep 11, 2009 at 15:06 | comment | added | S.Lott | -1: There is no reason to sacrifice quality. You can always sacrifice features. | |
| Sep 11, 2009 at 15:04 | comment | added | Preets | I would suggest "making it work" and if time permits getting around to perfecting it ! | |
| Sep 11, 2009 at 14:58 | history | answered | user8685 | CC BY-SA 2.5 |