-5

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.

  • 4
    You know anyone who has been in this business for very long has probably had to do that. What is unacceptable is for you to not document if your comapny has a requirement that you do so. That is gross incomptence and is a firing offense. Not to document in general makes you a jerk and people will curse your name. It will nto keep you from being fired if you are a bad programmer, it will nto keep you from being fired if the CEOs cousin wants your job and if you are only one who understands the system you can't move to another project or move up in the company. – HLGEM Dec 17 '14 at 19:19
  • @JoeStrazzere I meant has had to dig into undocumented code, not leave code in that condition. – HLGEM Dec 17 '14 at 19:28
  • 2
    Yeah but agile is also big on clean code, it should be self documenting. – The Wandering Dev Manager Dec 17 '14 at 20:19
  • 1
    Not to defend it, but non-documentation happens ALL THE TIME. Interestingly, I never heard of anyone getting ever getting "fired" for lack of documentation of a working system. Also, some clarification needs to be made about what constitutes documentation-- there are of course different levels and types of documentation and not all of them need to be present every time. – teego1967 Dec 17 '14 at 20:19
  • 1
    I'd consider firing someone for "poorly written code", even if it's perfectly documented. – Adam V Dec 17 '14 at 20:56
15

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".

  • Managers and HR people make these choices. The vast majority of them have never even seen a line of code that they understood so they have no idea if you comment it or not. Well written code on the other hand is generally understandable with very little commenting except to note the whys of a choice not what it currently does. – HLGEM Dec 17 '14 at 19:15
  • 1
    ^ That's basically what I was saying. The OP is trying to justify writing terrible code that only he can maintain, and that type of thinking is why most programmers dislike maintaining legacy code bases. Which is funny, because this complaint pretty much verifies that OPs strategy doesn't work. – Lawrence Aiello Dec 17 '14 at 19:19
  • 5
    If you love your job so much that you want to keep it, being professional is a better way to go. As well as a jerk move, not documenting your programs is a real career killer. "Got a cool new project to work on here - maybe Quora can step up and take it on" "Sorry, no can do - Quora is the only one who understands this pile of steaming spaghetti, so we can't let them move on to new opportunities." Finally, of course, documenting code isn't just for other programmers - it's for yourself 6 months down the line. – Laconic Droid Dec 17 '14 at 19:56
7

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).

  • Also, death by suicide. Making your code unmaintainable means that it will be difficult even for yourself for maintaining it. You will be slow making changes and implementing new functionality, and regression bugs will appear so many times that some of your users will begin asking for your head. – SJuan76 Dec 17 '14 at 20:32
  • The problems with this strategy are that your performance will be abysmal, your abilities will actually take a bit hit, and eventually your management will take action. In a years time I promise you that you won't be able to maintain your code, but I will. – gnasher729 Dec 17 '14 at 20:50
  • @SJuan76 in my experience the users honestly didn't have a clue so thought terrible cadence was "normal", but yes excellent point. – RualStorge Dec 17 '14 at 21:09
  • @gnasher729 You'd be amazed at just how long terrible kludge code can survive, and how terrible choices now take time to manifest themselves loss in productivity. A lot of applications once a chunck of functionality is done you don't have to mess with it for a while. So if that chunck is a total kludge that at least works you might not suffer from the technical debt for months. In addition working through a little technical debt doesn't hurt your turn around too bad... it's when you start having multiple places with technical debt you have to deal with that things get ugly. – RualStorge Dec 17 '14 at 21:28
3

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.

3

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?

1

Obfuscating your code to hide it from your own employer is NEVER acceptable .

Period.

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.

0

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.

0

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.