(4) Always check to see if someone has solved the problem previously before writing a whole new way to solve it.
That frustrates me the most. On the long run the worst thing to do is to always only reach back to the old code for patterns. But when you have to just do a single task, with no time to think things through and refactor, there's no other way. Trying to refactor in those cases lead to failure (e.g. you don't deliver on time, the time pressure makes you create a bad new design etc). Also you can end up with a codebase that has a half with one pattern, and another half with another competing pattern. Yet I believe a balance between the two approach must be found, otherwise the project is doomed forever.
I'm sorry your deadlines are so tight there's no time to think through or refactor!
I definitely mean try to replicate workflows as much as possible while you're tasked with adding something in. If that workflow can be updated, awesome. What I've seen and wanted to stay away from is creating situations where one change has to be done 3 different ways across similar workflows because each new developer reinvented the wheel.
Oh no! Not trying to downplay your pain either. I wish we only had 2 patterns competing. T.T
Just trying to clarify that tight deadlines are how we got here and I'm not reaching back without thought, but we've got to keep the ship afloat in the least complicated way.
But when you have to just do a single task, with no time to think things through and refactor, there's no other way.
True, especially when the old solution/function is not entirely correct or doesn't fit your situation exactly, fixing or refactoring it is so risky as you don't know what else is dependent on it and how much additional things you have to test outside of your task. Being able to talk to the developer that developed it is better than not having anyone to ask, but either way still takes a lot of time! And that's ultimately why duplication of code happens unfortunately :/.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That frustrates me the most. On the long run the worst thing to do is to always only reach back to the old code for patterns. But when you have to just do a single task, with no time to think things through and refactor, there's no other way. Trying to refactor in those cases lead to failure (e.g. you don't deliver on time, the time pressure makes you create a bad new design etc). Also you can end up with a codebase that has a half with one pattern, and another half with another competing pattern. Yet I believe a balance between the two approach must be found, otherwise the project is doomed forever.
I'm sorry your deadlines are so tight there's no time to think through or refactor!
I definitely mean try to replicate workflows as much as possible while you're tasked with adding something in. If that workflow can be updated, awesome. What I've seen and wanted to stay away from is creating situations where one change has to be done 3 different ways across similar workflows because each new developer reinvented the wheel.
I agree, it just hurts :') That doesn't mean you're not right. :)
Oh no! Not trying to downplay your pain either. I wish we only had 2 patterns competing. T.T
Just trying to clarify that tight deadlines are how we got here and I'm not reaching back without thought, but we've got to keep the ship afloat in the least complicated way.
True, especially when the old solution/function is not entirely correct or doesn't fit your situation exactly, fixing or refactoring it is so risky as you don't know what else is dependent on it and how much additional things you have to test outside of your task. Being able to talk to the developer that developed it is better than not having anyone to ask, but either way still takes a lot of time! And that's ultimately why duplication of code happens unfortunately :/.