4 ms·
When you're really good, you learn to FIX IT NOW while also not making a hack. Your code becomes flexible enough to handle that kind of change.
by ktRolster 11y ago
When you're really good, you learn to FIX IT NOW while also not making a hack. Your code becomes flexible enough to handle that kind of change.
- st3v3r 11y agoThat's assuming it's your code. Most of the time it's not your code. While one would hope that the rest of the team writes flexible code as well, that's not always the case.
- ktRolster 11y agoThen settle for making the code better than it was when you started working on it.
- szatkus 11y agoUsually it's not my code :/
- chimprich 11y agoYou can't anticipate every emergency change required to the codebase. Sure, you can make some intelligent predictions about certain points in the code and encapsulate possible changes but it's impossible in the general case. Trying to code to future possible requirements is often far more harmful because of over-abstraction than occasionally having to perform a quick hack and then fix it later.
- ktRolster 11y agoYeah. It's a balance between "build as little 'framework code' as possible;" and "build the framework as you go." I say 'framework code' but it could be called structural code, or glue code or something, too.
- mathattack 11y agoI'm not that good to pull that off with other people's code. :-)
- ktRolster 11y agoNah, you're good enough. If the code is bad, change your goal to "make it better than it was when I got here." That's something you can do.