Timeline for How can I favor quick (and dirty) over clean (and slow) in practice?
Current License: CC BY-SA 4.0
70 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 23, 2023 at 20:17 | review | Close votes | |||
| Feb 28, 2023 at 3:09 | |||||
| Dec 14, 2022 at 9:35 | comment | added | Gulzar | @Sinc and the fact that things "change from situation to situation" as you put it, does not mean they can't be formalized. All of software development "changes", though patterns can be found to make it more technical and repeatable. | |
| Dec 14, 2022 at 9:32 | comment | added | Gulzar | @Sinc I think this will not be helpful, as this doesn't tackle the bigger issue of dealing with open-ended, existing code, which my changes may break. But I see the mentality you propose, which is helpful. Thanks | |
| Dec 13, 2022 at 15:36 | review | Close votes | |||
| Dec 18, 2022 at 3:04 | |||||
| Dec 13, 2022 at 15:01 | comment | added | Sinc | @user1937198 That's true, but Gulzar is having a problem in any case with the concept of quick and dirty. A programming challenge would be a good way to practice "enough is enough". My coding solutions for it never have error checking beyond what is critical, don't handle edge cases until I run into them, aren't coded beautifully, and have no unit tests unless I run into something that a unit test might help me find. He needs to find the mentality to quit when things are done, so a challenge might be just the thing. | |
| Dec 13, 2022 at 14:39 | comment | added | user1937198 | @Sinc Advent of code is not nessicarily helpful here as it that is greenfield project. A big part of the problem here is how to deal with brownfield code, and small coding challenges don't give you that. | |
| Dec 13, 2022 at 14:27 | comment | added | Sinc | @Gulzar you're trying to formalize informality. It can't be done. Doing things quickly but somewhat dirty is about knowing when to quit, when enough is enough. That is bound to be empirical, and will change from situation to situation. Suggestion: Try adventofcode.com as a practical means of trying to code quick and dirty. It's a programming challenge site, and the goal of each exercise is simply to find the correct answer. The code is not inspected or shared unless you want to. Try some of the challenges, as quickly as possible. JUST get to the answer, without caring about anything. | |
| Nov 22, 2022 at 10:41 | review | Close votes | |||
| Nov 27, 2022 at 3:06 | |||||
| Nov 22, 2022 at 9:54 | history | edited | Gulzar | CC BY-SA 4.0 | added 51 characters in body |
| Nov 21, 2022 at 16:19 | comment | added | Gulzar | @Sinc Everyone keeps saying these "just" sentences. I fail to do that, because you actually didn't say anything. There is a lot of benefit in formalizing this, as this is actually how things work, and understanding life as it is is more useful than understanding ideals in many occasions. Answers with "don't worry about it" or "just succeed" are useless. Not understanding how what you are doing breaks other places (that did not protect themselves) is just doing bad work. | |
| Nov 21, 2022 at 15:05 | comment | added | Sinc | @Gulzar re your update: There aren't going to be any books or formal guides to doing things quick and dirty. It's not a paradigm that anyone REALLY wants to formalize. It's pragmatism. It's recognizing that if you write a function to merge two lists that you will use to merge 10 element lists, then no one cares that it is horribly inefficient for merging 1000 element lists. Stop fussing. It doesn't matter. It's about NOT encapsulating what others didn't encapsulate. If they got by without that then you can too. Don't understand the whole module, just grasp the function that you need to fix. | |
| Aug 12, 2022 at 9:16 | review | Close votes | |||
| Aug 17, 2022 at 3:09 | |||||
| Aug 12, 2022 at 6:56 | answer | added | kiwiron | timeline score: 0 | |
| Aug 11, 2022 at 8:23 | history | edited | Gulzar | CC BY-SA 4.0 | added 1 character in body |
| Jun 24, 2022 at 19:44 | comment | added | Simon Byholm | There are things that you just can't do quickly with old bad code. Some functionality in the code may just be too hard to understand in a reasonable amount of time. So what I do in that case is to identify what functionality can be added/changed relatively easily and tell the stakeholders that this is what you can get quickly. This other thing will take a lot more time as there is already existing technical debt that needs to be paid back. | |
| Jun 24, 2022 at 0:40 | comment | added | user1937198 | @Phil1970 That only applies when the team culture can avoid quick and dirty. If the team culture prefers quick and dirty, the long term is going to be slow. As an individual you have a choice of clean code (up front slow, and long term slow once the culture gets its hands on it), or quick and dirty (up front fast, but long term slow). So not going for quick and dirty just singles you out as the one who is slow and troublesome upfront, without any longterm payoff. | |
| Jun 23, 2022 at 22:17 | comment | added | Phil1970 | Usually, if you favor quick and dirty code initially, it will slow you down later. For example, copy and paste is fast but at some point, you would need to update all copies when a bug is found. Same thing by using hard-coded constants. It is fast to write initial code but hard to update it later. Same thing by writting somewhat long functions (might be faster until it is hard to reuse because it does too much)... Thus quick and dirty should only be used for very small project (a few days) for example to do a one time operation... | |
| Jun 23, 2022 at 20:27 | comment | added | Bjornicus | If you want to optimize for development speed try optimizing for getting feedback from and about your code. This applies to both clean and dirty code. Then for "quick and dirty" consider for the given situation what things that you would normally do in clean code that you can leave out. I.e. in some situations you really only need the golden path to function correctly and you can omit a lot of the error handling. | |
| Jun 23, 2022 at 9:14 | comment | added | Gulzar | This question started to get sudden traction, please comment if you are coming here from a reference | |
| Jun 23, 2022 at 8:42 | answer | added | phtrivier | timeline score: 1 | |
| Jun 22, 2022 at 16:32 | review | Close votes | |||
| Jun 27, 2022 at 3:04 | |||||
| Jun 22, 2022 at 15:38 | answer | added | Urausgeruhtkin | timeline score: 1 | |
| Jun 7, 2022 at 12:35 | history | edited | Gulzar | CC BY-SA 4.0 | added 15 characters in body |
| Apr 16, 2022 at 15:00 | history | tweeted | twitter.com/StackSoftEng/status/1515344273524375556 | ||
| Apr 12, 2022 at 13:19 | answer | added | Simon B | timeline score: -3 | |
| Apr 11, 2022 at 23:17 | comment | added | candied_orange | Stop asking for perfect feedback. Just get feedback. If you can get your mom to look at your code and explain what she thinks you were trying to do you’re better off then you were spinning out on this alone. Good code can be understood by the cpu and someone other than the one who wrote it. | |
| Apr 11, 2022 at 22:37 | comment | added | user1937198 | If we're talking about pressure for quick and dirty with colleagues accepting it, then is it not possible your in an environment where your colleagues are writing quick and bad code. Are they going to give good reviews? | |
| Apr 11, 2022 at 22:37 | comment | added | user1937198 | @candied_orange Or to extend The_Sympathizer's comment, even once you are doing coding as a job, how can you get continuous access to those who can give good feedback, if your colleagues don't happen to live up to the ideal? Bad feedback is useless at best and harmful at worst. If the majority either don't have enough experience, are too junior, or haven't kept up with how technological changes have changed design tradeoffs. | |
| Apr 11, 2022 at 22:09 | comment | added | The_Sympathizer | @candied_orange : so basically the real problem is when you don't have access to people who can give you feedback. How was OP then able to avoid these problems and not get stuck on "gold plating"? How do you get continuous access to those who can give feedback, when you aren't doing coding as a job? | |
| Apr 11, 2022 at 22:02 | comment | added | candied_orange | @The_Sympathizer You learn if code is good code in a code review. You learn if features are good features in a demo. Your concerns are not new. They have names. Gold plating. Gold fishing. The cure? Minimize time spent without feedback. Otherwise it’s all to easy to disappear into a problem, solve it, and find that no one cares about it anymore. | |
| Apr 11, 2022 at 21:44 | comment | added | Justin Ohms | I reject the premise of your question. It implies that only two options exist; quick and dirty or clean and slow. I see no reason why you can't write code quickly and cleanly or slow and dirty. | |
| Apr 11, 2022 at 20:49 | comment | added | Panzercrisis | There are currently two close votes on this question, but I feel it should remain open. It's a reasonable question, it pertains to something that is not discussed or explained as much as it probably could/should be, and on-topic questions for this site warrant at least slightly more open, subjective answers than ones on Stack Overflow. | |
| Apr 11, 2022 at 20:10 | comment | added | The_Sympathizer | with projects almost always never being completed because of the obsessiveness and trying to get how the rules can fit when they are presented in such an absolutist manner? | |
| Apr 11, 2022 at 20:09 | comment | added | The_Sympathizer | @candied_orange : What makes "good code", then? How do you know if you code is at the quality level the OP seems to be able to achieve near-effortlessly, instead of racking yourself for hours, weeks, or months into analysis-paralysis quibbling about rules and theories on how to make it, continually re-kneading the code because you always can seem to come up with contradictions in the rules in seemingly basic scenarios? How do you get a solid, trustworthy answer on what "good code" is so you can know if you're making it? How did OP manage to learn this instead of being years in rethink hell? | |
| Apr 11, 2022 at 15:19 | comment | added | Jeremy Friesner | One good way to write good code quickly is to not have to write new code -- i.e. to have good-quality pre-existing code available that you can impress into service to handle the new requirements, with little or no modification. This is fast because the existing code has (hopefully) already been largely tested and debugged, so you don't have to go through those steps with it. Whenever I write new code I try to keep half an eye on making it re-usable, so that over time I build up a library of ready-to-go drop-in components for future re-use. | |
| Apr 11, 2022 at 10:33 | comment | added | BЈовић | I am wondering how nobody wrote this "quality, speed, costs - you can pick only 2". | |
| Apr 11, 2022 at 9:18 | answer | added | AnoE | timeline score: 4 | |
| Apr 11, 2022 at 8:37 | answer | added | cjs | timeline score: -1 | |
| Apr 11, 2022 at 7:47 | comment | added | Martin | There is an article from Martin Fowler that discusses this Quality vs Speed tradeoff: Is High Quality Software Worth the Cost? | |
| Apr 11, 2022 at 6:13 | comment | added | user3840170 | @Gulzar It’s like The Game. If you’re thinking about it, you’re not doing it. | |
| Apr 10, 2022 at 22:22 | answer | added | Jason Weber | timeline score: 2 | |
| Apr 10, 2022 at 22:11 | comment | added | Gulzar | @thorbjørn practicing blindly is useless. I want direction in practicing | |
| Apr 10, 2022 at 22:04 | comment | added | Thorbjørn Ravn Andersen | @gulzar in that case, the best way to write code quickly is to practice. Having written lots of code allows you to recognize what is needed for being able to test, abstract etc, and what is the actual meat of the code which you by then also know where to put to avoid having to put all the scaffolding in place. So, this comes with experience. | |
| Apr 10, 2022 at 19:35 | comment | added | candied_orange | The code in the Gang of Fours design patterns book is not “good code”, never claimed to be good code, and it’s authors have spent a good deal of time explaining that. It’s simply code that works. That’s only needed in languages that don’t provide simpler ways of doing the same thing. Mindlessly following patterns does not create good code. It only creates recognizable code. Having a name for it doesn’t make it good. | |
| Apr 10, 2022 at 18:58 | answer | added | J.G. | timeline score: 3 | |
| Apr 10, 2022 at 14:31 | comment | added | Matt Timmermans | It just means coding without thinking about design -- consider each of the things your code has to do, and make each of those happen in the quickest way you can. How well that works out depends on your familiarity with the problem space and how you've developed your instincts. You never get anything really nice, though. | |
| Apr 10, 2022 at 14:27 | comment | added | Gulzar | @ThorbjørnRavnAndersen "bad" is a convenience word for getting on with this wall of text. I am looking for how to deal with such code. Judging it is irrelevant. | |
| S Apr 10, 2022 at 14:14 | history | suggested | Peter Mortensen | CC BY-SA 4.0 | Copy edited. Used more standard formatting. Fixed the question formation - missing auxiliary (or helping) verb - see e.g. <https:/www.youtube.com/watch?v=t4yWEt0OSpg&t=1m49s> (see also <https://www.youtube.com/watch?v=kS5NfSzXfrI> (QUASM)) - alternatively, drop the question mark (only the title). |
| Apr 10, 2022 at 10:28 | comment | added | Thorbjørn Ravn Andersen | Your assumption that code not conforming to the latest commandments coming from the ivory towers is invariably bad, does simply not hold. | |
| Apr 10, 2022 at 9:19 | comment | added | Helena | In the headline you are asking how to write quick and dirty code, but later you ask how to be "Writing working, tested, explainable code [Sleeping well not worrying production servers just broke because of me]"? So which one is it? Maybe the issue of your sleep needs to be addressed before everything else | |
| Apr 10, 2022 at 9:10 | history | protected | gnat | ||
| Apr 9, 2022 at 23:01 | comment | added | Peter Mortensen | Re "optimize for speed of development". Only in the short term, presumably? Like in to the next deadline. | |
| Apr 9, 2022 at 22:59 | review | Suggested edits | |||
| S Apr 10, 2022 at 14:14 | |||||
| Apr 9, 2022 at 22:00 | comment | added | Zakk | @Gulzar "working": it doesn't (properly) work. "tested": it isn't tested enough, if not tested at all. "explainable": no one is able to understand what it does without the presence of its writer. Even the writer himself may not understand his own code after a while. | |
| S Apr 9, 2022 at 16:23 | history | suggested | CommunityBot | CC BY-SA 4.0 | One pass of copy editing |
| Apr 9, 2022 at 14:35 | review | Suggested edits | |||
| S Apr 9, 2022 at 16:23 | |||||
| Apr 9, 2022 at 11:14 | history | edited | Gulzar | CC BY-SA 4.0 | deleted 1 character in body |
| Apr 9, 2022 at 11:06 | comment | added | Gulzar | @Kevin can you explain please? | |
| Apr 9, 2022 at 9:02 | answer | added | Heinzi | timeline score: 31 | |
| Apr 9, 2022 at 4:28 | comment | added | Bergi | "Writing working, tested, explainable code" - quick'n'dirty code is neither of these. It's dirty. | |
| Apr 9, 2022 at 3:14 | answer | added | Sinc | timeline score: 7 | |
| Apr 8, 2022 at 21:48 | history | became hot network question | |||
| Apr 8, 2022 at 17:22 | answer | added | Karl Bielefeldt | timeline score: 4 | |
| Apr 8, 2022 at 16:29 | answer | added | user949300 | timeline score: 81 | |
| Apr 8, 2022 at 14:52 | answer | added | Greg Burghardt | timeline score: 11 | |
| Apr 8, 2022 at 14:15 | comment | added | Vincent Savard | You speak of "existing bad code", but bad code comes in different flavours, which seems to be the source of your confusion. There's a world of differences, for instance, between code that is not tested automatically, and well-tested code that would be refactored to an architecture that better fits the current needs given the team had time to do so. | |
| Apr 8, 2022 at 14:14 | answer | added | Doc Brown | timeline score: 50 | |
| Apr 8, 2022 at 14:07 | answer | added | Philip Kendall | timeline score: 2 | |
| Apr 8, 2022 at 14:02 | review | Close votes | |||
| Apr 16, 2022 at 3:04 | |||||
| Apr 8, 2022 at 13:40 | history | asked | Gulzar | CC BY-SA 4.0 |