What's proper etiquette for handling code snafus when working for -- literally -- a mom-and-pop company?
It's a situation a coder should never have to face: perpetuating bad coding practices from years ago, or just fixing the darn thing!
Would going above and beyond when fixing terrible code have serious consequences?
Why user requests shouldn't always be granted.
That dinosaur of an office appliance -- the fax machine -- plays an unexpected role in Jason's Web site registration puzzle.
When fewer SQL Server columns does not mean better performance.
Everything at Henry's company revolved around contracts with vendors. The IT department had relied on the aptly named Contract Manager -- the sole remaining Visual Basic 6 client-server application -- to support that business for the past 12 years.
The office where Peter L. works was abuzz with excitement one morning a few months ago when the familiar, bland corporate art was missing from the wall opposite the elevators.
When Brett was hired on as a senior analyst, he wasn't surprised to learn that the older platforms were built around Visual Basic 6 (VB6), which was no longer supported by Microsoft.
Dueling developers create an unappetizing code stew.
Usually, when a multi-megabyte e-mail lands in Jerry's inbox, it means that someone tried to be fancy by including some silly photos or graphic images in intra-office correspondence.
A major validation error in the code resulted in a 60 percent failure rate for an expense form.
Henry was the TAXCALC king. But his coding skills were positively peasant-like.
Was "Calvin code" genius or tomfoolery?
For years, nobody cared that the legacy image-syncing application consumed as much bandwidth and processing time as it did.