Fred S. never much cared for zebra striping, the UI pattern than was all the rage after Mac OS X launched in 2001. It found its way into other Mac applications, web pages, even onto Linux. Like a tsunami of alternating grey-and-white waves, it overtook everything in its path.
After numerous requests from users, the project manager for WeightTracker asked Fred to add zebra striping to the weight journal window. Fred had inherited oversight of the application after the original developer, Louis, had been poached by their underperforming rival.
As an IT infrastructure manager, Jerry spent more time skimming his junkmail folder than he liked. Unfortunately, a large number of important messages landed there, because Garrett, the CSO, mandated an extremely aggressive approach to identifying spam. No less than once a week, a vital message was marked as spam.
"I was looking at prices for a train journey," writes Hamish, "I think my company's accountant might raise an eyebrow if I upgraded to first class".
"Chinese buffet2". Licensed under CC BY-SA 3.0 via Wikimedia Commons.
Assembler. C. C++. C#. PHP. Javascript. Bash. Perl. Ruby. Java. These were just some of the technologies featured on the resume of a candidate Christian recently interviewed for a senior Linux sysadmin position. The impressive list of programming languages (and related data-interchange acronyms like XSLT and JSON) made the candidate, let's call him Rob, seem more qualified for a developer position, but he went on to list common web server databases like MySQL and Postgres (plus a couple flavours of NoSQL), and, finally, the qualifications Christian was actually interested in: Tomcat, JBOSS, the Hotspot JVM, and every major Linux distro. While the resume reeked of keyword-baiting, Christian didn't want to risk missing out on an excellent sysadmin who just happened to spend a lot of time hacking, and brought Rob in.
Christian kicked off the interview by describing their infrastructure. Working for a major enterprise, his division was responsible for fifteen hundred Java application servers, clustered into groups of three or four. He explained to Rob how they managed the large number of identical deployments using Puppet, with SVN to track changes to their enormous catalog of scripts. He got through most of their rollout and monitoring processes before Rob cut in with a question.
Peter came across this helpful little utility function:
public static DateTime EPOCH_UTC()
{
DateTime epoch = new DateTime(1980, 1, 1, 0, 0, 0);
return epoch;
}DBAs are supposed to bring knowledge of the underpinnings of databases to the table. How to lay out tables and indices across disks for linear vs. striped access. How to properly set up partitioning for different types of access. Granting assorted privileges and roles. Managing backup and aging off data in a controlled manner, and so forth.
Some take pride in showing developers the "right" way. Some are maniacal in their tight-fisted my-way-or-the-highway approach. Others seem better suited to a career of asking do you want fries with that?
A little while back, I posted a user survey and asked for some general comments -- thanks to everyone who replied and shared their thoughts. I was hoping to share the survey results sooner, but I got a bit caught up in that Release! Kickstarter project.
In addition to some basic demographics questions, the survey asked some questions about a site redesign:
Correct now, optimize later. is one of the most important developer mantras and Scott K. followed it to a fault. He was on a team of programmers debugging a C# package management application, which used Microsoft SQL for revision tracking. Make sure it works right the first time; you can always tease out more performance after launch.
But if your program takes ten minutes to extract a C# package, as Scott discovered, you might want to optimize sooner rather than later.
"When War Thunder crashed, apparently there were some squirrels hiding in there and they gnawed on something. I don't know which button I'm supposed to push!" Jay wrote.
Mark was upset. You didn't have to sit next to him to know it, either. Even though his cubicle was at the far end of the farm, his frequent tirades were always audible to the rest of the office. Mark wasn't the most skilled or the most careful developer on the team, but what he lacked in ability he made up for in volume: a lot of his poorer decisions stood simply because his colleagues wanted to avoid a barrage.
The installer for their main product was Mark's pride and joy, so Jonathan tried to stay as far from the code as possible. Mark had long ago added a timeout to the code that checked for a stuck installation, but it consistently went off too early, complaining about failure when the installation would eventually succeed. When Mark tired of the QA team complaining, Jonathan overheard him bellowing at the team lead.
