Since I've been a software developer, I have had ideas about what programming in Hell would be like, although some days at the office made me feel like I was already in the fiery depths. Aside from the obvious heat problems, here is what I would find in the following levels of my own personal programming Hell:

In programmer hell, your cubicle comes equipped with a substandard computer with which you will attempt to perform your coding tasks, a cot for those long programming nights, a chair that looks more like a medieval torture device and shackles. Yes, shackles. You see, there is no quitting time in hell, there is only naptime. When you attempt to use your computer, you'll find that it is the slowest machine possible. You'll still be able to do work, but it will be painfully slow. Your work will take hours to compile, and a few more hours just to test, and that's assuming your machine doesn't crash and burn while attempting to do these tasks. You can beg and plead to get a faster machine, but it will fall on deaf ears, if you're lucky. If you're unlucky, you get to spend a couple of days in solitary with an abacus and a stack of math problems to figure out.

As you work day to day, you'll grow accustomed to the loss of data you experience. The IT staff in hell don't particularly care about your data, they care more about being able to play Unreal Tournament for hours on end without interruption. If you do call them, they will tell you they're looking into it, but they will actually just go in and wipe out your shared storage space. Overall, the experience with your computer will be a painful one due to the lack of color, speed and functionality. You don't get to use your favorite editor, in fact, you fill out a survey prior to entering your workspace in hell. This survey is used to "better your experience", but in reality, they take the answers to your questions and use them to torture you. In this example, your favorite editor might be Emacs. That being the case, your machine will be equipped with Vi. Like using Windows for an OS? You get either Linux or MacOS.

Coworkers in hell are not necessarily a good thing. On occasion, they may surprise you with some helpful hints or suggestions, or perhaps even write some code and do some actual work. Most of the time, however, they will be more of roadblock on your quest to finish an impossible task. One coworker, who will be referred to as Officer Clean, will go out of his way to clean up your code, and in the process, he will break the source control system. He feels that all code should have the same indentation and comment style, and if he finds code that does not fit his mold, it must be fixed, at least in his mind. Officer Clean will spend all day cleaning up code, rather than helping out on the impossible project you've been tasked with. Next is Mr. Selfish, who feels that if he is given a project with a particular database, it is his to do with as he pleases. Nevermind that your impossible project depends on the data in that database, he'll just clear it on a whim and create his own data. If you confront him about a backup of said database, he'll just laugh you off as you're left staring at an empty database. These coworkers all dress in the standard programmer-issued uniform in hell, which is a white shirt, black tie, black pants and glasses. Other coworkers will spend their time asking you questions about what you're doing, or even worse, messing around with your data files, not unlike Mr. Selfish.

Customers exist here in hell. They are still the primary reason you have employment at Hell Incorporated, and if they did not exist, you would not either. Keeping the customer happy, no matter what, is always what needs to be done. Your customer will always want their change to take top priority, and if it does not, your phone will be ringing every five minutes, asking when they can expect their change to be done. Most extreme issues, the issues that prevent the customer from making money, will always come in thirty minutes before they need the change done. It may take four hours, however, they need it in half an hour or else. They will tell you it's a simple change, and you can do it easily in your program. The customer is always right, they say, and management takes this to extremes. If a customer says it can be done in five minutes, it better be done, or else you will face the wrath of your manager. If you need to deviate from the timeframe the customer sets, you'll have to fill out a stack of forms and sign them in your own blood. You see, if a customer in hell is unhappy, they will demand your head on a platter, literally. In hell, customers look more like ogres, only with a bit more intelligence. They demand that their needs be met, otherwise they want your blood on their hands. Needless to say, it's in your best interests to keep them happy, lest you become a grease spot that used to be a programmer.

Managers in hell rule with an iron fist. If you fail to meet a deadline, or you do not do something exactly to their liking, you can expect to be placed in a dungeon and given some obscure task, such as abacus calculations, or counting the number of zeros and ones on a hard drive. If you do get things done, your only reward is more work and avoiding a trip to the dungeon. Managers look exactly like customers, except they all have pointy hair. Yes, the point haired bosses are alive and well down in the fiery depths. They usually spend their day in someone's cubicle, asking for a status update every five minutes. With the long compile times thanks to the archaic hardware, these managers tend to stick around one person for hours on end. You find yourself thankful that he is not at your cubicle today, but be careful what you think. Management in hell can read minds, so you can't even think about what a moron your boss is without the risk of being put in the dungeon, or worse yet, being put on TPS report duty.

As you have read, it's not a very pleasant place to be. Thankfully, Programmer Hell is something I do not have to look forward to, as I'm going to Unix Heaven.


This is a work of fiction, garnered from experiences from friends. This is in no way a reflection of my current employment, which is much more like Programmer Heaven

Programmer hell is far from a fiction. Thousands of unfortunate souls are living in it right now. The technical difficulties inherent in programmer hell are a symptom, not a cause. The real problem is the people. People problems are a lot harder to solve.

In programmer hell, substandard equipment is the least of your worries. In fact, wimpy hardware would almost be welcome, as it would at least allow you a much needed breather every time you have to build your entirely uninspiring spaghetti code. That's right, spaghetti code - because even though you have years of valuable experience and a natural talent for software design, you find yourself committing horrendously bad code to the repository each and every day. Ordinarily, this would be an outrageous affront to your personal integrity and work ethic, but you've long since abandoned any personal investment in the product. You see, the system has been architected by your development manager, whose lack of a technical background doesn't stop him from delving into low level design decisions that are far beyond his capacity for reason. The resulting ball of mud forces you to decide between bad solutions and worse solutions with every line of code that you write.

COTS products are the bread and butter of programmer hell, as the executives keep spending millions of dollars on licensing fees for closed source enterprise software with nonexistent APIs. You are forced to tightly integrate these products into the system ASAP, especially if they are unrelated to any feature under development. Often, you are called upon to perform technical due diligence prior to such a purchase, which usually involves a mandatory 6 hour meeting with 15 sales pukes and yourself, the lone technical expert in the room. After these meetings, no one ever asks your opinion as to the suitability of the product under evaluation, and if you volunteer your honest, measured appraisal of its technical merits and weaknesses, you will find your annual bonus docked for your "negative attitude regarding product X." Your cries for open source, extensible frameworks go unheeded, because surely, if they had any value, they wouldn't be free.

Although customers exist in programmer hell, they are not driving any portion of the requirements for the product. If they were, you could comfort yourself with the knowledge that at least someone will find the product useful. Instead, the requirements process is being driven by members of your marketing department, who are entirely unrepresentative of the common user and, in fact, refuse to talk to anyone who might actually buy or use the product. The result is a bunch of highly complex and totally useless features, each of which is deemed to be the most important to implement right now. If you actually manage to deliver one of these features on time, it will immediately be abandoned as the direction of the product radically shifts once again.

Product managers and business analysts exist in programmer hell, and although they're officially responsible for requirements management, they're really just ineffective project managers who utter nonsensical bullshit such as, "Feature A is the most important for our business model, therefore Feature B is the highest priority for this release." Feature B is, of course, unrelated to anything of value to anyone. The product managers spend the remainder of their time generating Gantt charts that no one ever reads, which is just fine, considering that the project schedule is totally divorced from reality anyway. Deadlines become meaningless, as every deliverable is always due yesterday.

In programmer hell, management spends a lot of time and breath on touting the advantages of an agile development process. Counter-intuitively, this translates to iterations that last 6 months, and the generation of massive amounts of tedious documentation that becomes obsolete immediately. True agile practices like short daily status meetings and test-driven development fly out the window, as everyone is always far too busy to engage in activities that might streamline the workload and result in a higher quality product. Similarly, collective code ownership and fearless refactoring are unheard of - nothing can be accomplished without negotiating a labyrinth of piss-demarcated territories established by your fellow programmers, and no one ever revisits anything they've previously written. The cost of change becomes monumental.

No one in programmer hell dares spend their time at the office playing video games, because the company monitors all of your actions on your machine. The break room has a foosball table that looks good for visitors (hey, we're a hip startup!), but ultimately collects dust as people realize that anyone who uses it gets fired shortly afterwards. It becomes known as the Foosball of Death. Instead of gaming, IT personnel spend all of their time helping the business side of the company administer a Sharepoint server that no one ever uses. Because the IT department is populated entirely by MCSEs, programmers suddenly find themselves responsible for hardware procurement and Linux administration tasks that lie far outside the scope of their job description.

In programmer hell, there are never any management problems; there are only software quality problems. You've spent the last year working 80 hours a week just to keep the product from breaking horribly, and against all odds, you managed to turn in all of your deliverables on time. Then your manager pulls you aside one day to tell you that you need to start "going the extra mile," because your bug fix numbers are "27% less than optimal." As extra incentive, he baldly waves a promotion and a pay raise in front of you. So you start working 15-18 hours a day, 7 days a week. When the time for annual performance evaluations rolls around, you are pained to discover that your promised "raise" consists of 10,000 stock options that aren't worth the paper on which they're printed.

Once a month, the CEO calls an all-hands meeting in which he always presents the same Powerpoint presentation on "the path to profitability," and "crossing the chasm" to mainstream acceptance. No mention is ever made of a plan to actually cross that chasm; just repeated admonishments that the company needs to be on the other side of it. It is unclear whether he is encouraging his employees to build a bridge, or simply jump and hope for the best. You strongly suspect that the executives expect their underlings to take that leap of faith, and when enough people have done so, the CEO and VPs will be able to cross the chasm by simply walking across the top of a pile of decaying, broken corpses.

Then one day, you show up at the office, late as usual (because it now takes a couple hours and at least one stiff drink just to motivate yourself to leave your apartment every morning), only to find that all of the doors are locked and your keycard no longer works. There is a note on the door regretfully informing you that the desperately needed bridge loan failed to materialize, and all employees are being terminated, effective immediately. Any personal effects you may have left in your cubicle will be mailed to you COD in 4-6 weeks.

There is no severance package.


This is a work of fact, garnered from personal experience. It is an amalgamation of my last three jobs.

Y'know, if you log in, you can write something here, or contact authors directly on the site. Create a New User if you don't already have an account.