Just imagine the hassle of hiring a new programmer, that will have to work through files and files of poorly written code, without any single line of documentation.
closed as off-topic by gnat, Jan Doggen, Chris E, Garrison Neely, Michael Grubey Dec 18 '14 at 16:09
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – gnat, Jan Doggen, Chris E, Garrison Neely, Michael Grubey
If that's your strategy of keeping your job, you must be a really terrible programmer. Plus, the people getting rid of you are executives that don't even write code. Layoffs/fires are thought of more on terms of profit vs. expense, or performance.
Additionally, documenting your designs and code is part of what separates the "engineers" from the "programmers".
This is an excellent way to find yourself eventually fired.
Death by complacency
I've actually been hired on to a company for the express purpose of replacing the current person working a role. People who artificially "create" job security through keeping how things are done secret and adding unnecessary complexity to their work to make it unmanageable by others stink.
You can quickly spot people of this nature, often what ultimately does them in is their own complacency. They create their complex web that's nearly unmanageably hard to navigate. Maintaining this web takes a notable hit in their performance as well. Eventually you get lazy, thinking you're "unfirable", and you're wrong. Some companies will bring in someone to act as your assistant who'll slowly learn your disaster, others will fire you outright accepting they'll lose months of work, others will force you to train this person.
Death by peer review
More common is as your company grows eventually your job simply is no longer a one-man operation. Things are growing faster then you can move and another developer needs to be hired on.
It'll take a matter of seconds looking at your code to discover it's a total kludge. Perhaps you'll survive the first new hire by saying he has no idea, he's a trouble maker, etc. But the second? Well now we have a trend and it points squarely at you, which means you are on your way out the door.
What could go wrong?
Sure someday this will catch up and you'll get fired you think. No problem, I just milked these saps for months to years before that happened!
If you're lucky yes that will be the whole story, but not necessarily. Many industries are surprisingly well connected, software is among them. The moment you develop a reputation of "creating job security" in this manner you're going to have real problems finding work in your area. Someone's bound to know you worked for company X and person Y also works there. They give that person a call and your chances of getting that job go to zero.
Oh but things can get so much worse. Depending on your location, there are places in the world where you could be held liable for intentionally causing your employer harm in this manner. Cases are admittedly rare, but do exist where a company has come after a former employee for damages in this manner. Would this happen to you... probably not... but it is potentially a possibility.
What happens next?
So let's say this comes to pass. You put in two year before you're finally caught and fired. Great! Two years on the ole' resume!
Problem... you really can't safely put that on your resume. If they call a reference or "someone knows someone" there your chances now hit zero, and you probably got on their do not hire list.
Okay, no problem! You get involved in your local user group to connect with other devs to land a job less likely to let that burned bridge cost you! but wait... the guy who replaced you is there as well... and he's talking about the disaster some jerk off dev left him... oh wait... that's you... yep... now everyone there is on the list of people who will never hire you, and likely they will work for people that when they see your resume show up grab their boss and say "sir, you don't want him."
No problem! We'll just relocate to someplace they don't know you! Sure, that'll probably work fine... it's also REALLY impractical, and yes these things really do follow you around. I know three different devs who relocated as they were effectively unhirable here due to burning bridges (one in a case like the one you've proposed).
Is it acceptable or effective behavior to not document your code to keep your job as a programmer?
If I worked with you, and found out about it, it wouldn't be acceptable. In fact, if you worked for me and I determined you were intentionally withholding documentation, you would be disciplined. The acceptability might be different in your shop.
Effective is something only you can determine, and only in your sitution. I suppose some folks do get away with it, but in the long run I don't think it can be very effective.
Perhaps you should ask your boss her opinion on this matter.
I don't think you have thought this through.
If they decide to terminate you it will be for
- lack of documentation
- a reason other than lack of documentation
It they decide to fire you for lack of documentation then lack of documentation is not going to save you.
If they decide to fire you for a reason other than lack of documentation and you say "you can't fire me as I did not document the software" do you think that will make them decide not to fire you?
Obfuscating your code to hide it from your own employer is NEVER acceptable .
Effective? Well, it's much more likely to get you fired than retained, and potentially to establish a reputation that keeps you from getting hired again. Very effective at committing career suicide, not so effective at anything else.
The only way this could even possibly help someone keep a job is if management knew it was being done (though not why it was being done). Simply put, if they didn't know you were doing this, they would only be made aware of it once your replacement points it out to them.
So, given that they know this, would knowing that an employee is performing badly in such a way that makes their loss more of a liability to the company make management more likely get keep or get rid of (after attempting to correct the behavior) the employee?
For good management, it will make the more likely to get rid of the individual sooner rather than later to minimize damage.
Now, this is different from merely learning part of a complex system that no one else wants to know. If you aren't causing the problem, but an existing problem is making you become more critical to the employer, then it is likely to give you some slight advantage.
In short, what you are doing is offering slightly improved security to the guy who replaces you (well, the first one to stick around), but not for yourself.
I have only ever encountered this type of tactic being effective once. A third party that our company worked with had a single developer writing code to implement an algorithm. They didn't think about sorting out who owns what IP at the time they hired them for complicated reasons that I won't bore you with (they didn't have an explicit "work for hire" agreement). He had all of their source code stored locally, in a foreign language, and encrypted. They couldn't fire him without losing their product. I got to see some of his source code with certain "proprietary" (according to him) parts left out so that I could optimize it to work with our product's architecture, and it was truly terrible. The sad thing was that he was actually working for some really nice guys who would not have fired him over the quality of the code.
So, the moral of the story is that if you feel like you need to use this tactic for job security, you should go big or stay home. Don't work on a team. Keep all the code that actually works under your local control. Make sure you have a very poorly written employment agreement and you know a good attorney that can keep you out of jail for what essentially amounts to blackmail.
Any decent professional developer can fairly easily sort out uncommented or purposefully obfuscated code even if it is tedious and we hate doing it. Most of us have done it many more times than we'd like to. When team members look at your nasty, unprofessional code, you can bet that word is going to get around and that you might have actually placed your head on the chopping block instead of securing your job. You've also guaranteed that no-one who has actually seen your code will recommend you for another position or promotion.