Datatypes are difficult. So is typecasting. And if you don't understand one, you probably don't get the other either. And if you don't get either, you should probably give up on writing code and find a new career. You may get a slight pay cut for doing so, but at least you can quit spending half your salary on all those expensive reconstruction surgeries every time your coworkers go on a cluebat rampage against your face. And your coworkers will certainly appreciate not having to lose brain cells to your poorly-written functions, like these submitted by Kevin.

private int GetClassRoomArea(Int32 StudentCount) {
  return ((int)(Convert.ToInt32(StudentCount)) * 2 / 1000); 
} 

There are a lot of different schools of thought on administering programming tests to new hires. On one hand, you’re hiring them to program, so it might be nice to see if they can actually do it. On the other hand, given the time constraints of most interviews , it’s nearly impossible to give them a meaningful test.

We've all seen folks who have trouble dealing with for-switch statements, exception handling, dates/times and so forth. As such, it should come as no surprise that people have at least as much trouble dealing with images.

In practice, there are only so many things you can do with an image. You can load it from a file or URL. You can calculate its size. You can stuff it into some buffer. You can even display it in a variety of ways. As long as you have a graphics library handy, one would think that these things would be fairly straightforward tasks.

Ali was what they like to call "Purist". You know the type by now: the man who's never met a piece of Java code that didn't need a refactor for the sake of "style". Too bad for him he was assigned to work on some code that had been ported to Java from other languages. It worked, but it wasn't Pure.

Nor was he sensitive to budget constraints or scheduling issues. On one fateful Friday afternoon, he couldn't take the impurity any longer. Over the course of around 6 hours, he committed dozens of minor revisions to source control, touching nearly every file in the codebase:

Shawn's company needed a critical piece of software developed ASAP. The development team estimated six weeks of time to build it from scratch, but those in charge felt that was far too excessive. The devs had a track record of missing features--"Management NEVER told us we needed that feature!", botched rollouts--"What?! You told $newClient their site would go live on Monday? The product won't be ready until August and it's only February!", and going over-budget--"We developed it for SQL Server Express, I don't know why $phb bought us an enterprise Oracle instance."

Against the objections of everyone who did the actual work within the company, management partnered with the local University to have graduate students, most of whom had zero experience outside of academia, develop the new system for internship credit. Unpaid, of course. The plan then was that Shawn would spend "an hour or two" to polish the code up a bit and get it going in production.

These days, most languages have some variation on the “structured exception handling” concept. Exceptions get thrown inside of a “try” block, and then a search begins for a matching “catch” block, specific to that kind of exception. Each type of exception can be handled differently, which allows minor errors to print messages for the user, while fatal, state-corrupting errors can lead to the application exiting and hopefully not damaging any data.

A good developer catches all of the possible exceptions. By that standard, the contractor who gave Martina this code must be one of the best :

Once upon a time, in a far off kingdom named 1996, there was a developer named Jack. Jack worked for a poor company that could barely afford to buy grain with which to bake objects; they had to make do with Delphi forms, pinching and scraping what they could into an application. Instead of methods, they were stuck with button events, from which they milked database tables.

One day, Jack came to realize that the button events were growing old, and soon, no more good could be wrung from them. Sadly, he knew it was time to retire his old Delphi code. But what could he live on?

To help ring in the new year, here - enjoy this "Best of WTF" classic that ran in 2014!

Tom works as a pentester and, as such, gets paid big bucks for finding flaws in his clients' websites usually because he has to find less than obvious 'gotcha'-level flaws.