It's Your Bug. But It's Not Your Job Anymore.
If a previous employer called to ask you about a bug in the code you'd written for them, how much time and energy would you be comfortable investing in helping out?
Let's say you left your previous employer a few months ago, on reasonably good terms. You might hold a minor grudge against the company because you didn't get the raise you deserved or because they wouldn't give you the QA resources you'd asked for, but it was generally an amicable parting. Certainly, you still care about your old teammates; you'd be happy to share a beer with them. Especially if they're buying.
A few months later, one of those teammates calls you with a problem. They're trying to debug a problem in a code module you used to own, and which you knew really well. Can you help?
Well, can you? Will you? Should you? Just how far will you go out of your way for the old team... and the old boss?
I think most developers would give an old employer 15 minutes of phone time without a second thought. Maybe 30 minutes, if it's still in a casual format such as instant messaging and if the conversation is kept general ("Did you look at the gargleblaster?" rather than "Let me pull up that JavaScript code...").
And certainly—at the other boundry condition—few developers would spend a whole weekend fixing the old application for free.
But somewhere in there, you draw a line. Two hours? Four? I don't know where it is for most programmers, or where it ought to be... and I wonder what the "right answer" is.
I expect that company lawyers would freak out if they thought existing employees were asking for your help. After all, your previous code was written as a "work for hire" so the company owns the copyright. If you change a semicolon in their code now, though, that wouldn't be so. (The fact that lawyers would object, of course, makes this effort even more attractive.)
Professional pride is a factor. If the bug is visible in some way (such as on a public website you developed), I think a lot of programmers would itch to fix it. For portfolio reasons, if not a sense of perfectionism.
Also, there's such a thing as good karma. Refusing to help a previous teammate (never mind the company affliation) might be seen as burning bridges socially, if not professionally. Which makes it all the more important to figure out where the line ought to be crossed; at what point do you cease to be a kind person, and become a gullible chump who's covering up for your successor's inadequacies?
Plus, some segments of the development community are connected more by shared technology than they are by the name on their paychecks. Many years ago, I knew several developers who worked on the software to run hotel reservations systems. A developer at Quality Inns had no qualms about calling an ex-colleague at Ramada Inns or Best Western for help (which incidentally, is the same software that United is finally replacing). In modern terms, developers who work on open source applications (particularly when their employers paid their salary while they wrote the open source code) will be bound by the project's goals, even if their attention has moved on to, say, another part of the project.
So: just how much effort would you put into helping a previous employer? Where do you draw your line? For fun, post your reply before you
Previous Post: The Standard Argument: Incorporating Internet Standards into the Design...Next Post: How Social Media's Changing Public Relations
Most Discussed Posts
Cloud computing has emerged as one of the most significant game changers to hit the technology landscape in the past 20 years. With this massive expansion of the cloud, the perception of the IT organization is shifting from a utility player to a change agent. This eBook breaks down five ways progressive organizations are using cloud-based IT Management solutions to help drive innovation and become more strategic, including: adding visibility and analytics, speeding up time-to-value, lowering costs, improving prioritization, and providing a blueprint for future cloud deployments.
Read the white paper to see how IBM helped Citigroup deliver new services and enhancements to their 200 million customers faster.
There are 3 ways to modernize legacy applications: rewrite completely, acquire packaged solutions or migrate existing code. This paper explains why it's best to migrate and how IBM® Rational® software can help.
Accommodating specific lines of business can result in a hybrid ecosystem of applications and servers. The resulting complexity of this architecture makes for an environment that is costly to maintain and difficult to change when addressing new challenges.
This whitepaper will help you to define a mobile device passcode policy. Security managers must attempt to reconcile two opposing goals. They must: 1) create a passcode policy that is strong enough to protect the device if it is lost or stolen, while: 2) not annoying users with needless length or complexity.
This whitepaper, authored by The Radicati Group, looks at the key reasons organizations should consider moving to a cloud-based archiving solution. Email archiving solutions enable organizations to store, monitor, and collect electronic data exchanged by their users to comply with internal policies and regulations.
ATERNITY will showcase a 30-minute demo on how Fortune 500 companies are leveraging its award-winning FPI Platform to deliver a user-centric approach to Proactive IT Management.
For businesses to move forward and tap into the ever-expanding universe of Internet users and network-enabled devices, it's critical to learn how to make the transition to IPv6. Learn the critical steps your organization must take to make a seamless transition-and keep your business world connected.
Learn how IT teams can protect against spear phishing tactics. Harry Sverdlove, chief technology officer of Bit9 offers a frank discussion about spear phishing - the most common technique used in today's advanced attacks.
Learn how to build a solid business case for your migration to Red Hat Enterprise Linux so you can run leaner, innovate faster, be more flexible and own the New Now.
Social media isn't about you; it's about everything around you. As you consider how your customers want to communicate with you, social media is something that can't be ignored. But what should your strategy be? Is social media "just another channel?" What kind of a plan makes sense for your contact center and for your customers? Join our experts as they share their insight and research results.
Hardware tokens were a popular method of strong authentication in past years but the cumbersome provisioning and distribution tasks, high support requirements and replacement costs have limited their growth. The additional log-in steps that hardware tokens require and the resulting user frustrations have limited adoption and make them impractical for larger scale partner and customer applications.
Sponsored Links
