04.06.09
Letting go
One of the hardest things in development is learning to let go. It’s something most developers fall victim to – you get some idea for a system that will simply fix ALL of the problems, walk the car, and wash the dog!
And then you find some use case that your system doesn’t quite cover. So you fudge around the use case, or scope it out. And so on and so forth. And you end up with some nasty piece of code that barely works, is horribly mangled to the point of unmaintainability, and that nobody wants to deal with, ever.
The problem here is letting go. As developers, we are in the job of creating solutions for problems. Any piece of code is a solution to a problem. And most developers are pretty smart, and hate admitting that they’re wrong.
But sometimes we are wrong. And when our use cases (the problem) start conflicting with our code (the solution), it should be the code that loses. We should tailor our solutions to the problems we are presented, not the other way around.
When we’re wrong, we have to let go of our wrong solution, and learn to do it quickly and easily and without ego. And that can be very hard.