Forums
A curious email arrived in Phil's Inbox. "Windows Support Engineer required. Must have experience of the following:" and then a long list of Microsoft products.
Phil frowned. The location was convenient; the salary was fine, just the list of software seemed somewhat intimidating. Nevertheless, he replied to the agency saying that he was interested in applying for the position.
Companies beyond a certain size all follow the same basic pattern. Where possible, everything gets centralized in the global office- email, web servers, Active Directory, etc. They dictate policy and then leave it to the extremeties to solve their own problems within the corporate boundaries. Al worked at a factory, supporting their production management and chemicals management software- things that couldn’t be centralized.
Each day, when Al logged in, his computer greeted him with the standard warning message. “This computer is private property, and its use is subject to our IT policies (123.6, 216.2, and 551.A), and if you’re caught using it for porn or pirated software we will fire you so fast the unemployment line will be blueshifted.” Each time, he ignored it and clicked “OK”.
It's Thanksgiving here in the US, so we're taking the day off! So, here, enjoy a classic. Cursed and Re-Cursed was originally published on May 7, 2009.
Graham K. was working for an atmospheric chemistry research group in a university in Wollongong, New South Wales, Australia. They'd been running a field experiment in sugar cane fields on a government research farm that was roughly 1500km (~932mi) away in Mackay.
College radio stations are small, but highly technical organizations. The era of the scruffy stoner spinning disks and mumbling into a microphone have been replaced by software systems that manage the station’s programming around the clock, and play recorded segments of scruffy stoners mumbling into microphones.
Kyle was the “tech-guy” at one station. Like any other small organization, the job involved doing anything from desktop support to server administration and some basic programming on the side. To keep the station’s website up to date, Kyle’s predecessor, Chad, had built a home-grown CMS-like system. Everything done by the station ended up there, in one form or another: photographs of every event, recordings of every interview, calendars and set-lists. As the tech-guy, Kyle put all of the data into that system.
A few years ago, while on a SQL Server data warehousing project, my project manager sent me a request - create a table with all kinds of information based on a given date. You know – given a date, be able to figure out day of the year, day of the week, month, last business day of the week, and so on, making sure the table stores enough dates to keep it maintenance free. Oh, and one more thing, it’s going to be linked off of the already complex star schema that we were developing for. Why? For reporting purposes of course.
Thankfully, I was able to talk my way out of it by explaining how SQL Server has built-in date functions that can do the job on the fly and that if I were to make that table, I’d have to go through the trouble of writing a bunch of date-related code anyway. However, the original developer for the database that Terje Nilima Monsen works on, must not have been as lucky as I was.
Every developer eventually breaks something in production. Whether by negligence, ignorance, or just plain bad luck, it happens even to the best of us. "Oops" moments like these are the ones we learn and grow from. The broken thing gets fixed, some data may or may not get cleaned up, and everybody moves on a bit for the wiser.
Unfortunately for Matt, he doesn't get to take a mulligan; he works in the industry where bad code might not cost just money and time, but lives as well. His organization has a very good reason for putting in place a strict code review process ahead of every promote.
The user’s incident report did not contain the most useful description of the problem. “The calculator always outputs zero,” it said. Fortunately for Aram, he had a little bit of an idea of the context, and he knew that the issue was in the Customer/Regulation Administration Processor.
That name was a collective label for a suite of web applications, web services, and client pieces built around managing business process data for dangerous-goods regulation. The original design had been a bit of a mish-mash, and for the past year or so, Aram had heard that the core developers were gradually migrating it to a more SOA implementation.
Like snakes and mongooses , QA and developers are natural enemies. Through an unfortunate series of events, developer Bridget found herself working on a QA team. She was deep in enemy territory, and not full prepared for the rigors of QA, so she focused on her core developer skills. She helped the testers automate things.
“Well, we already have automated scripts,” her new co-worker, Jim, said. “We just… well, we only use them for really big regressions.”
The daisy wheel stabbing at green-lined sheets could have been Satan’s fanfare, but Andy was long accustomed to tuning out ambient printer noise. It was 1982, and he spent most of his time before his Commodore PET 4032, churning out useful things in 6502 Assembly. Most of the code was for printing invoices, much like customer invoice currently printing and making all of that racket.
A sudden cloud formed over his desk. Once Andy clued in to the shadow overhead, he glanced up to find the new regional sales manager, Rick, accordion-folded printout in hand.
"Hey Ryan! Glad I got ahold of you, have a minute to lend a hand?" spoke a surprisingly jovial voice on the other end on the NOC’s emergency support "bat phone". It was the company's email admin, Jeff.
"Sure! Hang on a sec." Ryan panted before frantically stabbing at the phone's mute button as if he had just been caught slacking. After finding his notebook and pen, Ryan unmuted his phone and told Jeff to continue.
Oct 12