Timeline for Best way to deal with developers whose work is always unsatisfactory
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 27, 2014 at 17:20 | comment | added | Marv Mills | Totally agree... The amount of times I have had to stop people going straight to process automation and made them analyse and document the full as-is process first, then and only then think about how you might systemize/automate that process... They never learn :) Henceforth I will adopt the correct name for this- CodeGnome's Law :) | |
| Feb 25, 2014 at 12:17 | comment | added | MCW | CodeGnome's law roughly states that it is a cardinal error to automate that which you do not understand. Seems like an obvious, even trivial statement, but it keeps cropping up in PM:SE. | |
| Feb 25, 2014 at 12:13 | comment | added | Marv Mills | CodeGnome's Law... This I have to see... Is there a link? :) | |
| Feb 24, 2014 at 14:42 | comment | added | saakian | thanks! yes performance is the main concern of all of my projects. But that is just one of the problem I cited. I just noticed that we encounter the same kind of problems across many projects. e.g. there are some devs whose code causes problems. As I said, it becomes like a trend, so that I have to fix it. | |
| Feb 24, 2014 at 14:01 | history | answered | MCW | CC BY-SA 3.0 |