As an employee of a company, when you write code do you feel like you have an attachment to it? Do you feel that you have some ownership of the code? Or do you write it completely detached from it without any concern about what happens to it after you've moved onto something else?
EDIT: I'm not talking about writing bad code and then running...
After 30 years as a contractor, it's mixed.
It's all disposable. I've worked with hundreds of clients. I'll never see the code again. Why become attached? There's no sense of ownership.
It's very visible. It's more expensive than in-house code, so it gets a lot of scrutiny. Since I won't be around to maintain it, it gets a very great deal of scrutiny. Code walkthroughs and handovers are very important. There is some pride in craftsmanship. But no sense of ownership.
My record is 17 years of production. 12 of those years with zero maintenance of any kind.
I know because I got a call. They were revising their accounting systems and wanted to know how to replace the clever cost allocation algorithm I had built so many years ago. I looked at the code, and the files were unchanged since the last enhancement 12 years ago. (Not a bug-fix, AFAIK.)
The next longest run --that I know about-- was 7 years of flawless operation. That, however, had a serious Y2K issue and required some rework to use file names that had 4-digit years. The internal algorithms were all correct, but the log files would have appeared in the wrong order.
Again, I know it was flawless because the files hadn't been touched since the last release I had made.
So, yes, there is a great deal of pride in craftsmanship.
But no "ownership". It's their code, not mine. I only build it.
As a more or less solo developer, the fear of having to maintain what I write is the primary driver behind me trying to not write horrible code.
At work, some of the code is mine, in a similar sense to how the chair I'm sitting in is mine. I wrote it, I made it as good as I could, I feel possessive of it, people will ask me about changes, and people will refer to it as mine. And, like my chair, once I leave the company I'll never see it again, and I'll have no emotional attachment any more.
The word "mine" has a whole lot of variations on its meaning. "My wife" and "my toothbrush" are not strictly parallel.
If you write code for yourself, you can afford to have feelings toward it. If you write code for a business, you must viciously purge those feelings whenever possible. I can't count the number of times I've seen a good programmers cause themselves grief by getting emotional over code.
Say to yourself: "I made it, it's good, but it's not mine and I can make more." If you believe it, then when 6 months of your life becomes obsolete because a sales rep for an inferior product gave your boss a BJ over lunch, you don't lose your job for going crazy on him.
Remember they're paying you. We'd all like to be doing cool things, but if they're paying us to dig holes, then fill them in again, that's their privilege. I just had a situation where I wrote a web app, then spent months incorporating terrible features, then months more coding it back to the original state. The very last two weeks worth of "work" I pulled from my SVN repo, then recommitted it with the new version numbers. And I'm okay with that.
No, but I really hate having to fix bugs introduced by others in code I wrote originally. I would be happier if the change had been assigned to me in the first place. I hate it even more when the fix is completely outside the original design, e.g. by creating a circular dependency with a higher level module.
I love the codes I write. I understand them and tailor them so others will too. When people come upto me and say "Dude,we're still using that script you wrote for us. It's so stable and portable", I love that feeling of pride and ownership.
There's no harm in getting attached to your code if you can see where it's going to end up i.e If it's all in-house and you know who or what you're programming for, then I'd actually say it's a good thing to get attached . Coz you'll only love creating more pieces of brilliance,that much more.
On the other hand (fully aware that I might be reiterating what @S.Lott said) if the code Is going to end up as a client's property, then there's no meaning in getting sentimental over it. It's like...taking care of your friend's puppy when he's gone on vacation. :-/
Contractors and consultants who might never see their code again are probably not the ideal candidate to get emotionally attached to their code. Having to "abandon" it over and over would probably cripple the poor consultants creative drive after a while.
If we look at it from the perspective of an employee and not a contractor I would say that I would like all of my team members to feel ownership in the code they write and in everything the create. This ownership and pride should extend to the entire team. Feeling pride and ownership creates an attachment to the product in questions and adds meaning and sense into the work of a team member. I have seen this boost the performance greatly in small to large teams.
What should be avoided and what I dislike is people who seem emotionally attached to the specific lines of code they have written and defends it to the grave. They don't want changes made, they look down and turn down any idea for change or improvement and try to justify it with something that sounds credible. What this often boils down to, from my own experience, is the fear of change and fear of the unknown. It's not actually giving up their old lines of code that's the issue. Instead it's having to take on something new, sometimes not written by yourself, and the fear of failing at it.
This kind of "sick" attachment to code is something I work hard to try to prevent. But "healthy" emotional connections to the product, and by extension the written code, is something I encourage.
This is an interesting question and I agree with one of the postings above: Yes and No - but for different reasons.
Do I grow attached to the code? Definitely yes. But I don't think it's the code itself but the overall architecture and application. Usually you have to do a lot of domain specific research before you can really put into code what the business people want (unless you're writing an IDE - then you're definitely stuck in recursion).
On the other hand: There are not many things I like more than throwing away obsolete parts of the codebase. No matter how difficult the writing may have been. The journey matters a lot more than the product (at least for the ego, of course the product itself has to work as well).
Is there a sense of ownership? Well it depends on the project situation. When you'll never see the code again (because your part in the project is over and you're moving on) then why get romantic about the stuff? However if you keep supporting it (in whatever way) then a feel of attachment is a good thing! When you care about the product you're building then chances are quite high you're trying hart to deliver high quality artifacts.
So all in all I try to adopt a pragmatic "relationship" with the code I write.
Yes and No.
Yes - It is something you created and therefore you have an attachment, just like a car designer is proud or embarrassed when they see cars they designed on the road.
No - As far as ownership goes, typically you give that up in exchange for being paid to work at a company. Factory-line employees who build cars get no ownership in each one that rolls off the line because they are paid for their time.
I feel very proprietary about the code I write; it represents decisions I made about how to solve a given problem and hence is a reflection of my ability to think through a problem rationally and devise a logical and hopefully elegant solution. That said, everything I write on company time belongs to the company. I hope none of it comes back to bite me, and I'd prefer to be asked to fix my own code, but if not, then not. (And I might add that the guy who was writing code three months ago and putting my name on it in source control is an idiot).
Not at all. Once I check it in, it's no longer "mine". I'll be the go-to guy for maintenance and troubleshooting, naturally, but I feel no sense of ownership towards it.
I've known some people who felt very proprietary towards their code, to the point where they'd get irritated if someone else fixed a bug or somehow modified it without running it by them first. I've never felt that way. All I ask is that if you find a problem in my code and fix it, tell me what the problem was and how it was fixed so I don't make that same mistake in the future.
