"You better not steal any of my code or I'll be suing you for all you got!"
This event early in my career changed my perspective on how to treat others. My story starts with being hired as a freelancer...
(This is an updated re-post from 2006-Apr-12)
Throughout your career, there are a number of certain events you remember that adjusts your perspective on how to treat others. As they say, "always treat others as you'd like to be treated" a.k.a The Golden Rule.
As a developer, I've always kept an open mind and (tried to) check my ego at the door. If there is a better way of writing code, speak up and let me know.
Because as developers, we all want to build exceptional software our users can appreciate and use on a daily basis. It doesn't hurt that you are compensated for the effort as well.
The problem occurs when someone takes way too much pride in their code and considers it theirs instead of who they're writing it for. They become a little too possessive.
The (Possible) Lawsuit
Back in the 90's, I started out as an independent freelancer/consultant. I had a friend who asked me if I would be interested in taking on a project where I would update a document management system for a government agency.
I agreed to take the assignment.
The contact for the project told me they already had an existing document management system written in Delphi and requires some updating. At the time, Delphi was my specialty.
However, the main contact I reported to made me aware of a sticky situation. They already had a programmer working on the existing system.
Uh-oh. A red alert in my head was going off.
The problem was that the programmer would work on the system trying to fix an issue and break two other features. The contact told me that this was an ongoing issue over the past three months and that he would be "leaving soon" once I evaluated the project.
When I walked into the office one day during lunch, I saw the programmer working on the main PC with no one in the office at all.
The man looked at me.
"So, I hear you're the new programmer."
"Yes sir, I am."
He immediately looked up at me and began to raise his voice. "You better not steal any of my code or I'll be suing you for all you got!"
I guess it never really occurred to him that:
- If he only fixed the problems properly in the first place, this "situation" wouldn't be happening to either one of us.
- It wasn't "his code" at all. It belonged to the government (doesn't everything?) :-)
I looked at him and calmly said, "Sir, you have nothing to worry about..." He started to smile at me.
"...we won't be using any of your code." The smile stopped midway.
I left it at that. He focused his attention back to the PC and I told him I would be back after lunch to talk to my contact. I received a grunt of confirmation.
When I returned, he wasn't anywhere in the office. I was told he left for the day. Actually, it was the first and last time I would see him.
After lunch, I came back and met my contact. I told him what happened. He told me he expected the programmer to do that and not to worry. The code was theirs to begin with, as I suspected.
The project went very well from that point on. As the project came to a successful close, we were kidding around saying if someone comes in and takes "my code," that I would sue them for everything they had.
Conclusion
Based on the code, it was probably a good idea to let the programmer go. After I examined the project, I wrote up a document describing the approach I would take based on their needs and make the application maintainable for the next developer (if there was a next developer).
As a general guideline, if you spend more time fixing bugs in your code than writing features (a possible 3+:1 ratio), you need to step back and take a hard, structural look at the code. Or better yet, conduct an honest evaluation of your skills and try to improve on writing better code.
I know he meant well, but there are times when someone does not, and will not, work well with others.
Also, when I first met him, first impressions are important and he immediately set the tone for a bad working relationship.
This was definitely a moment in my career I would not forget.
Before you solve the equations of the world, make sure you're not part of the problem.
Sidenote: This is why I decided later in my career to focus on design patterns and practices. If you see a particular design pattern, it makes the code easier to understand and maintain.
Have you ever experienced someone like this? Are you currently working with these people? Post your comments below and let's discuss.