I was all set to upvote this after the first point, and then I read the next two. Really, it's a job. There're things more important than a steady paycheck, and IMHO keeping your integrity and doing work you can feel proud of are among them.
#12: This seems a bit vicious, but that's probably because you're spoiled by startups and tech companies, where there's a lot of work to be done, and a high proportion of it's actually interesting. At some of the big-box companies, neither of these is true. Some of the BDCs have beginning programmers doing office work during the first year to "pay dues". The saving grace is that 25% utilization is the norm for BDCs, leaving the underutilized hackers time for side projects. Unethical? It's not more unethical for the hacker to work on side projects than it is for the guys in marketing to spend 6 hours per day on Break.com.
#13: I discussed this in my reply to the other poster. As I said, it would only make sense in an extremely negative career situation. I was utterly wrong to imply that obfuscation would make sense in poor economic times without other extreme circumstances.
#12 - my issue isn't with the side projects done on company time. It's in doing the side projects on company time and then trying to unambiguously own them. Didn't you sign something to the effect of saying you wouldn't do this?
Back when Diffle was a part-time project for me, I did bugfixes and stuff while I was at work. After all, I was often blocked waiting for another team member, and coding on some other project is a better way to keep skills sharp than surfing Reddit. But I threw away the code and started fresh when I left my day job and turned it into a full-time startup. Granted, part of this was for technical reasons (I found the code I'd done on nights & weekends basically sucked), but part was because the best way to unambiguously own the software was to not have written it on somebody else's dime.
#13: For me, the appeal of programming is in having my code get used. Making it incomprehensible seems a good way of ensuring it won't be used in the future. In both of my last two employers, I put a premium on readability and documentation, even staying about a month longer than I'd hoped to at my last employer so that everything was documented, all known bugs were worked out, and all unit tests passed.
my issue isn't with the side projects done on company time. It's in doing the side projects on company time and then trying to unambiguously own them.
I don't think that there's much of a difference. The company doesn't know that the side projects exist, so there's no foul. That said, destroying code built for work purposes (e.g. sabotage) would be extremely unethical, highly illegal, and very very stupid, not to mention petty and pathetic.
Ownership can be a knotty issue. I have a friend who wrote a short story while in a dead-end corporate job, and published it around the time that he was laid off. The company found a draft on his work computer and, although they had no real use for the story and it wasn't relevant to his work (he was in accounting) they claimed ownership and managed to take royalties for the story (which were small; this was a symbolic pwnage). To twist the knife even further, they put a clause in the settlement wherein he'd have to get permission from them in order to publish it. He might have won if he went to court instead of settling, but a struggling, laid-off writer doesn't have the resources to fight a large company in the courts.
But I threw away the code and started fresh when I left my day job and turned it into a full-time startup. Granted, part of this was for technical reasons (I found the code I'd done on nights & weekends basically sucked)
You make a great point. In that sort of situation, a second write of the code is an excellent idea in any case. Besides, an intelligently chosen side project is one whose value is primarily education/skill development, since that can never be taken away or owned by anyone else.
For me, the appeal of programming is in having my code get used. Making it incomprehensible seems a good way of ensuring it won't be used in the future.
I fully agree. It's always a lot more satisfying to write great code, and I've always tried to do the best job possible. I'm just arguing that there are very rare, dire situations in which perverse incentives arise, and it might actually be wise to be "perverse".
