Timeline for How do quick & dirty programmers know they got it right?
Current License: CC BY-SA 3.0
43 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 6, 2017 at 17:49 | review | Close votes | |||
| Sep 12, 2017 at 3:02 | |||||
| Sep 6, 2017 at 17:35 | history | protected | gnat | ||
| Sep 6, 2017 at 17:01 | answer | added | Mendy | timeline score: 0 | |
| Jan 29, 2015 at 10:55 | comment | added | Lightness Races in Orbit | Why do you think it's called "dirty"? | |
| Nov 20, 2014 at 23:26 | comment | added | Giorgio | @James Anderson: I agree and I think it makes a lot of sense to look at finished code and try to understand the thinking behind it before dismissing it as nonsense. In this respect, I think that a big downside of pair programming is that too many good ideas are dismissed as nonsense by one member of the pair before the other has the time to properly write them down into working code. This happens because it would take some time to really understand somebody else's thinking, whereas in pair programming everything happens very quickly. In this way, many good ideas simply go lost. | |
| Dec 20, 2011 at 20:07 | comment | added | Warren P | Quick & Dirty Programmer = Someone more sloppy, or slightly less clever than me, who wrote code that makes me mad. | |
| Dec 19, 2011 at 20:29 | comment | added | stefgosselin | Good programmers can sometimes pass bugs or unexpected conditions as "hidden features". I have done this, when the unexpected turns out to be the logical result after all. If customer does not like the unexpected 'feature', you fix it to his liking and move on. This does not change the amount of work, but really does make it seem (psychologically) like there are less bugs. Oh. And a habit I have is to use a very minimal home made test framework that holds tests to validate the main tasks in the scripts. | |
| Dec 15, 2011 at 21:45 | comment | added | Joshua Davis | "Because it works" - for certain definitions of "works" | |
| Dec 15, 2011 at 11:17 | comment | added | Giorgio | In my own experience, it is very frustrating and time-consuming to chase bugs in quick and dirty code that was checked-in two years earlier by a developer that does not work in the company any more. So, there is no perfect code, but each project should have some coding guidelines and code reviews that do not allow code below a certain standard to be checked in. | |
| Dec 14, 2011 at 20:50 | answer | added | Thiago Gama | timeline score: 0 | |
| Dec 14, 2011 at 15:21 | comment | added | Rachel |
How do quick & dirty programmers know they got it right? Because it works :)
|
|
| Dec 14, 2011 at 15:20 | vote | accept | Karl Bielefeldt | ||
| Dec 14, 2011 at 15:18 | answer | added | Purplegoldfish | timeline score: 5 | |
| Dec 14, 2011 at 14:51 | comment | added | Wolfger | <ego>I know it's right because I wrote it.</ego> | |
| Dec 14, 2011 at 14:40 | answer | added | hotpaw2 | timeline score: 2 | |
| Dec 14, 2011 at 7:26 | answer | added | siamii | timeline score: 8 | |
| Dec 14, 2011 at 6:21 | comment | added | Joonha | There is no answer to this question because its too subjective. Its like philosophy and religion. What is dirty code? What is clean code? What level of testing is considered dirty or clean? etc, etc. this has no answer other than providing a means of social grease for nerds. | |
| Dec 14, 2011 at 1:51 | comment | added | James Anderson | @joe -- +1 -- some programmers are too quick to dismiss code that does not fit into there personal idea of "good code". You should always try to understand the thinking behind a body of code and its code style, often you will learn something useful. | |
| Dec 14, 2011 at 1:46 | comment | added | DJClayworth | The important thing about iterative programming is that each little iteration should work really well. | |
| Dec 13, 2011 at 22:47 | answer | added | S.Robins | timeline score: 3 | |
| S Dec 13, 2011 at 22:14 | answer | added | Caleb | timeline score: 3 | |
| S Dec 13, 2011 at 22:14 | history | made wiki | Post Made Community Wiki by Caleb | ||
| Dec 13, 2011 at 22:13 | answer | added | Kevin Peterson | timeline score: 11 | |
| Dec 13, 2011 at 20:15 | comment | added | tdammers | Not quite an answer, but I think it is important to distinguish between "quick & dirty" ("saving" time by being sloppy) and iterative programming (starting with the smallest possible prototype that barely meets one core requirement, then keep improving it until it's done). There is nothing wrong with iterative programming, but being sloppy is seldom a good thing. | |
| Dec 13, 2011 at 20:01 | answer | added | Suboptimus | timeline score: 7 | |
| Dec 13, 2011 at 19:21 | answer | added | Morten | timeline score: 2 | |
| Dec 13, 2011 at 19:07 | comment | added | Joe | Not all programmers think alike -- I've been given code to maintain that made no sense to me for months, until one day, it was like a light switch was flipped, as I realized what the overall organizing structure was, and it all made sense why they had done it how they did. Would I have done it that way? No, but it worked. | |
| Dec 13, 2011 at 18:59 | answer | added | Trav | timeline score: 4 | |
| Dec 13, 2011 at 18:23 | comment | added | user2528 | All my 'quick&dirty' code throw an exception on unhandled case. This isnt a bug but i dont think i can ship with all of them... | |
| Dec 13, 2011 at 18:06 | answer | added | BillThor | timeline score: 7 | |
| Dec 13, 2011 at 18:05 | answer | added | slim | timeline score: 105 | |
| Dec 13, 2011 at 17:57 | answer | added | Dan Ray | timeline score: 106 | |
| Dec 13, 2011 at 17:24 | history | tweeted | twitter.com/#!/StackProgrammer/status/146641639098679296 | ||
| Dec 13, 2011 at 17:10 | comment | added | Carlos Campderrós | However, some people feel it's occasionally okay to intentionally check in dirty code in the interest of shipping software, with a plan to "clean it up later." heh... hell will froze before it's "later"... | |
| Dec 13, 2011 at 16:55 | answer | added | jfrankcarr | timeline score: 15 | |
| Dec 13, 2011 at 16:05 | comment | added | Job | My theory is that all coders fall somewhere in between "memorizers" and "understanders", and few can do both well. The more crap you can remember at once, the more messy you can afford to make your code. Whether the code is clean or not, make it work, test it! | |
| Dec 13, 2011 at 15:51 | answer | added | Péter Török | timeline score: 82 | |
| Dec 13, 2011 at 15:42 | answer | added | Tom Squires | timeline score: 35 | |
| Dec 13, 2011 at 15:40 | answer | added | Fredrik | timeline score: 6 | |
| Dec 13, 2011 at 15:39 | answer | added | Bernard | timeline score: 5 | |
| Dec 13, 2011 at 15:38 | answer | added | Raku | timeline score: 4 | |
| Dec 13, 2011 at 15:35 | answer | added | asthasr | timeline score: 241 | |
| Dec 13, 2011 at 15:31 | history | asked | Karl Bielefeldt | CC BY-SA 3.0 |