Ornoth

Say you were a young college student taking a programming class, and your aging computer science professor’s first assignment was for each student to write a program to print out their name and telephone number.

That wouldn’t be the least bit sus, now would it?

Apparently, back in 1984 it wasn’t! Lemme tell you a story…

I was recently bedridden with both a back injury and my first case of Covid. And having already purged many of my old books, I really had to stretch (metaphorically, of course) to find something to entertain myself with.

One book that followed me through my migrations – from Maine to (five different locations in) Massachusetts, then Pittsburgh, and finally Texas – was a college textbook that was highly cherished by most of the CS majors I knew back then: George Struble’s “Assembler Language Programming for the IBM System/370 Family”.

Yes, I was so bored that I started re-reading a 40 year old textbook on one of the driest topics in all of computer science, for a computer that no longer exists!

Chapter 1 is a snoozer (not unlike the rest of the book). It’s all about how mainframe computers used combinations of ones and zeroes to encode numbers and characters. Like any textbook, the end of Chapter 1 had a dozen exercises for the student to solve, to promote active learning and demonstrate a practical understanding of what’s been taught.

Here’s the text of Problem 1.3: (emphasis mine)

Each byte of storage in the IBM System/370 contains eight bits of information and one parity bit. The parity bit is redundant; it is used only to guarantee that information bits are not lost. The parity bit is set to 1 or 0 so as to make the sum of 1’s represented in the nine bits an odd number. For example, the character / is represented in eight bits (in EBCDIC) by 01100001. The parity bit to go with this character will be 0, because there are three 1’s among the information-carrying bits. The character Q is represented by 11011000, and the parity bit is set to 1, so there will be five 1-bits among the nine. These representations with parity bit (we call this “odd parity”) are also used in magnetic tape and disk storage associated with the IBM System/370. Using the character representation table of Appendix A, code your name and telephone number in eight-bit EBCDIC representations, and add the correct parity bit to each character.

That’s right: on just the third exercise in the entire book, Struble is asking the student to provide their personal contact info, presumably to their instructor. I can only imagine the repercussions if a professor presented this exercise to his or her class today.

To be fair, when Struble’s book came out (in 1969, then revised in 1974 and again in 1984) such an assignment simply wouldn’t have set off the red flags it does today. The author and his editors probably felt safe in the assumption that women wouldn’t be taking hard-core mainframe assembler classes. And for the odd exception, what harm could possibly come from a young coed revealing her phone number to an upstanding member of the academic community?

What harm, indeed.

I’m not one to condemn past generations for not living up to more modern social norms, but still… Today that exercise just screams of inappropriateness and invasion of privacy. For me, reading that was a head-scratching moment of astonishment from an unexpected source, a true blast from my past.

Being a programmer and obsessive about data is not always an ideal combination.

Most people make a habit of knowing their age. After all, it’s a basic vital statistic, and a useful piece of information to have on hand.

Of course, no one actually pays attention how old they are. After all, when you tell us you’re so-many years old, that’s only a vague approximation, with a typical variance of hundreds of days.

That is, unless you’re data-obsessed, and have the engineering skills to write a program to calculate your age to a higher degree of precision.

That’s where this story comes back to me. Over the years, I’ve written programs in several languages that tell me exactly how old I am. But since dates are messy, I don’t go too crazy about precision; two decimal places—a hundredth of a year is a three-day window—is close enough for me.

One of the oldest such programs runs as part of a Rexx macro when I open up Kedit, a favorite old text editor (and coincidentally the one I author my blogposts in). It calculates the difference between the current date and my date of birth, which is hardcoded in the program in Rexx’s standard “USA” format: MM/DD/YY.

All that worked great until a little while ago, when it started barfing up crap data. I didn’t pay much attention to the error until recently, when I was cleaning out a bunch of old code. And when I figured out what the problem was… it really pissed me off!

The relevant section of the manual spells it out rather bluntly:

When DATECONV() is used to convert a date that is specified using a 2-digit year, it assumes that the date falls within a 100 year sliding window starting at (current year - 50) and ending at (current year + 49).

For example, in 2007, DATECONV would convert 2-digit years to 4-digit years in the range 1957-2056. But in 2008, the sliding window would move by a year to cover 1958-2057.

Fast-forward to 2014, when Rexx decided that the “63” of my birth year no longer referred to 1963, but to 2063. In other words, shortly after I turned fifty, my birthday no longer fell within Rexx’s 50-year sliding window for converting two-digit years. It surprised me to realize that today we are actually closer to 2063 than we are to 1963!

So thanks Kedit/Rexx for breaking my age calculations. And thank you even more for letting me know that I’m too damned old for you to consider my birth year the most likely expansion of the two-digit abbreviation “63”.

With the perspective that comes from thirty years in tech, I’ve gained quite an appreciation for the basic absurdity of developing software.

A quick look in the rear-view tells a revealing story.

Of the volumes of software I’ve written, perhaps a quarter of it was never even used. And nearly all of the code that did make it into production was gone and deleted within five years of its creation. Heck, half of the companies I worked for disappeared within eight years! And nearly every programming environment I ever learned was obsolete within ten.

While everyone talks about how rapidly technology evolves, it’s rare that anyone thinks through the implications. The software that I was quite well paid to craft has been astonishingly ephemeral, and the development tools that I’ve used have had a useful lifetime somewhat shorter than my last pair of socks.

Needless to say, this isn’t just my problem; everyone in our industry faces the same underlying challenge. Nothing lasts forever, but in tech, everything we learn, use, or create should come with a “use-by” date of fewer than 60 months.

When you were young, you probably got the impression that your career would be a linear journey from Point A (your first job) to Point B (a comfortable retirement).

In the tech field, it’s more like trying to steer a sailboat at sea. You can point yourself toward a destination, but the water’s hidden currents and tides will pull you in different directions. The wind, waves, and other people’s passage will also push you off course. Never mind that every employer and project asks you to use their own boat with completely different rigging! And sometimes, either by choice or necessity, your destination changes mid-stream. About the time you reach the middle your career, you realize that your industry and career trajectory are far more fluid than you foresaw when you first set out.

While all this change and dynamism makes it hard to make progress in any one direction for long, if you develop the insight and skills to respond to these changes wisely, you can still get to a happy destination, even if it might look nothing like what you imagined when you got your first offer letter.

What follows are a list of observations I’ve made over the course of my shifting career: some often-overlooked implications of trying to navigate my way through such a turbulent industry. I hope they are of value to you on your own journey.

First, let’s look at the implications the ephemeral nature of software has on companies as a whole.

As soon as a development team delivers a software system, companies and product managers need to immediately start planning for its replacement. These days, you have two options: either factor a perpetual enhancement and revision process into your product strategy, or plan to simply throw away and reinvent your system at great cost a little further down the road. The traditional concept of implementing a system once and then scaling back for a lengthy “maintenance phase” died about the same time as pay phones and busy signals. It’s a nice old-fashioned idea that will lead you directly toward your Chapter 7 filing.

Whether you are a product manager or a development lead, you must accept and somehow communicate to your development team that time to market is infinitely more important than the elegance or academic correctness of their code. Bug-free code does not exist, and companies are much more rigorous about following the old 80/20 rule. If you’re truly following the Agile model (rather than pretending, as so many companies do), your top priority is to ship the beta: get an initial offering with a minimal feature set out into the market, and then react rapidly to customer feedback. These days, software that is “good enough” is almost always good enough.

When I first became an engineer, my older brother offered me one of the most valuable insights of my entire career: never hire technical staff for the knowledge they already have; instead, evaluate candidates primarily on their ability to learn new skills quickly and effectively. Five years down the road, the knowledge they walked in the door with will have no value; their usefulness as employees will be determined by how easily and quickly they can become productive with new languages and tools. Furthermore, the optimal way to retain the best technical talent is to support their desire to keep up with current and emerging technologies.

Now let’s talk about a few things that apply both to individuals as well as companies.

Whether you’re an individual managing your to-do list or a product manager specifying features and enhancements, you’re always going to have more tasks than time and resources to complete them. Therefore, always work on the highest value item. Constantly ask yourself whether you and your team are working on the most strategically valuable task. Always attach yourself to the tasks that truly have the most impact, and don’t waste your time on anything else.

Risk is uncomfortable. Risk is a threat to one’s company and one’s career. And yet risk is an inherent part of every single thing we do. While moving cautiously forward might seem like the most comfortable and risk-free approach, it really only defers that pain, because there is a huge hidden risk associated with not moving forward assertively enough. Both corporations and individuals must learn how to embrace risk, tolerate its associated discomfort, and recover from failures.

Software engineers and managers often have a grand dream of software reuse: the idea that if you’re building a program to handle Task A, you should invest some extra time into making it generic enough to handle anticipated future Tasks B and C. In the real world, B and C might never be needed, and their requirements are likely to change between now and then anyways. While it goes against our sensibilities, it is often quicker and easier to just duplicate and customize old code to handle new tasks. If the additional cost of maintaining multiple versions becomes sufficient, only then should you invest the resources to refactor it into a single generalized solution. That might sound like blasphemy, but in thirty years I’ve rarely seen a compelling example where software reuse saved money in the long run.

Finally, let’s talk about how we as individual employees should respond to the fact that our work has such a surprisingly short lifetime.

On a purely tactical level, as soon as you finish a project, save some screenshots and code samples for your portfolio. Six months later, those sites you built will have changed significantly, if they survive at all.

While everyone wants to be the best at what they do, building deep expertise in any tool or language no longer makes sense, because most languages are supplanted in a few short years. Rather than becoming an expert at one thing, a better strategy is to become the long-derided jack of all trades: someone who has a wide breadth of knowledge, an understanding of the general principles that apply to all environments, and the ability to adapt to changing business needs and a changing job market. Cultivate your passion for perpetually learning new tools, and your ability to be comfortable doing so under stress and time pressure.

In terms of getting your resume noticed, what you have done is not always as significant as who you worked for. Sites and projects are ephemeral, but major companies last longer and will catch the reader’s eye. Working with companies that are household names will—for the rest of your life—help you get that first phone screen.

My advice to all individuals is to focus on saving cash when you’re working, so that you can comfortably weather the inevitable downturns in the business cycle. Every time I’ve been laid off, I’ve been able to take a year or two off to decompress, have some fun, wait for the next upturn in hiring, and then be selective in my hunt for a new position. Layoffs and buy-outs weren’t personal emergencies because I had the cash on hand to weather any situation that arose. But if you take time off, devote some time to keeping your skills up to date and learning marketable new technologies.

Unlike the coding I’ve done, the one element of my career that has proven surprisingly durable over the long-term has been the relationships I’ve built with my coworkers. Despite everyone moving from project to project and job to job and often city to city, people remember you forever, and a robust contact list is immensely helpful in finding great places to work (and knowing which ones to avoid). It might sound crazy, but this has been one of the most important elements of my career success: put just as much effort into developing good relationships with your coworkers as you put into the software you write. Software doesn’t last, but people do.

Finally, one closing bit of advice about the long-term. If you want to be happy when you look back on your career, you must work for companies and projects that improve people’s lives, rather than just making a buck. Being a successful spammer or marketer might pay the bills, but money isn’t fulfillment. No matter how elegant, satisfaction will not come from the short-lived systems you build; real, lasting fulfillment comes from the impact your work had on real people’s lives. Life is too short to waste your time working on shit that doesn’t have any meaningful value, so make sure you’re contributing to a business you can really believe in.

And, of course, don’t be surprised or dismayed when the systems you worked so hard to build disappear overnight. It’s one of the facts of life as a software developer…

There really needs to be a corollary to Newton’s Second Law of Thermodynamics, stating that website maintenance is a constant (and un-winnable) battle against the Stupid introduced by other people.

Usually this involves a lot of quiet fuming while cleaning up the garbage left behind by the incompetent agents of entropy. But sometimes the Stupid is just so ludicrously headdeskingly perfect that there’s nothing you can do but laugh until you gag on your own puke. All the while, marveling at the “mysteries of the universe”.

For example, consider the following. While working on something, I once came across the following block of code on a production website:

$rss_feeds = "";
echo $rss_feeds;

Now, even if you’re code-illiterate, you can probably figure out what this does. It sets a variable to nothing and then prints… nothing.

Why? No reason. The only thing I can figure is that someone hired a contractor and paid them based on the sheer number of lines of code they produced.

Now, before I lose all the non-coders in the audience, here are a couple examples where people chose to demonstrate their mastery of their native language. For example, take this headline that appeared in a second-level heading on one page:

Private vs. Gevernment

Or this major announcement:

Without further adieu [...]

Or this favorite job listing of mine:

[...] is currently seeking a Senior FrontEnd Web Developer with 710 years of professional experience

Working our way into the code doesn’t have to be painful, though. How about this one: Need to name a file? Why not name it after your own awesome self?

$fileExt = 'markrules';

Another one that is easy for non-coders is this one:

<div id="left_content" class="right">

Yup. In the Stupid Universe, left is right and right is left.

Now how much would you pay? But wait: there’s more!

<?php //    include('ad_med_rectangle.inc.php'); ?>
<?php include('ad_med_rectangle.inc.php'); ?>

In PHP, two slashes are used to comment something out. So here we have a line of code carefully commented out. And then the exact same line, not commented out. Um… huh?

Speaking of comments, try figuring out what this one does:

$form->addElement('hidden', 'xzdf', 'A3104', array('id' => 'xzdf'));

Using names or key values with self-evident meanings is really overrated. The Law of Stupid instructs us to use completely nonsensical names, and make sure you don’t leave any comments in the code that might explain to the people maintaining your code what those random numbers and strings of characters actually mean!

And then there’s this mystery of the universe, a perennial favorite:

$term = ereg_replace("hero", "elongated sandwich", $term);

I can’t tell you why this site has such a strong aversion to heroes, but it’s clear that any time we find the word “hero”, we replace it with our preferred term “elongated sandwich”. No reason; we just do. No hero worship allowed here!

Here’s a fun one!

.blue_button {
    background: none repeat scroll 0 0 #ED8D1E;
}

Blue_button, huh? You might be forgiven if you thought that might actually show a button that was blue. But that background color of #ED8D1E? That’s dark orange. OF COURSE!

For some reason, “switch” statements seem beyond the grasp of many well-compensated “engineering professionals”. I’m not sure why it’s so difficult to do different things depending on whether a variable has a value of 1 or 2 or 3, etc. Is that so hard? Apparently it is. Here’s a nice example:

case 1:
     $url = 'http://www.awebsite.com/';
     break;
case 1:
     $url = 'http://www.awebsite.com/';
     break;
case 1:
     $url = 'http://www.awebsite.com/';
     break;
case 1:
     $url = 'http://www.awebsite.com/';
     break;
case 1:
     $url = 'http://www.awebsite.com/';
     break;

That’s a double dose of Stupid! Here, all the cases do exactly the same thing! But that’s okay, because they all test against the same value, too!

In plain English, it translates thus: if it’s a 1 you do this; but if it’s a 1 you still do this; or if it’s actually a 1 you would also do this; and if 1 you do the same thing too; and so on. That’s seventeen lines of code to do what requires only one. See what I mean about someone being paid per line of code?

Of course, that only works if you want to do something. Truly masterful Stupid code does nothing, like this switch statement:

switch($page[subnav]) {
}

Huh. Only outside of the Stupid Universe is it customary to write code to actually *do something*.

Of course, junior developers often aren’t wise enough yet to disguise the fact that they’re doing nothing. Consider this:

Yes, that’s nothing. That’s the whole contents of a file I found called small.css. Small, indeed! Perhaps they thought they weren’t leaving any evidence of their stupidity behind.

Here’s some additional CSS-flavored fun:

<div style="clear: left;"> </div>
<div style="clear: right;"> </div>

More from the Planet of the Confused: why not just do “clear:both”? Oh yeah, it’s because YOU HAVE NO IDEA WHAT YOU’RE DOING!!!

ttable tr td.odd {
     border-left: 0;
     border-right: 1px solid #fff;
}

Did the W3C create a new HTML tag (ttable) and I missed the news?

p.margin-left {margin-left: 15px; padding-right: 15px;}

So let me get this right: a paragraph called “margin-left” actually has equal margin on both sides? But on the left it’s a margin, and on the right it’s padding? That makes perfect sense, especially if you don’t understand basic HTML page layout!

Here’s an exemplary 12 lines of masterful coding:

if (isset($page_close)) {
$page_close .= <<<EOD
</body>
</html>
EOD;
} else {
$page_close = <<<EOD2
</body>
</html>
EOD2;
}
echo $page_close;

That’s just another example of how these guys clearly were getting paid per line of code. No matter what $page_close is set to, what those 12 lines of code really do is this:

</body>
</html>

No need for complex logic or any dynamic behavior. Good thing they inserted an extraneous IF/ELSE block, two “here quotes”, and echoing a variable, because how else would one know they were such masters of PHP syntax?

if (test_it_counter == 0) {
   computeForm(entry.form);
}
computeForm(entry.form);
test_it_counter++;

So the first time through this program, computeForm() get run twice in a row, just for kicks. I’m sure that works just great! I wonder why they didn’t run it twice every time?

<div id="nav" onmouseover="Tip('#nav { <br /> <var>float:</var> left; <br /> <var>width:</var> 788px; <br /> <var>height:</var> 36px; <br /> <var>margin:</var> 0; <br /> <var>padding:</var> 0; <br /> <var>background:</var> #fff url(images/navbg3.gif) no-repeat; <br /> <var>text-align:</var> center; <br /> } <br /><br /><cite>Note the hover action. </cite>')">

I have absolutely no idea what the coder was thinking here. If you hover over a nav, it displays a tooltip with a bunch of CSS code (which actually doesn’t get used and doesn’t appear anywhere in the page) and the message “note the hover action”. Glad that has been running out on the production web site for four or five years…

My final example is a solve-it-yourself problem. Are you ready for a developer challenge? How long does it take you to spot the Stupid in this statement?

<?php if ($isForm = false) {

This one’s an all-time classic and a personal favorite. When comparing a variable to a literal, professional software engineers always put the literal first. Do you know why? Well, the above is a perfect illustration why. The reason why will be left as an exercise for the reader.

Just a quick note to observe the 25th anniversary of both the Space Shuttle Challenger disaster… and my professional career.

The Challenger disaster is one of the few news events where I recall exactly where I was. At twenty minutes before noon on January 28 1986, I was at work.

Although I hadn’t finished my undergrad at UMaine, I had just begun working as a software engineer for the university’s parking, police, and fire departments, which were all housed in one old farmhouse on the edge of campus.

My Televideo 925 mainframe terminal was located just outside the police chief’s office, and when the news broke about the shuttle’s disintegration one minute into its flight, the chief called everyone into his office to watch the event on the television that he usually used for videotapes or presentations.

Three months earlier, in October of 1985, I had been fired from a job slinging sandwiches at 7-Eleven because I had actually read the manual on how to operate the cash registers. My buddy Mike Dow was doing database work for the parking department and brought me in to assist, since he and I had already done some volunteer work together on CSNEWS, one of the internet’s earliest information services. But the Public Safety gig was my very first paid programming job.

For that reason, the Challenger disaster is inextricably linked with the beginning of my professional programming career. A career which has now officially spanned twenty-five years.

It’s been quite a ride, but I won’t indulge in reminiscing about all the good and bad times along the way. I’ll simply say that I’ve learned a lot, developed valuable skills, had a lot of satisfying successes, made so many great friends, and had a ton of fun. It’s enough to make an unemployed guy want to go back to work!

But today isn’t about all those things. It’s really more about just taking a minute to say: Wow, twenty-five years!

One part of my life that I haven’t mentioned here is foosball.

My first exposure to foosball was when I started working at BI in 2005. Initially, I viewed foosball (table soccer) as a pretty stupid game, but I did start playing a bit. It was interesting to see the differences in skill level between good players and neophytes, and I decided I’d start cultivating my skills. Despite the rather mundane nature of the game, there are a lot of subtle skills one can develop, and it’s really quite interesting, once one actually gets into it.

When I moved to Optaros, I found they, too had a foosball table, and I started putting real effort into on developing my game. I also took over most of the maintenance of the table.

At the same time, I missed one of the features we had at BI. Our lead architect had begun keeping track of scores and developed a ranking system based on the same system used to rank chess players. It grew into a full-fledged .NET application, and people really took to it. I decided I’d bring “the foosball app” to Optaros.

Unfortunately, when I asked the guys where the source code was, no one could answer me. So I wound up having to study the Elo ranking system and reverse engineer the thing all over again, this time using Perl and MySQL. I called it “Frank”: Foosball Rank. I took the opportunity to tweak the UI a bit, and you can see the result here. Neeto features include charts of each player’s rating over time, and the ability to predict the score of any given matchup, based on the players’ ratings.

The cool thing is that people at work have taken to it pretty well. At first, I was entering all the scores myself, but people have caught on, and now it seems pretty self-sustaining. It made for a fun little project, and the level of competition has definitely gone up since the system went into production back in June. I guess if I was smart I’d put some advertising on that page and generate some revenue from it, but that’s not gonna happen.

But the foos—and the foos app—are definitely interesting additions that I’m enjoying.