- Feature Articles
- Other Articles
Alex T had hit the ceiling with his current team, in terms of career advancement. He was ready to be promoted to a senior position, but there simply wasn’t room where he was- they were top-heavy as it was, and there were whispers among management of needing to make some cuts from that team. So Alex started looking for other openings.
There was another team at his company which had just lost all of its senior developers to other teams. Alex knew that was a bad sign, but in general, climbing the career ladder was a one-way street. Once he had a senior position, even if it was terrible, he could transfer to another team in a few months, keeping his senior title and salary.
We live in a brave new world. Microsoft, over the past few years has emphasized, more and more, a cross-platform, open-source approach. So, for example, if you were developing something in .NET today, it’s not unreasonable that you might want to parse a PList file- the OSX/NextStep/GNUStep configuration file format.
But let’s rewind, oh, say, five years. An Anonymous reader found a third-party library in their .NET application. It never passed through any review or acquisition process- it was simply dropped in by another developer. Despite being a .NET library, it uses PLists as its configuration format- despite .NET offering a perfectly good in-built format. Of course, this C# code isn’t what we’d call good code, and thus one is left with an impression that someone hastily ported an Objective-C library without really thinking about what they were doing.
There are certain tropes that show up in our articles, and judging from our comments section, our readers are well aware of them. For example, if a manager in a story says, “You’re going to love working with $X, they’re very smart,” it’s a pretty clear sign that the character in question is not very smart, and is almost certainly sure to be TRWTF in the story.
Part of this is narrative convenience- we try and keep our articles “coffee-break length”, and dropping a few obvious signals in there helps keep it concise. Most of it, however, really boils down to the fact that reality is full of certain patterns. The world is full of people who aren’t half as smart as they think they are. There are legions of PHBs ready to micromanage even if they haven’t a clue what they’re doing. And there are a lot of employers that can make a terrible job sound really great for the duration of the interview process.
Many decades ago, DefCon Inc, a defense contractor working for the US military was attempting to get awarded a new contract to build some widget needed for combat. As part of their proposal, they wished to demonstrate that they had the available staff to dedicate to the project. Toward this end, they hired more than 1,000 assorted programmers, project leads, managers and so forth. The military folks that were evaluating the various proposals saw a slew of new employees that were completely unfamiliar with the relevant processes, procedures and requirements, and awarded the contract to another firm. In response, the contractor laid off all 1,000 folks.
A few months later, another such contract came up for grabs. Again, they hired 1,000 folks to show that they had the staff. A few months later, that contract was also awarded to another contractor, and again, all 1,000 folks were laid off.
I once built a system with the job of tracking various laboratory instruments, and sending out notifications when they needed to be calibrated. The rules for when different instruments triggered notifications, and when notifications should be sent, and so on, were very complicated.
An Anonymous reader has a similar problem. They’re tracking “Events”- like seminars and conferences. These multi-day events often have an end date, but some of them are actually open ended events. They need to, given an event, be able to tell you how much it costs. And our Anonymous reader’s co-worker came up with this solution to that problem:
Just following the logic of a language can send you a long way to getting good results. Popular languages were designed by smart people, who work through many of the problems you might encounter when building a program with their tools. That doesn’t mean that you can’t take things a bit too far and misapply that philosophy, though.