I've found being too attached to code is a recipe for frustration in the workplace. You code something elegant, simple, dare I say beautiful and inevitably it will be butchered by new product requirements, business needs, that quick hack to satisfy a client or more generally uncaring colleagues who are looking to get their job done as quickly as possible.
Perhaps romantic aspects could only be achieved when there are no third parties, just the programmer and their code. Working in or more importantly leading a team mandates a different approach by putting aside aesthetic considerations for more pragmatic ones that will satisfy all parties involved.
It's hard to be romantic in corporate environments.
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.
> It's hard to be romantic in corporate environments.
I agree it's hard, but it's not impossible. One thing that heightens the experience for me is to:
Listen to movie scores while you program.
I first started this to help drown out other noises so I could concentrate. But, I soon realized that there's a lot of drama in the sound: there are highs and lows, chaos and order, fumbles and precision, brief pauses, slow times and fast -- the sound is just like programming!
One time, as the score was building my task was nearing completion. Just as I ran the program and saw that everything worked the movie score delivered a massive crescendo. It was so cathartic and I had never felt so much emotion while programming. I actually cried with joy. That's the closest thing I've felt to actual love while programming.
Amusingly, I pick those because they provide a bit of variety but not so much as to be distracting while working. Usually music with words in it gets me focused on what they are actually saying and thus unable to do work.
Yes! That's precisely how I got on to them too... I can't listen to music with vocals while programming. I like various sub genres of electronic music, but even a lot of pure electronic music is a little too jarring sometimes (some is not of course). But, without spending too much time curating, movie scores are almost always a safe choice.
I understand that. But it's interesting how this experience can be spiritual to some and others may be "purists" who find explicitly avoid extra toppings (listening to music during the task) just to be closer to the task (and thus intaking it in full, they could argue)
I guess it depends on what you consider pure. Without the music, I'm listening to kids (or coworkers) screaming or watching paw patrol in the background. Is that more pure than listening to a professionally arranged and conducted orchestra? Even with noise cancelling headphones, it's still not perfectly quiet, thus the movie score is a delightful way to drown out the additional background noise.
This reminded me of something that happened last week. I had written some code I found absolutely beautiful, then had to delete an hour later since the customer's requirements had changed. Personally, I find these situations disheartening but it's never frustrated me.
Every line of code that you write and can be proud of stays with you and adds up to your experience. You will produce more of it as you gain more experience.
> I've found being too attached to code is a recipe for frustration in the workplace.
Not sure why, but I've always viewed code as a means to an end of solving a larger problem. I end up attached to the end result, and not the code itself.
I suspect this is one of the reasons I don't get very passionate about language features. Something that makes my life easier is nice, but I'm not one to argue about them. I've solved problems in Visual Basic to C with everything in between.
haha yea, I try to sync my clothes to a RGB value that represents that day's mood. Sometimes I just type `cmatrix` and just sit back for a minute thinking about the problem I'm solving (should I use another class or inherit?)
Perhaps romantic aspects could only be achieved when there are no third parties, just the programmer and their code. Working in or more importantly leading a team mandates a different approach by putting aside aesthetic considerations for more pragmatic ones that will satisfy all parties involved.
It's hard to be romantic in corporate environments.