“You should get some real-world experience.”
D.H. was in college to study video game programming, and his professors encouraged him to find an internship. “The real programming business is nothing like these university assignments.”
What the real world doesn't look like
D.H. found a year long internship, ready to have his mind blown by how different it was, and his mind was certainly blown- but not for the reasons he was expecting…
On his first day, D.H. was shuffled into a conference room with 19 other interns for their orientation. The company was a large one, mostly doing IT and software consulting. With that many interns, most of them fell into the dreaded roles of donut-fetcher and coffee distributor, but D.H. lucked into doing some actual development work.
After a few weeks of getting to know things, Bernie, the lead developer, came by with a new assignment. “We’ve got some new validation rules in the application. They’re pretty easy to follow, so why don’t you help us out by doing the testing? If you find any bugs, feel free to take a crack at solving them yourself.”
This was a dull line-of-business application, but his game development classes came in handy. In a world of online cheating, he knew better than to ever trust client input. His caution earned his coworkers’ respect. D.H. was excellent at finding and fixing issues ranging from simple mistakes, like not constraining the quantity field to an integer; poor design, like confusing and ineffective radio-buttons; and just plain bad coding, such as relying on thrown exceptions to recognize invalid inputs. By the end of his one-year internship, D.H. was the “expert” on not one, but three of their major applications.
It was D.H.’s last week when Bernie came to him in a panic. “D.H.! Before you leave, can you please take a look at bug #622512? This is causing a lot of problems. I’ve had all of our experts look at it, and they’re stumped. It’s causing reboots, and the server guys are ticked off!”
“Sure,” D.H. replied.
D.H. opened up their internal bugtracker and read the issue. Multiple users had complained about the application’s checkout page not working, specifically when they used promo codes. Even worse, when they had trouble with promo codes, the website became unresponsive. The server team was monitoring it, and automatically rebooted the server whenever the application crashed.
D.H. read the notes from the other developers, which all amounted to, “Read the code, didn’t see anything odd.” So D.H. did what they hadn’t- he fired up the checkout page and tried to reproduce the issue with a list of current promo codes. Before he got too far, he got sidetracked by other bugs on the page. Users with hyphenated last names couldn’t make purchases. Selecting the radio button to decline an extended warranty didn’t disable the extended warranty form, meaning users could actually decline a warranty at the same time as requesting a five-year warranty. Neither of those was related to the application crash, but they were easy enough to fix while he was in there.
Finally, he discovered how to trigger the crash. Specifically, he had to enter an invalid promo code, not a valid one. With this knowledge, he took another dive into the code with his debugger.
And found this:
if (isCodeValid(promo_code) || !isCodeValid(promo_code))
{
addPromoToCart();
displayPromoError();
}
else
{
addPromoToCart();
displayPromoError();
}
Sure, the if statement’s condition was a tautology, but the else (which was unreachable) did the same thing anyway. Even with a bad promo code, it would attempt to apply the promo code, and a stored procedure on the backend would crash and burn horribly. D.H. had seen the database code once- once- and dreaded the thought of trying to fix that, but fortunately, he didn’t need to- it was blindingly obvious how to fix the code.
The next week, his internship was over, and he returned to school full time. He was older, wiser, and armed with “real world” experience, but he kept wondering: how would that company do without their resident Expert Intern?