If your code gets butchered it is not that great.
That's something I am slowly learning, and by slowly I mean in the scale of decades.
I've seen some of my old code I wrote in the workplace ten years ago, going through the hands of many developers of various skill levels and with different ideas, and then getting back to me. Needless to say, it is pretty ugly.
Analyzing that, I found the real good parts mostly untouched. The parts that I though were great when I wrote them and make me feel ashamed today usually didn't hold up. The most butchered parts tend to be of the overly abstract kind. Interestingly, some of the complicated and clever stuff that most people advise against did well. If it does the job well, people will keep it and put it to good use.
You can code romantically in the workplace. You just have to realize your code will be under attack and it has to be strong enough to defend itself. Weak code is not beautiful anyways, so in the end, all that adversity will help make your code better and more beautiful.
I agree with your points with a couple of caveats. I've written a lot of terrible code. For the good stuff it's usually not the existing lines of code or structure that are butchered rather the additions which do not follow the spirit of the original code. That ranges from trivialities such as code style of another developer or more serious issues of making a mess to fit a completely orthogonal new requirement, not utilizing existing functionality rather just doing similar things in different ways etc. In such cases a small refactor would suffice but that almost never happens due to time constraints.
On the topic of overly complex stuff not being touched, I find that's usually because no one understands it and hence others refrain from touching it lest it break.
I don't understand why you'd put the effort in when you can write it off as a job and pursue your "romances" in your personal life. I'd guess the return in satisfaction is greater unless you're already in love with your job in some way.
Very well worded. One thing I'll add -- some of the best code I've written has been the shortest and most plain, simple and obvious. Perhaps for the reasons you stated -- it makes it more likely to come through untouched over time.
I've seen some of my old code I wrote in the workplace ten years ago, going through the hands of many developers of various skill levels and with different ideas, and then getting back to me. Needless to say, it is pretty ugly.
Analyzing that, I found the real good parts mostly untouched. The parts that I though were great when I wrote them and make me feel ashamed today usually didn't hold up. The most butchered parts tend to be of the overly abstract kind. Interestingly, some of the complicated and clever stuff that most people advise against did well. If it does the job well, people will keep it and put it to good use.
You can code romantically in the workplace. You just have to realize your code will be under attack and it has to be strong enough to defend itself. Weak code is not beautiful anyways, so in the end, all that adversity will help make your code better and more beautiful.