Monday, February 20, 2017

How Long Can I Remain a [Ruby, Java, C++, Python, …]  Programmer?

Several respondents to an earlier post have asked me about the future prospects for workers in one programming language or another. Here's my best answer.

As others have said, "I can predict anything but the future." But also others have said that the only things we know about the future are what we know from the past. Therefore, you might get some idea of your future as a [Ruby …] programmer from the answers to a recent Quora question, "What were some jobs which existed 50 years ago but have largely disappeared today?"

It was great fun reading all these answers, many of which described jobs I held back then. I go back a bit more than 50 years, though, so I have a few more to add. Most obvious omission was the iceman. In the 1930s, we had an icebox (not a refrigerator, but an actual box that held a block of ice). The iceman’s horse-drawn wagon would come around regularly and be surrounded by us kids, hoping to get free shards of ice caused when he cut up little blocks to fit our iceboxes.

Another job only briefly mentioned was typesetting. I never held that job, but I was trained for manual typesetting for a semester in high school. At least I know where terms like upper-case and lower-case come from.

Someone also mentioned keypunch operator, a task (not a job) that was often done by prisoners who were literally chained to their machines. Who weren't mentioned, however, were key verifier operators. Not many people today have ever seen a verifier, let alone even know what one was.

Even before my time, there were jobs that disappeared, but which I read about—for instance, in a nineteenth century book about jobs for women. The final two chapters in the book were about a couple of sure-fire women’s jobs for the future (1900 was then the future).

First chapter was about teletype operators. The chapter “proved” that there was a great future for women because they could operate a telegraph key at least as fast as men (and the telephone had yet to be invented).

Second chapter was about picture tinters. There was, of course, no color photography, and it wasn’t really even conceived of. Women were supposedly much better at coloring photos because of their “artistic bent” and their more delicate hands. Though there are a few photo tinters still around today for special jobs, it’s not a career with a great future.

By the way, one future job for women that wasn't even mentioned in the book was typist (or amenuensis) in spite of the then recent exciting invention of the typewriter. Other sources explained that women would never be typists because everyone knew that women were not good with machines.

It's fun to think about these forgotten jobs, but they're also a source of important knowledge, or perhaps even wisdom. Job disappearance is not some new phenomenon caused by computers. It's always gone on through history. True, some jobs lasted a long time, so long that they were passed down from generation to generation, even becoming family names, such as Smith, Turner, Eisenhower, Baker, and Miller. (See, for example, <> for hundreds of examples)

Some of those jobs still exist, though often modified by new technology. Do you still recognize Fuller, Chandler, or Ackerman? And many others have largely disappeared, remaining only in some special niche, like photo tinters. Do you know anybody named Armbruster who still makes crossbows? Well, you probably know a few Coopers, but how many of them still make barrels?

No job is guaranteed. Nothing entitles you to hold the same job for life, let alone pass the job down to your children. So, for example, if you think of yourself as a "[Ruby…] Programmer," perhaps you'd better prepare yourself for future with a more general job description, such as "programmer" or "problem-solver."

In fact, there's a whole lot of people out there who think (or hope) the job of "programmer" will disappear one of these days. Some of them have been building apps since the time of COBOL that would "eliminate programmers." I've mocked these overblown efforts for half a century, but history has tried to teach me to be a bit more humble. Whether or not they succeed in your lifetime, you might want to hedge your bets and keep learning additional skills. Perhaps in your lifetime we'll still need problem-solvers and leaders long after we've forgotten the need for Chamberlains and Stringers.

Additional reading: 

Monday, February 13, 2017

Should I learn C++ or Python?

When I first saw this question on Quora, there were already 47 answers, pretty much all of them wrong. But the number of different answers tells you something: choice of programming language is more of a religious question than a technical one. The fact is that if you want to be a professional programmer, you should learn both—and at the same time.

When we teach programming, we always teach at least two languages at the same time, in parallel. Assignments must be done in both (or more) languages, submitted along with a short essay on why the solutions are different, and why the same. That’s the way to develop some wisdom and maturity in the coding part of your professional work.

Some of the respondents asserted that programming languages are tools. If that’s an appropriate metaphor, then how would you answer this question of a wannabe carpenter:

"Should I learn saws or screwdrivers?"

Do you think someone could be a top-flight carpenter knowing only one?

So, stay out of this quasi-religious controversy, which can never be settled. Instead, spend your valuable time learning as many different programming languages as possible, at least 5 or 6. You won’t necessarily use all of them, but knowing their different approaches will put you far above those dullards who say:

“I only know Language X, but it I still think it’s the best language in the world.”

Sunday, February 05, 2017

Fuzz Testing and Fuzz History

In 2016 I added a paragraph to the Wikipedia page on "fuzz testing." Later, the paragraph was edited out because it "lacked reference." The editor, however, suggested that I blog the paragraph and then use the blog as a reference, so the paragraph could be included. So, here's the paragraph:

(Personal recollection from Gerald M. Weinberg) We didn't call it fuzzing back in the 1950s, but it was our standard practice to test programs by inputting decks of punch cards taken from the trash. We also used decks of random number punch cards. We weren't networked in those days, so we weren't much worried about security, but our random/trash decks often turned up undesirable behavior. Every programmer I knew (and there weren't many of us back then, so I knew a great proportion of them) used the trash-deck technique.

The subject of software testing has many myths and distortions. This story of fuzz testing has several morals:

1. This type of testing was so common that it had no name. Apparently, it was giving the name "fuzz testing" around 1988, and the namers were thus given credit in the Wikipedia article for "inventing" the technique.

2. This is just one example of how "history" is created after the fact by human beings, and what they write becomes "facts." That's why I believe there are no such things as "facts"—not in the sense of "truths."

3. In any case, this is one example of why we ought to be wary of labeling "inventors" of various techniques and technologies. For instance, Gutenberg is often labeled the "inventor" of moveable type, though moveable type existed and was widely used long before Gutenberg. Gutenberg used this idea in ways that hadn't been employed before. That was his "invention," and a worthy one it was, but if we're to understand the way technology develops, we have to be more precise in our definition of what was invented and by whom.

Finally, I have no idea who "invented" fuzz testing. It certainly wasn't me.

NOTE: If someone would like to update the fuzz testing article on Wikipedia, they're welcome to reference this blog post.