Nice writeup, giving "permission to write something shitty" is really sound advice i think. :)
Code-wise writing something that work like shit is a good way to get a prototype you can refactor and fix into the ideal, rather than obsessing about details that might not end up mattering for the end product.
The trick is to make sure to that everyone involved knows that time for refactoring and fixing will be needed after.
I totally agree. I have an article in my queue about creating a culture of refactoring so people “are always refactoring.”
But yea, good point about putting bad code in that doesn’t get refactored. I guess if you know your team isn’t into refactoring, you can refactor it yourself before you ever commit it to Github?
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.
Nice writeup, giving "permission to write something shitty" is really sound advice i think. :)
Code-wise writing something that work like shit is a good way to get a prototype you can refactor and fix into the ideal, rather than obsessing about details that might not end up mattering for the end product.
The trick is to make sure to that everyone involved knows that time for refactoring and fixing will be needed after.
Otherwise it can be problematic..
I totally agree. I have an article in my queue about creating a culture of refactoring so people “are always refactoring.”
But yea, good point about putting bad code in that doesn’t get refactored. I guess if you know your team isn’t into refactoring, you can refactor it yourself before you ever commit it to Github?