Author: Jud

Technologist interested in building both systems and organizations that are secure, scaleable, cost-effective, and most of all, good for humanity.
Way Way Back

Way Way Back

By | | Comments 3 comments

I’ve had the pleasure of working with a large variety of technologies over the course of my career. Yesterday I was working on an interface to an old government database, without the aid of documentation, natch. After a few hours I was able to extract data from the system, but I was unable to decode it. Google is a great tool (I couldn’t get 15 minutes into my day without it), but if you don’t know what to search for you can’t find anything. Thankfully some careful guesses led me to the Wikipedia entry for EBCDIC, a character encoding developed in the mid-60s.

“Extended Binary Coded Decimal Interchange Code (EBCDIC) is an eight-bit character encoding used mainly on IBM mainframe and IBM midrange computer operating systems. EBCDIC descended from the code used with punched cards and the corresponding six bit binary-coded decimal code used with most of IBM’s computer peripherals of the late 1950s and early 1960s.”

It’s a fun thing in this industry to say you’ve worked with 50-year-old technology, but only once you’ve figured it out. Surprisingly there’s some modern tooling to interface with this particular encoding (yay Python!), so once I knew what I was dealing with it was straightforward enough. Maybe even easier than what it used to be, if this anecdote is to be believed:

EBCDIC: An alleged character set used on IBM dinosaurs. It exists in at least six mutually incompatible versions, all featuring such delights as non-contiguous letter sequences and the absence of several ASCII punctuation characters fairly important for modern computer languages (exactly which characters are absent varies according to which version of EBCDIC you’re looking at). IBM adapted EBCDIC from punched card code in the early 1960s and promulgated it as a customer-control tactic, spurning the already established ASCII standard. Today, IBM claims to be an open-systems company, but IBM’s own description of the EBCDIC variants and how to convert between them is still internally classified top-secret, burn-before-reading. Hackers blanch at the very name of EBCDIC and consider it a manifestation of purest evil.

Don’t Judge Your Book By Its Cover

Don’t Judge Your Book By Its Cover

By | | Comments 0 Comment

It’s been said that Vincent Van Gogh didn’t like _The Starry Night_, which is crazy, because it’s one of the world’s most recognizable paintings, and an obvious masterpiece.

If some of history’s greatest artists were unable to judge the value of their work accurately, how much less so are we. Don’t be quick to disparage your creative efforts, no matter how meager they may seem.

Follow The Money

Follow The Money

By | | Comments 0 Comment

I read this quote in a completely non-software context last week, and it’s been rattling around in my brain ever since for its implications in numerous disciplines:

“It is difficult to get a man to understand something, when his salary depends upon his not understanding it.”

I’ve had experiences where I’ve been trying to explain the benefits of automation to people whose job descriptions include large amounts of manual work. Or more significantly, managers whose bonuses are directly tied to the profit they can bring in via labor hours billed to the customer. Needless to say those explanations fell on deaf ears.

That’s just one example. I’m certain there are more.

Phantom Fix

Phantom Fix

By | | Comments 0 Comment

I’ve got good news and bad news. The good news is that the system is working now. The bad news is that we have no idea why.

The above scenario plays out regularly in the life of a software developer, and it’s infuriating. In some sense it’s worse for a problem to disappear without warning than it is for the problem to persist, because without reproducibility it’s nearly impossible to determine the actual cause of the issue.

This happened to me after losing a big chunk of my Saturday night. Essentially the issue fixed itself after several retries. No idea at all as to why, but at least I could finally go to bed.

Diligence Is For Lazy People

Diligence Is For Lazy People

By | | Comments 0 Comment

I wrote yesterday’s post almost a full day in advance, which hadn’t happened before in the (admittedly short) history of this blog. It felt really nice when my daily 9am writing reminder went off to simply click “Publish” and get on with my day, instead of hitting snooze and hoping I get back to it later.

It brought to mind my sophomore year of college, where I learned the value of discipline. My fiancée was at a school ten hours away, and I had a randomly assigned roommate with whom I had nothing in common (and despite his pedestrian physical appearance managed to have three simultaneous girlfriends for most the year, but that’s a different story). I also had a class schedule that finished by 2pm every day.

Since I had little reason to get back to my lonely little dorm room so early in the day, I got in the habit of hanging out in the library studying until dinner. I quickly discovered that this routine completely freed my evenings and weekends of schoolwork. And that was awesome. I wasted gobs of time playing video games during those hours, and didn’t feel the slightest bit bad about it, because my work was done.

It’s Elementary

It’s Elementary

By | | Comments 0 Comment

There are really only two tasks a company must perform:

  • Make great products
  • Sell them for a profit

Each employee, no matter her job title or role, must contribute in some way to one or both of those two goals. Any other task is only a means to one of these ends; everyone involved does well to remember that.

And yes, I realize strictly speaking products and services are two different things, but for the sake of pith can we consider the latter a type of the former? Thanks.

Two Days In A Row?

Two Days In A Row?

By | | Comments 1 comment

Back in my days working for a large defense contractor, it was understood that as a developer became senior she would get involved in writing proposals. At the time I thought it an odd expectation; shouldn’t developers stick to doing what they do best, i.e. writing code?

But now I see the wisdom in getting engineers more involved in the process of winning new business. For one thing, it forces them to write, which is not a bad thing, even though it isn’t always fun. Secondly, it helps build relationships between engineering and sales, two departments which are often at odds (this is probably worthy of its own post, stay tuned for that). Finally, it gives them insight into the kinds of features customers are asking for, and allows them to be a part of suggesting creative solutions for those features.

So yeah, I’m a proponent of proposal writing. And in a completely unrelated note, I’ve got a big spreadsheet of proposal questions I need to divvy up among the team for responses. Who’s with me?

Z Is The Most Important Letter

Z Is The Most Important Letter

By | | Comments 1 comment

(I’ve been asleep at the wheel for far too long here, time to dive back in with a truckload of mixed metaphors).

Do you get enough sleep? Americans are chronically sleep-deprived, and a body of research is growing that tells us how damaging a lack of rest is to every other area of life (see, for example, this fantastic article). The particularly troublesome aspect is how sneaky the damage can be, manifesting itself in subtle ways over time.

A large part of being a professional software developer is taking care of your meatspace hardware. And that means getting regular sleep. The image of the late-night coding warrior who bangs away at the keyboard until the wee hours of the morning may play well on TV, but it’s false. The most effective engineer is one who rests.

The Bible Of Software Engineering

The Bible Of Software Engineering

By | | Comments 0 Comment

One of my all-time favorite passages on software development.

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Frederick P. Brooks, The Mythical Man-Month

The Name Of Things

The Name Of Things

By | | Comments 0 Comment

If you cannot say the words, you cannot solve the problem.

This is true of many subjects in the world right now, a crippling inability to call things what they are. But it is also true of software development. I’ve written before about the importance of accepting blame when something goes wrong. The first step of that process is being willing to say what went wrong, to name it with precision. Shortly thereafter the people responsible for ensuring that particular thing doesn’t go wrong should be named, not to shame them or make them feel bad, but so they can be given the opportunity to improve in the future.

While it might be easier to “not point fingers”, such an approach rarely helps an organization get better.