Timeline for How can I favor quick (and dirty) over clean (and slow) in practice?
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 13, 2022 at 17:11 | comment | added | Gulzar | I would like to take something away from this answer, and that is probably better up-front planning. Could you elaborate on that? How do you approach a large code base with for example not enough encapsulation layers, and plan ahead in that? Usually what I tend to do is create those encapsulations as I go, just to understand what's going on and name it. Understanding it and coding it is almost the same work. But how CAN I plan ahead in such cases? Please elaborate | |
| Aug 12, 2022 at 12:05 | comment | added | user1937198 | Or what about when your managers ask why you aren't completing as many tickets as the coders who complete the original ticket with quick and dirty and broken implementation, get that commited and closed, and then spend loads of time in seperate bugfix tickets fixing the issues they caused? | |
| Aug 12, 2022 at 10:46 | comment | added | user1937198 | And how did you handle the issues from trying to interface clean code with a codebase full of design and code issues from the bad coders? Or handled situations where challenging a bad design gets you labelled as a troublemaker and the implementation passed over to a bad coder who isn't going to challenge the architects underlying flaws? | |
| Aug 12, 2022 at 6:56 | history | answered | kiwiron | CC BY-SA 4.0 |