Ed Barnard, Author of From Capone to Cray: Where Computers Really Came From

Len: Hi I'm Len Epp from Leanpub, and in this episode of the Frontmatter podcast I'll be interviewing Ed Barnard.

Based in Cannon Falls, Minnesota, Ed is an author and speaker with over 40 years experience in software development, spanning two distinct twenty-year careers, the first being in operating system development, and the second in web software development.

You can follow him on Twitter @ewbarnard and check out his profile on LinkedIn.

Ed is the author of two books currently published on Leanpub, From Capone to Cray: Where Computers Really Came From, and Here Be Dragons: Finding the Joy in Software Development.

In From Capone to Cray, Ed tells the story of the history of computing, through the suprising connection to Prohibition-era rum runners, through the amazing accomplishments of cryptologist Elizebeth Smith Friedman, right on through the role played by the American National Security Agency and Cray Research.

In this interview, we’re going to talk about Ed's background and career, professional interests, his book, and at the end we'll talk about his experience writing and self-publishing.

So, thank you Ed for being on the Leanpub Frontmatter Podcast.

Ed: Thank you.

Len: I always like to start these interviews by asking people for their origin story. So, I was wondering if you could talk a little bit about where you grew up, and how you first found yourself interested in computers and technology?

Ed: Sure. This actually takes place near Seattle. My father, a Korean War vet, took advantage of the VA Bill to go to college after - we're talking the 1950s here. He became an auditor, which I considered extremely boring occupation. But at Safeco Insurance Company, this is the same Safeco that is Safeco Field in Seattle now, for the stadium. But Safeco Insurance Company, based in Seattle, they were - this was early 1960s. They were so impressed with his audit of the data centers, what they called the "back end," the server farm - that they put him in charge of the data center.

For the rest of his life, he was what we would now call the CTO, the Chief Technical Officer. Back then, it was Director of Data Processing, of whatever company it was.

So that meant that I was exposed to mainframe computers from early grade school. It also meant that I was discouraged from - he didn't want to pressure me into following his footsteps.

But I enjoyed playing with computers, and - oh, fourth or fifth grade - mom drove me around to Radio Shack and a few other places, to get some resistors and diodes from a Popular Electronics article. Dad helped me do the soldering, to solder together my first computer. So that's - oh, about 55 years ago now. It's been a while.

I was lucky enough to get a summer school program that taught Boolean algebra. So I learned about AND gates and OR gates and I did follow what was a half adder and then a full adder, and write out the logic gates for those sorts of things. Back then it was - we did actually learn binary arithmetic and base 10 and base 12 and base 60, and so on. That was very commonly done - these were normal things in school. Which, at least in Minnesota, is no longer the case. I've always had computers as a hobby.

The third book that's coming up on Leanpub - the cover is out there - has to do with Mount Rainier. Which is in Washington State. It's important enough to Washington State, that that's what you'll find on their license plates.

Back then - and it's still true now - it's very rare to do a winter climb of Mount Rainier. The weather is - well, back then it was how people prepared for Mount Everest. The weather, it was that severe; same weather now, of course. The standard training ground for Everest expeditions was in the winter on Mount Rainier.

So, that actually formed a large part of my career, the idea of experiential education. Looking back, you wouldn't think that you'd learn software development on a mountain. But I kinda did. That's where - the idea of being outdoors, and a wildness and so on - those also became parts of what actually became software background.

Len: That's really interesting actually. I've got a question about that. What was it specifically about being outdoors and facing that kind of challenge, that translated into being helpful for a career in software?

Ed: A couple of things. One is, the idea of "been there, done that." If you have run marathons, then the idea of having to spend an all-nighter, is not going to bother you that much. You've been exhausted before. You've pushed through things before. But the idea also of taking a physical experience and turning that into something else. Learning to climb a rock face. Learning basic rock climbing or - now, a lot of people do gym climbing. Especially in Minnesota in the winter, do indoor gym climbing, and things like that.

Well, what you're doing is, you're learning to learn. What I found with the software career, is you need to keep learning. Most people have noticed that because the world of computers has changed, and continues to change, there's nothing but change. Part of my way of thinking is, "Okay, what if this next thing is, whatever this next project is, I know that I will need to take some time to learn - something. I'll need to learn a skill or I'll need to learn a concept."

By the way, the idea of ebooks, where I can go and instantly download a book on that topic, and see, "Okay, is this feasible, is that feasible? Is this what I need?" The instant library is very, very handy.

I personally prefer print books. If you were seeing me on video, you'd see - that's my level one cache of books. The library is downstairs. I prefer physical books.

But the electronic form, number one, if you have to throw away thousands of books at a time, you know that having them inside a computer helps.

But, yes, so, it's the idea of transferring a skill. If I have successfully navigated through a wilderness and reached a destination, that gives me a confidence that I can find my way from point A to point B, even if point B is figuring out a network topology. Does that kind of make sense?

Len: It does actually. You're reminding me of an experience I had once, where I was on - I didn't have like the most developed background in being outdoors, but I was the kind of kid who loved summer camp, and liked camping and hiking and stuff like that.

One time I was on a high school hiking trip with the boys from grade 11 and 12. I was behind the pack, enjoying the hike, and being slow for whatever reason. When I got to the site where we were supposed to be making camp for the evening, the two teachers, who didn't know the first thing about being outdoors, were squatting down with all the other kids around them, on a bunch of rocks at the edge of the lake, trying to make a fire.

I remember going, "Oh my God. They don't understand that it's going to get dark. You can't all just sit around, and you don't build a fire that way." They were picking up wood off the ground. And, "You don't do that, because it might be wet," and stuff like that.

Anyway, so I basically had to - it wasn't like I was being proud of myself or anything, there was just no choice. I was like, "Okay, listen guys, here's what's going to happen. You two teachers and these two other guys, you guys are going to build a fire. You're going to do it over there, and you're going to build a little pit first. Then we need every" - four people were staying in each tent. I'm like, "Two people from each tent are going to choose a site and set it up. Don't build it on top of a hill, and don't build it in the bottom of a puddle. The other two guys are going to go collect wood, and you're going to collect that wood by breaking it off the trees." We barely made it, right? If it hadn't been for that, it would've been a nightmare. But I guess I'm just saying that the idea of resonates very strongly with me, the idea that there's these transferrable skills.

Because it's not just the fact that I knew how to do all that stuff, that we needed to divide labor, because winter was coming, as it were. It was like, once you've been through an experience like that, you know that if you end up again in an experience where everybody's doing the wrong thing, and maybe even panicking, you've done it before, and you can go, "Okay I know what this is like. No guarantee that it's all going to work out today. But nonetheless, I've been here before."

Actually, it's interesting, so you ended up studying, I've just seen from your LinkedIn profile, that you ended up studying Computer Science at university. But on your way there, you spent a couple of years at the United States Air Force Academy.

Ed: Yes. In fact it was the cadets, who we grouped together to do the winter climb of Mount Rainier. You talk about goals. Of the six of us, half of us had never been on a glacier before. So, we were going to do a winter expedition climb of Mount Rainier, because we thought, "Well, this is a very serious goal. This is a challenging goal." That's why we took it. That in itself is a story, and that'll be there.

That was in 1977. Forty years later in 2017, I sent a note over to the editor of The Mountaineers magazine. They're like the Sierra Club of Washington State. I said, "Hey would you be interested in a trip from forty years ago? Kind of as a forty year, this is what it was like, kind of thing." I got no response at all. I went, "Okay, well, that happens." It was just a spur of the moment thought.

Almost exactly a year later, I got a note from a different person. They had had a change of editors, and I think somebody went back and swept the missing email. They said, "Yes, why yes. Definitely." We went back and forth, and we were doing the story. Then I said, "But, unfortunately, thanks to a wet basement years ago, I don't have any photos." Their reply, it was very politely worded, but it came back, "Have you seen our magazine? It's color, it's glossy, and it has pictures. No photos, no story." "Yeah, we could maybe go back to - ?"

The people that I hadn't been in contact with since 1981, I went and tried to find those five people. I hadn't been in contact with them. I had a friend who I did know, who was an Academy grad. He gave me the email addresses that might or might not be current. Within hours, I had responses. I had people digging through their basements, dusting off and rescanning, carefully re-delinting, in the literal sense, the 35 millimeter slides, for me.

My first note back was from a woman. Now if you're out in the mountains for eight days on a glacier, you know whether or not there is a woman who was part of your group. I know we did not have any women in our group. We're all teenagers, or late teens, early twenties. She said, "Hi, I'm, I am Randy Nelson's wife. I'm keeping an eye on his email account, because Randy is currently hiking the Pacific Crest Trail from Mexico to Canada, and he's 1,200 miles in." I'm thinking, "No, I know exactly how old these people are." Randy was like 51 at that point. I thought, "Okay, that's pretty cool."

We went back and forth a couple of more times. She sent me a picture of the two of them at Forester Pass, which is 1,300 feet, if I recall right, in the Sierra Nevada, not that far from where you are. She said, "Well, I started out with him, hiking with him. After the first 600 miles, I decided it's not for me."

Now, if a woman is willing to walk 600 miles before deciding it's not for her, she either doesn't make up her mind very well, or she is really awesome. I suspect the latter. But apparently the whole issue was, Randy had really long legs, which I know, and she didn't. You could see the two of them, she comes up to his shoulder. I get it. But, so, she came back home, after only 600 miles, hiking California from the Mojave Desert, and everything else.

But we were so close-knit, and we had done so much together. This is a big part of experiential education, is you don't do it by yourself. The team-building aspect, there's no question, people just did things for me. We compared notes. None of us had ever seen all of the photos together. We were at college, and then they were all Kennedy grads. So, Air Force careers. We compared notes, and found some stories that really can't be published. A funny thing, they all centered around one particular person. And he's the person I did Air Force survival training with, we became known - but that's a different story. That's actually the topic of the fourth manuscript waiting at Leanpub. But I almost got off track there -

Len: Oh no, that's okay. That's really great to hear those stories, and the idea that, I mean, these bonds and these lessons can actually last for decades, and that they can be brought back to the front of mind after all that time, is actually really, really instructive.

You said that a bunch of your colleagues went onto careers in the Air Force. You chose not to. You went to university, as I understand it, and you studied Computer Science. This was at, I think the University of Washington in the late seventies?

Ed: Yes.

Len: Quite a few of the people listening to this podcast, typically, are people who've either done it, or are thinking of doing Computer Science. I was just wondering, I've got a couple of questions, one of which is, just generally, what was it like studying Computer Science at that time? You didn't have the Stack Overflows. There weren't even necessarily all that many magazines to consult, and things like that. What was the typical class like?

Ed: There's actually two pieces to that. At the Air Force Academy, it's not normal for a lowly freshman to be tutoring the upper-classmen. But I could. This was in ALGOL, by the way. Algorithmic language, ALGOL. The bureau's operating system was written in ALGOL. The compiler itself was written in ALGOL. It was a self-compiling compiler, the first time I'd ever seen that concept. Which kind of - I couldn't figure out how that could possibly work, but clearly it did. Then I learned about the idea of bootstrap. But, anyway.

One piece was the weirdness of being the put-upon freshman helping the others. But that also turned out to be the connection that allowed me to find the people forty years later.

At the University of Washington, I really wanted to take an assembly language programming course, which was by the Department of Engineering, where they actually got things done. As opposed to the Department of Computer Science, where they talked about nice theory.

The trouble was, that the prerequisite was Fortran. On paper, I had no Fortran coursework. Yes, I'd been writing Fortan using a keypunch for about six years, at that point. But the professor was very kind. He said, "Okay, how about I give you the final exam for the Fortran class?" I said, "Great." So he did. I took it and handed it back to him. Everything was pencil and paper back then.

This was the summer of 1977, and I was in line registering for something. I heard a couple of people talking back in line. It's college-aged people. They said, "Yeah, I saw that new movie Star Wars." The other guy said, "Yeah, I did too. Yeah, it was okay." That was the end of the conversation. I eventually went and saw Star Wars. But, yes, that was it, "Yeah, it was okay."

Anyway, he never told me how I did on the exam. He simply signed the thing, saying, "Yes, I would be allowed into his class." It so happened that that class gave me my career in supercomputing. To get my job with Cray Research, that one class was the prerequisite. They were looking for people who could do that type of assembly language programming. You never know what it is that's going to happen.

Back then, doing coursework, we typed things up on a keypunch. We handed decks in at the window. Usually within half an hour, you'd get the deck back and some green paper, which was the printout, which, that might be your one chance for the day. S there's a picture loading, okay, you're working on a web page. You get to load the web page once a day. That's your quota. To see if everything looks fine. Sure enough, you'll get to stand in line, and you'll get to do a reload once tomorrow also, to check your changes.

Len: That's interesting, when you mention handing the cards through the window. To extend the analogy you're using, and imagine someone else actually had to type in the code for that web page for you - there was the possibility that they made an error, and there wasn't an error in your instruction. Was that part of the process as well?

Ed: Oh yes. Generally speaking, your errors would be very carefully typed.

Len: Right.

Ed: Thanks to my dad being the data processing manager for the State of Washington, I had access to an IBM mainframe. That department does not exist anymore, and my dad's dead, so we don't need to cut this out. I can tell you that, yes, I hung out with the systems programmers, and read the detailed Principles of Operation manuals, and so on.

But I was also able to hand in pieces of paper, and get them keypunched. Now there, it's a real operation, which means there will be one person who does the keypunching, and a second person who does a verify. The method of what the verify is, you flip the switch on the keypunch machine, and the person types it in a second time. The keypunch verifies that the pattern of holes punched in the card, matches what the person's typing. It's actually literally typed twice. That's how they avoid the errors.

Len: I've got a very detailed question about that. I think probably most of us, whether we've come close to interacting with a machine like that or not, we do have an idea of, maybe from movies or something like that, of these like keypunch cards. What did you actually do to, did you feed it into a slot, into a machine at the end?

Ed: To actually punch the cards, you mean?

Len: No, to feed them into the computer.

Ed: Oh, then later you're going to have a deck of cards, which goes into a card reader. Not that unlike a floppy disc. You would preserve the floppy disc, and it would be stuck into something. Only this time, it's, oh, think of a currency, have you seen a currency counter at a bank?

Len: Yes.

Ed: Where you take the block of, your wad of well laundered cash, hand it across to the teller, and the teller sticks it in this thing, and it goes "d-d-d-d-d-d," to add.

Len: Yeah.

Ed: A punch card reader is very similar. Less sophisticated, but very similar, that's how that worked.

Len: My image was of Tony Montana in Scarface, sitting in that little room, counting all that money. But a similar thing.

Ed: You're not too far off. By the way, if you only get access to a keypunch person once or twice a week, how do you correct errors? I did get a stack of blank punch cards. I used an X-Acto knife, and it actually worked.

Len: Oh wow.

Ed: I carved my edits.

Len: That's fascinating.

Ed: It actually worked.

Len: It's so interesting to think about the literally tactile relationship to the way that the instructions are being fed into the computer, in that direct way, is so interesting.

Ed: There's actually a lesson there for today. Which is, back then, computer hardware was so slow, that the weakest link, the most expensive resource, was computer time. Not programmer time.

Now we want the programmers to be more efficient. We did all sorts of weird things, and took all sorts of programmer time to allow for the fact - insane optimizations that, why in the world would you do that, to save one - ? Because you're going to save five seconds every day of the week. That's worth it. The paradigm in that sense, as in, what is the most scarce resource? Has very much changed. That's a big difference. Go ahead.

Len: Speaking of lessons for today and things that have changed, this leads me to a question that often comes up on this podcast in one form or another. Which is, if you were starting out brand new in a career in Computer Science or software engineering today, with all the resources that we have available and the really fast computers and things like that, would you do a formal university degree? Or would you maybe try and find a way of doing things more independently?

Ed: That's a really good question. Of course, it's still around, there's a board game, Life. In the board game, you had the option of a tradesman's degree, or a computer degree. So, which is - exactly that strategy. Is the degree going to be worth it, or is getting the genuine tradesman going to be worth it? I still see the question is similar to that.

But one thing I hugely recommend, would be a liberal arts degree. My son is now a professor of Computer Science. He passed his doctoral studies, he only has the dissertation left. I've heard that's actually not trivial, but -

Len: No.

Ed: It was so fun doing - with his masters, I got to help him with his homework. Me, the college dropout, which I thought was pretty awesome.

There are formal things, and formal ways of thinking about things, that I did learn in Computer Science, that still serve very well. There's a degree of background or education that will be a gap if you don't get it.

But at the same time, is the book-learning really worth it? Because college tuition has gotten so expensive that the 1970s go-to-college model, is different from the 2020s go-to-college model. I'm not even sure I could give a relevant answer, except in terms of computer -

Okay, software development is a people business. I am not a people person. I do not want to be a people person. I do much better dealing with computers. But it is those skills that - they're the necessary parts. Well, okay, you liked climbing a mountain, but if you can't build a fire there, you're not going to like climbing the mountain. You need to be able to build a fire too. That's why the real arts degree, it's the breadth of skills.

My son has a History degree, but he is a professor of Computer Science in North Dakota. By the way, he and his friend, when they were students there, they were driving the department head nuts, because they had hacking pretentions, and so they would do things to the professor on screen as he was trying to do a lecture. That same person is now his department head. It came full circle.

Len: I personally couldn't agree with you more about the - I mean, if you've got the temperament for it, and you've got the ability to do it, the liberal arts undergraduate years are extremely practical in the long run. Even though they might not appear to be so in the short run. Anyone who listens to this podcast regularly knows that I got an English doctorate, and then I became an investment banker. That is not as unusual as it often seems to people. Henry Paulson, the former Goldman Sachs CEO, and Secretary of the Treasury, I think? He got an English degree for his undergrad. These things are not as rare as they seem, and there's utility and certain types of education that might not be apparent, until you have it. That's the classic kind of ancient paradox about those kinds of learning. It's interesting,

Ed: I think you're exactly right. Yeah. That's the same concept that I mean with experiential education.

Your career might have been outdoors. Well, you didn't learn to build a fire on the first try. You can have the expectation, "Oh, to learn a new skill I might have to practice." Because of the experience, whether it has to do with how to add two numbers in a spreadsheet. Well, you expect to have to learn, or expect to have to practice. The cross-coupling is super valuable, I think.

Len: You just reminded me of something else along these lines. Which is, sometimes people complain about, "I learned something, but it was a waste of time, because I never used it." Using your analogy of doing, well not analogy, your example of outdoors stuff, and how that can be helpful, for example, when, if you're climbing a difficult mountain, if it's winter, if it's nighttime - or I guess if you're training the Air Force, what happens if you get captured. Things like that. When you've been faced with a circumstance, where, if you hadn't figured something else out in advance by trying it numerous times, you would've been in terrible trouble - you lose that idea that, "Just because I never used something, it was never useful to me."

You can think of an example being like, if you ski a lot, and, in the back country, you wouldn't complain that you never got to use your avalanche training, if you never got in an avalanche, right? You'd be like, "Thank goodness I did that avalanche training, even though I never had to use it. Because if it had ever happened, it would've come in pretty handy."

Thinking about the way you're using the term, "experiential," there's kind of technical way that it's often used in universities, about getting a job. But what you're talking about is much, much deeper than that, and fascinating to me.

Before we move on, I was thinking about how to structure this, because typically the way we do these things, is we talk about a person's kind of progression through their career, and then we talk about their book or books. But the point we've gotten to, where you're talking about your career, comes in midway through the book.

Ed: Yes.

Len: We'd kind of be crossing streams if we did that. So, before we move on to talking about your book, I actually wanted to, just leap ahead. I mentioned in the introduction, and you talk about this in various places in your profiles online and stuff, about how, after twenty years in your first career, which we're skipping, I guess we'll get to it later - you then embarked on a new one. I was wondering if you could talk about that change in careers, and why you made that decision?

Ed: Yes. It seemed like a good idea at the time. Turned out it wasn't. But it seemed like a good idea at the time.

My first career primarily is simply language programming. That's actually a chapter in the first book. We eventually got demoted to where we actually had to write C programming. We were dealing with a UNIX operating system., writing device drivers inside UNIX, alongside the current developers. Except for what we were doing was still on bare-metal. That's how we considered ourselves demoted. We were totally full of ourselves, in other words. But what that meant was, I had experience with UNIX-type operations. This is the late 1990s, where the web is becoming a thing, so web servers are becoming a thing.

Very quick side story - so this is when we were owned by Silicon Graphics, SGI. With the servers, there were maintenance contracts where you have this service level. We would be on site to fix or patch whatever it is, within two hours, within four hours, within three days, whatever it is. There was a call from a site known as "Danni's Hard Drive." D-A-N-N-I, Danni's Hard Drive. Many people have heard of that operation.

There was a hole in the operating system which was exploited, so that they could get in, a pay site, so you can get inside the pay site. Naturally that was broadcast all over. It was Usenet back then. So our headquarters said, "Oh, we'll be right over." Because they said, "No, wait till tomorrow. This is the best traffic we've ever had." Anyway, but, the server manufacturers, what was not said out loud, was, the leading edge, and most of the UNIX-based servers, were porn servers. That's what the leading edge was, late 1990s, early 2000s, that time frame.

Meanwhile then, people coming into the industry, meaning coming out of high school, and/or, primarily high school, they considered themselves computer experts, they grew up with computers. Well, if there is a problem with a Windows computer, what you do is you reboot it. By this point with production UNIX servers, that was generally not considered the right answer. The fact that I could get in as root and make edits, make changes, do things safely, without taking the server down, was a skill that was relatively unusual.

Because back then, people flooding the market from high school, didn't have the UNIX background. They had the Windows-based background. Likewise, they didn't have the hard knocks from the aerospace companies saying, "Ah, no, you will not take this down again now, will you?"

So, basically I tried to build my own little consulting company. What I didn't know, was, I was riding the top peak of the dotcom boom, straight into the ground. 2000, 2001, and so on.

When 9/11 happened, that affected the airline companies - I'm sorry, the aircraft manufacturers. Because the airline companies stopped buying aircraft. Well, the aircraft companies were one of our major customers. We were supplying Cray Computers to the aircraft manufacturers. That was stopping - end of September, meaning two weeks after 9/11, Cray Research did a layoff. At the same time, the US was doing a lot of job protection, in the sense of extending unemployment benefits and so on.

Meanwhile, because I had been with Cray Research so long, I got the very, very top tier of the - basically I got nine months’ pay. I said, "Hey," I was already trying to do this company off on the side. I said, "I wouldn't mind if you put me on the list and save somebody else, and I'll take the layoff." And so I did.

I had my nine months. It took a year for me to figure out that, no, the bills were not getting paid. Nobody else was getting paid, and they weren't paying me.

I tried to work my way back into the job market. At that point, I had no relevant experience on a resume, period. I am literally trying to start my way back into a different job market. I said, "Scripting languages, piece of cake." I was enjoying that actually. IBM was doing a supercomputer project. The IBM Blue Gene system, that was 45 minutes away, just down the road from me, where they're doing it. The IBM Rochester site, in Minnesota.

So, I hired on as a technical writer. I went from bare-metal operating system programming, to technical writing, working my way back into the job market. I found that I was having fun with the scripting languages. The fact that I knew a thing or two about UNIX, because I had written some of it - that background has continued to pay very, very well. People talk about packets exploding across the network. Well, yeah, I used to write drivers that sent those packets across a network. So, you never know when useless knowledge is going to turn out to be useful again, or just give you a background or an orientation.

Another thing, you mentioned avalanches. In the outdoors, sometimes a crisis will happen. You take a hard spill on your skis. Or, yeah, you're down the slope forty feet, but your other ski is still forty feet back up the slope. How are you going to get it? But more often, when a crisis happens, like, "It's getting dark, and we don't have a fire yet," it's a group crisis. Have you ever run across an IT operation that has had a crisis happen to them?

Len: Yes.

Ed: It's a transferrable skill. How do you work with the people who are hip-deep in it with you? The fact that you have successfully navigated a crisis - I'm a huge fan of the Isaac Asimov's Foundation series. In a Seldon crisis, they will figure out the external part and the internal part. Well, if you know the nature of a Seldon crisis, and you can look over there and say, "Gee, you guys reacted like this to a Seldon crisis, then, I know this piece, I know that piece. This type of crisis, the most important thing we can do is have a conversation with upper management. Let them know what is happening. Because we have dealt with a crisis before."

Again, it's a transferrable skill. That's a large part of what my writing is aimed at, is trying to help people think of the transferrable skill.

Len: Thank you very much for that, you gave me the, what I always call, "the greatest gift a podcast guest can give," which is an opportunity for a segue, which is to writing.

You got this job with IBM, writing. You've just brought up that writing is very important to you, partly for this reason of telling these stories, that have these transferable skills in them. I know that you've written for PHP Architect and things like that. Was it around this time at around the time of the turn of the century, that you began writing? Or had you been writing all along?

Ed: There was a person who did a keynote talk at the first conference that I went to. This would be like 2015, 2016? 2016, I think? Five going on six years ago. Basically, they explained the importance of other people sharing their knowledge by doing the conference talk. This was PHP-specific. But, again, it was the general concept. And, I had taught software before. Actual platform teaching. My wife's a teacher, my mom was a teacher, my son is a teacher. I didn't see that as a problem.

But also, I found out, there was a group of people willing to mentor would-be speakers. And, "Give us your abstract that you're going to present as your offer to do a talk, and we'll take a look at, we're conference organizers, we'll take a look at it."

My very first one, I offered it, and I said, "I've never spoken in a conference before. But in a former life, I did teach operating system internals in a similar language for Cray Research." I got some very good feedback, which finished with, "Oh, by the way, you could do a conference talk on pretty much anything you want to talk about, about Cray Research. What it was. Or lessons learned, and so on."

And, huh, a year later, I did. I thought, "Well, okay, this is what it was like programming a Cray-1 Supercomputer," which many people had heard of, but very few had actually - with a show of hands, I never encountered anyone who had ever actually done any work on a Cray-1 itself. From a person who I respect very, very highly, very knowledgeable, he did an amazing talk on the theory behind Alan Turing's famous first paper and the Entscheidungsproblem. He said, "That talk was over my head."

That's when it hit me, "Oh, people don't know how to do it," I asked around. "Nobody knows how to do binary arithmetic." I knew people didn't use slide rules anymore, but binary arithmetic, nobody can do binary arithmetic? What do they think that a network mask is? Oh that's the net mask. But shifting or masking or doing an AND versus an OR, or extracting pieces because you masked it, these are - well, I learned that in fourth grade. So, what I had was a blind spot, a complete blind spot. Then I started doing conference talks on teaching this.

What I did was, I took a piece of PHP software, so it's open source. That, for constant time and create encoding, and said, "We're going to walk through these four lines of code. And that means we need to learn 1s complement and 2s complement. We're going to do integer arithmetic in 2s complement. But we're also going to do some shifting, which is 1s complement." This was very heavy going for people. This was a new and alien concept. I'm thinking, "Well, this is fourth grade stuff." People are saying, "Well, no, that's not HTML, that's not how we do things."

Nobody saw the relevance. It took me a very, very long time to begin to finally come back to the relevance, which is detecting the - one example is the coding interviews that people do, that a lot of people have a really hard time with. But then very few people have no trouble at all, because they're trivial. I've been doing them with interviews, including at IBM, for, as an IBM programmer. "Gee, we never had anyone who could actually do this before." "Well, gee, you're shifting by 2 bits. It's not - it's easy."

I wrote the book trying to explain my thought process, and this different way of thinking, which was more, for fans of Apollo 13, it's a lot of what Apollo 13 people would've been putting on the chalk board.

But then the other part of that was, I realized, yes, I kept running across a lot of interest in Cray Research. Either the mystique of Seymour Cray himself, or supercomputing, or just Cray's position in that. I realized nobody ever wrote a book. They did for the hardware side, but nobody ever wrote a book from the software side.

I thought, "Well you know, I am not the best person to write that book, but I'm willing to write it." So I did. It was awful. Then I rewrote it a couple of times, and I finally put it into three books.

You have read book number one, From Capone to Cray. So, connecting the dots.

Book number two is intentionally intense, it's what in the 1980s we considered perfectly normal. But it's not anymore. In trying to teach lost skills, to some extent - but also the idea of getting practiced learning, learning to learn.

And also share some of the stories before they're gone. My generation is retiring out of the workforce, if they can. Or they're still here writing code, hoping to make a million dollars from Leanpub.

Len: We hope they do. Thanks very much for sharing that story, the origin of the book Capone to Cray but also the other books that were part of the original big project.

Just so everyone knows, I mentioned the second one in the introduction, but it's called Here Be Dragons, and it's available on Leanpub. Then, the third one, which you've talked about a couple of times already, is called Surviving Spring Break on the Mountain which isn't out yet.

One of the things I wanted to try and frame, when we now start talking about the story that you tell in, From Capone to Cray, is what a serious business computing is. There's a couple of specific examples of that. It's sort like, as it were, computing adjacent, or even prior to computing, these ways of thinking are.

For a lot of people who may have caught it, like when you talked about being taught computing-related stuff in school, I think that might've surprised a lot of people, right? Who hear like, "Oh, should kids be taught programming school nowadays?" They might think that the idea that people should learn things like that in school, might be a kind of post-mid-90s web, Silicon Valley tech billionaire boom kind of question.

But there are these epochs of interest in computing, and one of them happened around the time of the second world war, and that's a big ball of things, one of which is calculating trajectories on ships at sea. Another one of which is nuclear bombs.

But even prior to that, there was cryptography and breaking codes, which was very important in the second world war. But prior to that, of course as well, which is where we'll be going in a moment, when I'll be asking you to tell some of the stories briefly that you tell so well in the book -

But then there was even the subsequent period shortly after the second world war, and in historical terms, when all of a sudden there was a cold war with a competing. A very sophisticated and powerful country, with a competing world view to that of the United States - they were both nuclear-armed, they were enemies, and someone was getting to space first. That was the Russians, not the Americans. In this period of time, let's say like kind of mid-century, computing did seem mysterious to people, to some extent.

There were images of big rooms full of machinery you can't see inside of, and stuff like that. But there was a very on-the-ground sense, that this was a fight, and there was going to be one winner. You talk about that in the book, when some people might ask, "Why would you spend all that time?" For example, you mentioned optimizing things to get the extra five seconds out. It's like, "Well, when the stakes are nuclear war, people have a lot of incentives to spend a lot of time doing those in-the-moment boring things."

So, with that context said, there's this super interesting origin, where you start telling this story. Which is with Al Capone and rum-running. So, I was wondering if you could tell us how that's relevant, as the beginning of the story of the development of computers in the United States?

Ed: I sure could. I'm going to interrupt myself twice first though.

One is exactly like you said. When we're in the midst of a cold war, and we might actually be helping save this country from a nuclear fallout. That means that what you're doing is important. When you're doing what is important, it really doesn't matter if it might objectively be boring or not.

With the Cray-1 talks, people asked, "Why would anyone do that?" It really wasn't like that at all. That's part of what I wanted to portray, is, literally it's the title. "Finding the Joy in Software Development." To me, it's in learning and it's in finding importance.

My second interruption is, true story, at Cray Research, when we shipped software, we also shipped the math library. Part of the math library was a math library called "Fast Fourier Transforms." The FFT Library. There were export controls. We could not export that library to certain other countries. The word on the grapevine inside the company, was, the reason was, the Fast Fourier Transforms were used for calculating cannonball trajectories during the US Civil War in the 1860s, and they were still on an export restriction.

Len: Oh wow.

Ed: Go figure.

Len: Yeah.

Ed: Okay. I have friends who grew up in Chicago. I hear stories about Chicago. Of course, the essence of Chicago is Al Capone, and/or Mayor Daley. Which was effectively a - there's Mayor Daley Senior and Mayor Daley Junior. Effectively it was a hereditary thing at that point.

But what's not so obvious is O'Hare Airport. Everyone's heard of O'Hare. But O'Hare Airport was named after a guy, O'Hare, that's true. But [his father] Eddie O'Hare was Al Capone's mouthpiece, Al Capone's lawyer. So, that's the connection to O'Hare Airport, almost. Almost.

Len: Yeah, it's the "almost," exactly.

Ed: What happened was, O'Hare senior, Fast Eddie O'Hare, someone, he grew up in St. Louis. Of course, Charles Lindbergh was flying out of St. Louis. Charles Lindbergh's from Central Minnesota, where there's a Minnesota connection also.

So O'Hare was growing up in St. Louis. He was a lawyer. There was this guy who basically patented greyhound racing. What he patented was the rabbit on a stick that runs around the track, and all the greyhounds chase it around the track. They were making all sorts of money.

This will be before prohibition, the 1920s, if I recall right? The guy died. O'Hare went to the widow and purchased the patent rights for this greyhound racing invention. He wanted to take it to Chicago.

Well, the boss of Chicago is Al Capone. He went straight to the top, and became partners with Al Capone. They buttoned up the race tracks with this invention. They made millions. Then of course, prohibition happened and so, the liquor aspect happened also.

Eventually, we all know that Al Capone went down for tax evasion. A highlight of the trial was Al Capone's bookkeeper. But another highlight of the trial was Eddie O'Hare, his lawyer. Now, the lawyer's part could've been kept secret, but historian's speculate -

It became a highlight of the trial, that the guy who betrayed Al Capone was his lawyer, Eddie O'Hare. At the same time, his son Butch O'Hare, was applying to become a cadet at the Naval Academy in Annapolis. Well, in the 1930s, you're not going to let somebody into Annapolis, who is associated with Al Capone. They want heroes at Annapolis, not monsters.

So, there's a lot of speculation, but no proof, that I know of, that his betrayal of Al Capone, was to portray him as a good guy, while Annapolis was considering the son's becoming a cadet at Annapolis.

He was admitted. He did graduate, became an ensign and became a pilot. He already knew how to fly, because he few with Lindbergh on some of the mail routes, and so on. In 1942 in the Pacific, off an aircraft carrier, the son, O'Hare, Butch O'Hare - the carrier, the battle group was being attacked by Japanese medium bombers. This is after Pearl Harbor.

One thing bombers are very, very good at is dropping bombs on battleships and aircraft carriers. They tend to sink when that happens. Well, most of them had already been destroyed in Pearl Harbor anyway.

At this point, the US Navy was basically being kicked all over the Pacific Ocean. This has nothing to do with what was going on with the convoys in the Atlantic, of course, this is the Pacific. This was early 1942, Pearl Harbor having happened the previous December. Things were not going well.

There's a lot of circumstances, it's in the book - Butch O'Hara singlehandedly [shot down] five or six, and chased off the nine Betty Japanese bombers, basically saving the entire aircraft carrier. This was all within sight of the carrier, they were that close. He only received one bullet hole, it hit his airstream indicator, so that didn't help very much. At that time, he only had about 30 seconds of ammunition to use. He then was awarded the Medal of Honor by President Roosevelt, and he was the first naval aviator ever to receive the Medal of Honor.

What in the world does that have to do with codebreaking? Well, as it happens, Al Capone was a rum runner. The rum runners used encrypted communications. This was shortwave, radio transmissions, anyone with a shortwave stack could pick up the transmission. It was dots and dashes, but it was encrypted dots and dashes. These were picked up by the Coast Guard. It was the US Coast Guard that was tasked with foreign alcohol coming in. The big pipeline was Detroit. Windsor, Detroit from Canada, Because it was perfectly legal in Canada. It's a short trip across the river to Detroit. That was a major pipeline.

But meanwhile, then, there were all these encrypted communications that nobody could break. They went and talked to this guy, he was in military intelligence. He was a cryptographer for General Pershing in World War One. Had run a cryptography school, and, in fact, he eventually would be the founding cryptographer of the ASA. I mean this, he was an important guy. Very knowledgeable. He said, "No, I'm in the Army. I'm not interested, I want to keep my Army career."

They talked to his wife. Which kind of sounds dumb on the face of it. Best move they could've made. She, in about, I believe it was six weeks, doing pencil and paper decryption by hand, broke the codes. She cleared out the entire backlog in about six weeks. Hundreds of different ciphers. As, I, believe the contractor for the Coast Guard at that point. Just the wife. The husband was the famous cryptographer. There's strong speculation at this point, that it was actually the wife that got the husband interested in cryptography. So, some very interesting things going on there.

But it turned out that when World War II broke out, the Coast Guard would hear communications, like from the Germans, over the shortwave.

They were the same types of codes, the same approaches. Coming, in many cases, from the same radio stations. I mean, base stations. Same geographic, the same transmitters, is what I'm trying to say here.

Eventually I think it became eleven people? This little tiny Coast Guard group, actually broke the Enigma by hand. They thought that was very, very difficult, it took them like six months to break it. Now, nobody else ever - but, yeah, she broke Enigma with pencil and paper, by hand. How she did it is actually available online now. It was originally a highly classified document.

It was actually the rum runners, their encrypted communications, that became the route to gaining the skill with production crypto, if you will? Which is just really odd. So, that's why I call it From Capone to Cray, with Elizebeth Friedman being the connection then to William Friedman, who was the founding cryptographer, for what became the NSA.

Another side note is, the National Security Agency was created so that all this cryptography stuff would be taken out of the military. The NSA was created to be outside the military chain of command. This was the first time. The Coast Guard is military. The Army signal service, the signal intelligence focus, all that was military. The Navy had the group also. The NSA was outside the military, right after they got their charter and began to come into existence, except nobody knew it. It became clear that the Russians had the bomb.

That changed everything, in terms of the NSA's mission. So, because atomic weapons, those were military capability - the NSA, again, became very, very closely tied, like six months later. But the way the NSA charter originally was, is kind of a weird story in itself. But that's the story, that's why I connect Al Capone to Seymour Cray, who, back, beginning with - yeah, I kind of skipped a step there.

During World War II, in the US Navy, there were a bunch of cryptographers. Now, these were both mechanical engineers, who would build, physically build things with vacuum tubes, and so on. Then, mathematicians who were doing theory and actually creating, programming computers, and so on.

The Army effort became the ILLIAC computer. The Navy effort remained top secret. They quietly formed a company, a top-secret company in St. Paul, Minnesota. They took over a glider factory that had been making gliders for the World War II effort. Well, the war was over. Nobody else wanted the gliders.

He had an empty factory. They made it a Naval place. They had Naval security there. That's where the first programmable, I should say, the first stored program computers were made, were right here in Minnesota. The University of Minnesota, of course, is just down the road. The University of Minnesota provided the entire 1951 electro-engineering class, virtually all of them got hired on by this secret company - including a guy named Seymour Cray, who had worked as a code clerk.

Just totally coincidentally, in the Army, he did Army service during World War II. But he did the G.I. Bill, and he took college after his World War II service, as many G.I.s did. He became a college graduate, and went to work for this top-secret company.

As we know from security clearances these days, if he worked as a code clerk in, obviously, in the US Army, during World War II, chances are, he had some clearance. Getting re-cleared, I would think would be an easy thing. That's just reading between the lines. But that's where Seymour Cray started. Then became the father of supercomputing.

Len: Thank you very much for sharing that. That was just fascinating to listen to. I mean, this is the book I've been reading, and now I get to hear the person telling the story in audio, as it were, in person. That was so great.

One thing I want to really thank you for, is for capturing so well the nature of your approach to telling these stories in the book, drawing connections between these,

Ed: Thank you.

Len: I really mean it. These inherently interesting stories that have these, to some extent - some of the connections drawn are kind of tangential, but they're all very meaningful and interesting. The idea that, for example, people would've - probably a lot of people would've known, oh, O'Hare International Airport was named after the Medal of Honor winner, who fought off these Japanese bombers, became the first Navy pilot to win a Medal of Honor. He ended up getting lost in action, and this was very tragic. The airport was named after him.

But then there's this connection to his father and to Al Capone. Putting together that connection between the fact that it was made public, that The father had spilled the beans on Al Capone about the same time that the son was applying for Annapolis, is just so interesting.

That, and the way that you told everything else too, really captures the beautiful way you bring these connections together.

Ed: You have just described debugging. Making connections that nobody else notices. For me, that is the art of debugging, and that's why I do this in the books.

It's a technique that I call "finding patterns in the noise." You note something that's just a little bit odd, that nobody else has noted, and you start digging. You come up with the goods.

That is a skill that I don't know how to teach. But if you can get it, it's really valuable. That's why the connections is - it's the most basic skill you have in software development.

Len: Thank you very much for making that explicit, that's very important. It's interesting too, because it goes towards explaining partly - and this is just my reading of it - but like, you'll be much better at it, if you inherently enjoy going down the path, not knowing where it's going to take you. Not knowing where that it's necessarily going to take you anywhere.

That's one of the really interesting things about how the book is structured. Because one thing you do at the beginning of the chapter, the sections, is you show these various paths with these mind maps, and things like that. To give the reader some knowledge in advance - it's like, "We're going to be going down all these paths. I can show you visually how they all kind of fit together." It's very interesting -

Ed: In fact, no,

Len: Oh -

Ed: That was an experiment on my part.

Len: That helped, very particularly, in the sense that it gives the reader an understanding that you've got an approach, and that what they're being presented with is not random. That it does fit together.

I don't know if this is intentional, but it also has the kind of curious effect of looking a little bit like those like those typical things in like a cop show, where there's a bulletin board, and they've got pictures up, and people are drawing these connections.

Ed: Well, yeah.

Len: There's a very fun element to it, that it visually invokes that.

Thank you so much for going into so much depth on that one chapter. I really wish I could just have you recount the entire rest of the book that way. But we want people to buy and read the book, and also we've got time constraints.

But one thing I wanted to mention before we go on to talk a little bit about Cray Research and your work there and what happened, I do want to call attention to - you were talking about Elizebeth Smith Friedman there. There's this great book, which you talk about a couple of times in the book, called, The Woman Who Smashed Codes, by a journalist called Jason Fagone. I hope I get his name right, because I follow him on Twitter.

Ed: You did, you're exactly right. It's right over there. If you could see me, yes it's right over there. He's on Twitter. Very personable. I believe he's based in San Francisco, as a matter of fact, as a journalist.

Len: Yeah, I think he is. And, again, I only know from Twitter, and I don't know why I would've followed him years ago, it was before he published the book. But anyway, it's The Woman Who Smashed Codes. It's not on Leanpub, but buy it anywhere you can find it.

It's a really interesting thing. There's like all these cool things about her. Even in the end, her and her husband have a shared gravestone at Arlington Cemetery if - they both served in the military independently, so they could've had their own individual gravestones. But he died first, and she decided they'd have a shared one.

But she hid a cryptographic message in the gravestone, in the words, "Knowledge is power," by alternating serif and non-serif fonts for the letters. It was only when someone who kind of knew a little bit about this kind of stuff, noticed the odd switching of the fonts, and just independently put it together, that it was discovered like 20 years later. I mean, the idea of Elizebeth Friedman putting together this secret message on her and her husband's gravestone, and telling no one about it, is just -

Ed: It is the most awesome thing.

Len: Yeah. It's amazing. It tells you something about the like - another feature of her career is how secret a lot of it was, and how held back a lot of it was. Not, then, that's complicated by the fact that a lot of what she was doing was spy stuff. But there is a bit of drama to the idea that her husband became this very famous person. There she was - her husband became a very well-known person in the circles in which people like that are very well known. Her work wasn't necessarily so well understood. The fact that this book eventually comes out after all kinds of stuff is released, it is just fascinating.

Anyway, but you brought us to Cray. The background, a little bit. One thing I wanted to ask you about - so, we've been talking about a lot of technical stuff, which is very important. But companies don't just come around because of brilliant inventors, a lot of other things have to happen sometimes. You've got this great line in your book, where you talk about, "The legendary Cray-1 supercomputer came to be built because of the legends, and not the other way around."

Which is a brilliant line. If it hadn't been for the legends, sometimes perhaps carefully cultivated, it might've been difficult to get the funding for the work that was done. It might've been difficult to get the company off the ground. It might've been difficult to get the first computer built and delivered to it's first customer. What are one or two of the legends of Cray Research?

Ed: Well, let's see.

Len: I know that's a broad question.

Ed: Yes. Okay, ones that I observed personally are in the book anyway. Let's start with Boeing Aircraft Company. This would be around June of 1980. This was Cray-1 serial number 20. Now at the time, Cray Research was making, I believe that year, they actually got up to a dozen, making a dozen mainframes. But it had been four, five, six mainframes per year. When Cray himself founded the company, they thought there was a market for maybe two dozen mainframes.

Well, okay, so this was talking about making five or six mainframes, this was not a startup plan, that was the entire plan, that's a ten-year plan. These were all made by hand. 60 miles of twisted pair wire go into each mainframe. In fact, if there's a wiring problem, a wire mat problem, what they needed to do, was they actually sent a full or a partial wiring crew from manufacturing headquarters, Chippewa Falls, Wisconsin.

They would send the wiring ladies over to wherever the site is. Could be Japan. Could be around the world. Those ladies were considered so valuable, we're talking 1970s and 80s at this point. Well 80s, yeah, back in the 80s, really. The crew was split across two aircraft. We're talking the 747s. But the crew's split across two airport, aircraft, in case one of those planes went down. Sometimes I've heard about this with executives or boards. But, no, Cray did this with the wiring ladies. They were that much of a company asset.

At Boeing, we've got this Cray-1 mainframe coming along. This is where the Boeing B-29 Superfortress bombers were made for World War II. This is the old World War II-era manufacturing building, at the south end of lake Washington in Seattle. By the way, yes, there are a number of World War II aircraft at the bottom of Lake Washington. The word on the street was that the 737s, now basically 737 MAX these days, also, that were built there - the runway was short enough so the plane could take off, but it was too short for it to land. When that pilot takes off the brakes, he has committed. He is headed straight for Lake Washington, and he needs to get off that runway. Because he's not going to be turning back. Now there are - Seatac Airport is not that far away, and so on. But, yeah, they had to be pretty confident when they took the plane off that runway.

Anyway, so as you can imagine, Boeing Aircraft Company has some really good forklift operators. You have to. If you've got a million dollar fuselage, you want the crane operator to not be putting dings into the fuselage by swinging it around or something. So, the cargo truck backed up, and there's this Cray-1 mainframe, four or five tons on one loading pallet. A Cray-1 arrival is always a big deal. They were like Vice-President level people. The suits were there in attendance. Of course, the Cray people were there.

We were standing around, and we were wearing suits also, because we'd been warned. We could hear a forklift in the distance. The pallet was there, we could see the mainframe, we could see the pallet, and we could hear this forklift off in the distance, this large manufacturing area outside. "errrrrrr." Then, it comes around the corner, and it suddenly went "errrrr." Oh, down to very sedate procession. Because of course, suits were there.

Len: Right.

Ed: This was going to be a responsible forklift operator who crept his way over, and lifted up, picked up the pallet off the back of a truck, and then, obviously, very, very carefully - but obviously they got one of their best people. They got it down near the ground, and turned around, and headed to the building where it was going to be. However, Seattle does have rain. That's still true. Seattle does still rain sometimes. There is a Seattle rain festival, that is celebrated September through May. The general saying is, "We don't tan, we rust."

But Seattle does have rain. The walkways between buildings have awnings. They're covered walkways. Well, this was a heavy mainframe for a pallet. This was a big forklift. The top part of the forklift would not fit under the awning. He's stuck outside. We stand around for a while longer, and then we hear these two forklifts off in the distance, "errrrrrrrrrrr."

They come around the corner and saw the suits. We now have this pair of forklifts, smaller forklifts, sedately approaching us. They loaded this ten-million-dollar pallet, one on each side of the pallet. The forklifts were facing each other with the pallet in-between them. They pick up this ten-million-dollar top-heavy cylinder, monolith-type cylinder, several tons. Pick it up. One's going backwards, one's going forward, to take it underneath the awning, With all the suits watching.

Len: Wow.

Ed: They got it to the other side of the awning, sat it very carefully down on the ground, and got the hell out of there. Meanwhile, the big forklift has done the circuit all the way around the building, a large manufacturing building. He's now on the other side of the awning. Picks it up, and takes it to the door where it's going to be wheeled in. It all worked. Nothing fell. Nothing fell over. We have this little hand forklift, like you see at the box stores, Costco or whatever. It's a forklift that's on a handle. We called it a "come-along."

We wheeled it down the Hollywood 1940s-style tiled hallways, to where the machine room is. Well, machine rooms require cooling, and require electricity. And there's no subfloor. What they did, is they built it up, a foot and a half up. There's this cube, like a fishbowl room, basically, with a raised floor. So, the left one, it's got a big picture of [?] on two sides, and they left a ramp over the door, with a hole for the door. Then they're just going to nail it in. The computer's going to be there permanently.

With this come-along, we got this four and a half ton thing up the ramp. At the top of the ramp, it turned out the door way was high enough if the mainframe had been level. It was tilted, so it was a quarter inch too short. Well, none of us felt - four guys are not going to pick up a four and a half ton mainframe to get it level, and watch it tip over onto the floor, with the suits watching. We weren't going to stand around at the top of the ramp holding it, while people decide what to do.

We got it going back down the ramp. No, we didn't want it falling off the ramp. There was no guardrail here. We stood around. The suits made some phone calls. It's a union shop, the carpenters came in, made it high enough, that we then were able to get the mainframe in. But the semblance of math, measure once, cut twice, it just didn't quite go as planned. But it did eventually happen. That was the arrival of the Cray mainframe. That was my first Cray-1.

Len: That's a really great story. Especially setting again, as I brought up, really - the stakes are actually really high with things like this, at this period of time as well. There was a lot riding on that for all the people involved.

It reminds me of just one brief story that you tell in the book, that I wanted to talk about. Which is, just having to do with the creativity and resourcefulness that it takes to get big projects like these through. There was this one point, I think it was for the very first Cray supercomputer, when these two labs, Los Alamos and Livermore were competing -

Ed: Yes.

Len: They both wanted it, and they were both willing to pay enough for it. But they were capable of preventing the other one from getting it. There was all this money invested in the company, to build this supercomputer, and to build more in the future. But they couldn't sell their first one, because neither of the first two customers would let the other one have it.

There's a financing element to these companies. If they were relying on the sale of this first huge product, to be able to finance ongoing operations, not being able to sell it was actually a potentially catastrophic problem. I love the fact that Seymour Cray, and presumably his team, came up with the solution of giving it to one of the two competitors for free.

Ed: You're missing a point.

Len: Okay.

Ed: An important point. You're missing it, because it's not in the book.

Len: Oh, okay.

Ed: That is, the government labs needed bragging rights. How are they going to recruit the best of the best? It's through the bragging rights. Seymour Cray was well-established at this point. Supercomputers only existed to control data, at this point. We got the serial number 1 of the newest product, why don't you come work for us and not for the other guys? The recruiting aspect was bragging rights. That had as much to do with funding as anything else.

So, this had to do with the labs' very existence. This was part of how the labs did business. Anyway, so go ahead, yes.

Len: That's so fascinating. I assumed there was something along those lines, that had to do with reputation or even projects they had planned, or something like that. Thank you very much for filling in that detail. It's so important to know those kind of things, to explain like what was at stake, right? It's like, it could damage the future of their institution, and competing with each other - just the final detail that you recount in the book about that, is that, he couldn't just go and give it away, right? He needed the money.

The idea was that - the excuse, as it were, for pulling this off, was, "Oh, you'll get to have it for free for six months, so you can test it and you can see if it all works as promised. Then at that point, you can decide whether to buy it or not to buy it."

First of all, he gets it out the door. But it also means that after six months, they've agreed to make a decision whether to buy it or not, which then gets rid of the whole problem of the competition with the other lab. Because either they'll buy it, or the other lab will. It was an absolutely brilliant way of solving a non-computer problem, but that had everything to do with what was going to come next.

On that note, actually, I think we should probably switch to the last part of the interview, now that we've talked enough, and you've been talking enough, that's for sure. I say that as having maybe not been as economical with your time as I should've been.

But in the last part of the interview, if the guest is a Leanpub author, we like to ask them to talk a little bit about their process of writing, and how they got their book up, and things like that.

I was wondering if you could talk a little bit about how you wrote the book? We've actually talked about it a little bit already, but I guess I mean in the technical sense. Did you use Word and then do something else?

Ed: First for the philosophical aspect, real quick, which was, it was iterative. I wrote things, and then realized that nobody had any idea of what I was talking about. I wrote more. Then I finally realized, "This is such a convoluted path, I'm not sure I can even draw a map." That's where the mind maps came from.

Ed: It was to show the connections. Because they were obvious to me, but boy they were not obvious to anybody else. Then I realized, "Oh, my way of thinking is different from a lot of other people." It's just, What do you select for? So, "If that's the case, then maybe what I can be doing is trying to better explain my way of thinking." But that's like describing the color blue to people that have a blue/red color blindness. Well, it's a lot like red, right?

Len: Right.

Ed: Okay. Literally, from the writing standpoint, with the company I work for, we got hit by a brute force hack attempt, trying to find our passwords. I offered a magazine article to PHP Architect, but then shortly thereafter, the boss and I went to a PHP Architect conference. The editor was there, and said, "I never heard back, are you interested?" The guy standing there talked to the editor on the phone, and he found it in his spam filter.

Five minutes later, it was a "yes," and it became a three-part article. By the way, the first line was, "Learn from the enemy." I call that super, super important. It's not from the horrible movie, but the book, Ender's Game, by Orson Scott Card. I forget the main guy towards the end of the book that taught Ender - he was explaining to Ender that, "You will lose, but you will win, because you will learn from the enemy. You will learn how to beat the enemy, because the enemy will teach you how."

To me, that's a software development skill, that's why, before I talk about, "Chased By The Bad Guys," originally I was going to title it "Chased By The Bad Guys, How I Learned Software Development." I kind of changed my mind on that. But "being chased by the bad guys" gives me some insight for software development. Especially if you're dealing with websites. Because sometimes websites do have not nice people stop by.

Len: Yes.

Ed: I've heard Bitcoin exchanges have that too. Today's topic, yeah, so in the news.

Okay, so, I began doing articles, which became conference talks. Which then, talking with other people at conferences, became articles, and so on. And so it's kind of a synergistic back-and-forth. Both from the standpoint of teaching. "What can I share?" I also found that I had kind of a unique perspective.

I could - well basically, I'm weird. I could put a weird perspective on things. People come away from my talks shaking their head, but also having learned something.

But the editor for the magazine wanted articles submitted in Markdown format.

Len: Got you.

Ed: Well, I can do HTML, I can do PHP, I can do assembly language, but my goodness, now I have to do Markdown. Well, you just start typing, and when you come to the end of a paragraph, you hit return twice. "Okay, I guess I've got that one figured out."

But I also wrote my own post-processing system for trying to do a manuscript, and so on. When I came across Markua, that it had already solved those problems rather more elegantly than I had on my own anyway, this became my workflow, and I'm so glad of this.

I actually used Scrivener for my original typing. I used Scrivener, because I don't do outlines. I don't do mind maps, strangely enough. I give myself a couple of bullet points, and then I start typing. I'm unusual. I'm very much a linear thinker. I can type an article straight through, and other than very minor rewording of a sentence, I don't change things around. It just flows straight through.

But for something that's book size, I want to be able to rearrange things. Scrivener makes it very easy. What I do is, every head becomes a separate little document inside that hashtag title, in other words, a level two head. I make each one a piece, and that makes it real easy for me to move this around or copy it, or this and that. All my content editing, and by that I mean, rearranging, I do in Scrivener.

Then I do a dump into my text editor. I use phpstorm - as a PHP person, I'm so close to the text anyway -which has perfectly good support for Markdown files.

Then there is a tool for the Mac, I'm on a Mac. Now, I'm on a Mac, because it runs UNIX. Not Linux. I grew up on UNIX. I didn't do Linux. But I do do UNIX. I've kept that. And, yeah, I don't do Windows. Windows and I don't do very well.

But, anyway, there's a program called Marked 2. Ironically enough, the author, the guy who wrote it is half a mile down the river from me.

Len: Oh wow.

Ed: It just so happens that he's a Minnesota person. Anyway, so it is a Markdown viewer. Which means what that does, is it does a better job of showing me listings in place, and showing me images in place, than the straight text that I would have in the editor.

Part of the reason for that is, I tended to have them separate over, because Scrivener does not play well with images inside the flow. Anyway, so Scrivener and my IDE, which is phpstorm. Then, as a viewer, I will often have Marked 2 going also.

I've tried various things for flowchart type things, but I'm also finding, a co-worker of mine - he has shown me that he communicates with himself very, very well with mind maps. I realized from what he was saying, and exactly what you said, criminal minds, the strings between the dead people's pictures on the corkboard in the background - the mind maps that are showing the relationships between the topics. I realized that, because I'm here, there and everywhere, I'm trying to show connections that I can actually - I'm actually helping the material.

When I read somebody else's book that's highly detailed - right in front of me is Domain-Driven Design by Eric Evans. It's holding up the laptop at the moment, which means I'm not reading it. I don't look at his listings, I read his descriptions of the listings. I'm very, very text oriented. I can glance at it, I can see it. One language - I've seen a lot of code in fifty years - it's the author's thinking that I'm looking for.

But if I'm going to write a book, sure enough, it helps if I put some pictures in there, or some images or some graphics, or some way to break it up. Because most, well all normal people, are going to be much more visually-oriented than I am. That also, by the way, means I don't do podcasts and I don't do videos, sorry, but I do books.

Len: Well, thank you very much for sharing that actually. It's funny, I always like to say to people, we save the technical approach that each particular author takes towards their writing and their processes to end. But there actually are people who skip to that part, which is interesting. Because they're so interested in - just for anyone listening, there were a lot of technical terms in there, like Markdown and Markua, and things like that. If you didn't get them all, that's fine, we'll have links to explain all these things in the transcript.

Ed: Perfect.

Len: Hopefully we'll catch them all. But, yeah - it's so interesting hearing about people's different approaches to writing. One thing I've found in interviewing people over the years, is that a lot of people who are into programming, really love to come up with the ideal process, and love trying out different tools all the time. They really like hearing those stories. The one thing I would add to it is, just because I only learned about it on Saturday - have you heard of draw.io?

Ed: No, tell me about it.

Len: If you're a diagramming person - I was going to say "diagramming nerd" - if you're really into it, I haven't used it a lot yet, but like it is just amazing. You can just click "Create New Diagram," and it's just in the browser. It's amazing. There's an app that you can get as well for it, that you can download.

Ed: I continue to search for something like that, yes. I really need it for one of the books that's not - well it's what I call "Book Five." It's up there, but it's not available yet. I really need some diagrams.

My favorite thing, I still had a copy of Windows 7, that I boot as a virtual thing on my Mac. I have Windows 7, because there is a flowcharting tool that is the very best. By the way, my boss still has a plastic flowcharting template.

Len: Oh wow.

Ed: For actual pen and ink. Still. He's no Navy chief. My boss and I get along.

Len: I bet, yeah. But anyway, no, I'll share a link to that in the transcription as well.

The last question we always like to ask when the guest is a Leanpub author, is, if there was one magical feature we could build for you, or if there was one bug or terribly annoying thing or problem that you've encountered with Leanpub, can you think of anything that you would ask us to do?

Ed: Yes. If there were an easy or easier way of getting feedback.

Len: Right.

Ed: If I put something up on Amazon, which I haven't - but if I put something up on Amazon, I get the dreaded book reviews. Worse yet, I'd get zero book reviews. But that would be the big thing, is, well, in fact, the founder or co-founder, I'm not sure which, Bill Pollock of No Starch Press, said, "The most critical thing is getting that feedback while you're writing the book." I have split, resplit, restructured, sorted. I literally threw out over 100,000 words. I just plain yanked it out, threw it on the floor, and eventually put it back in as the separate book, as pieces of three different books, based on discussion of - but still, just like any kind of iterative release process with any kind of software, if there's a way to get some - well, I'm not sure how to get feedback from my books. I can put a blurb in, say, "Contact me on Twitter," or this and that. But if there was a simple process like Amazon has for getting reviews or that thing, that I think would be golden to the people who are trying to be craftsmen.

Len: Thanks very much for sharing that. We do hear that from authors from time to time. That we don't - particularly that we don't have reviews, is something that we are going to have someday. The whole Lean Publishing idea is kind of based on getting feedback. "Publish early, publish often" is our motto.

The fact that this is actually something that we don't have something more worked on, is an area where we know we need to do a lot of improvement. It is kind of funny that we haven't gone there yet. We will. But we have, from the beginning, though - there is an "email the author" feature on the landing page for a book, that people can use. We point them to that, when we're contacted by people who have questions or find it just in our Help Center documents, or just find it on the page.

A lot of authors do what you do, which is, they put a section at the beginning of the book with their email address. It might be a dedicated per-book email address, or something like that, saying, "Contact me."

Actually email has been the way that a lot of people have done it. It's a bit ad hoc. But especially if you're early on in a project, it doesn't need to be all that systematic. We have had one or two authors who've told us stories of like staying up all night and coding their own feedback system, and stuff like that, so people do that sometimes as well.

But having that feedback in the form of reviews - also feedback more in the form of like just contact the author and give them comments. We do have that through email, that can be double blind, by the way. They don't need to give you their email address - I don't need to give them theirs, if they use that form. Although at that point, people do like to share emails anyway.

But, yeah, there's a couple of things like that that we do. But something systematic around feedback. if someone could go, like could choose page number, and had a little field and say, "Here's the typo," or whatever, something like that, that's more systematic, is definitely something that we do want to do one day.

Ed: I have a second comment, if that's okay?

Len: Oh yes, definitely.

Ed: Yes. I am extremely pleased with how easy it is to build and produce good looking books. That's a huge, huge, huge plus, is the system that is there, and it is in place,

But the other side of that, is, it's not real clear to me, Well, okay, once the book is 100% complete, does that mean I should go away and take it somewhere else? Because Leanpub says, "Well, we're aimed at works in progress." Well, okay, does that mean I'm allowed to stick around and sell books that are complete?" I'm not sure. There's a little bit of a blind spot there, in that sense. It's not obvious to me that,

Okay, right now, a conversation going on - because I've got six manuscripts that I'm trying to get, COVID happened, by the way. I've got this log jam. I'm thinking, "Well, okay, do I try to get one to completion, and then take it over and put it on Kindle with Amazon? Or should I try to get all six up, complete and for sale on Leanpub, and then look at trying to move the one over?"

By the way, I'm convinced that getting all six available, partly for the feedback aspect, is - but then the other question is, "Well, gee, can I sell finished books on Leanpub?" It's hard to find a spot where Leanpub says, "Well, yeah, we're here."

Len: Thank you very much for sharing that. Us getting to know that that's what people are thinking, or what they're not thinking, is actually like some of the best feedback we can possibly get. Because we know what - anybody who works on any product or whatever, project, you know what it is - it can be very hard to know that people aren't getting the message that you wish they would.

And, yes, Leanpub is very much a place where you can publish completed, finished books.

The typical process that we try and give people when they're using Leanpub to publish in progress, like, "I've got three chapters, I'm going to publish it, and then I'm going to publish it chapter by chapter, get feedback, change stuff as I go along." Typically what we say, is, "When you're 'done, done', when you're 100% done, now you've got a decision to make. Do you want to keep selling it on Leanpub? Do you want to keep selling it on Leanpub and elsewhere? Do you want to stop selling it on Leanpub, and only sell it elsewhere?" Those are the questions that you need to ask yourself when you're done. But Leanpub is definitely a platform for finished books, it's not just for books that are still in progress.

It took us longer to do this than it should have, but we have an upload workflow, which is for - the idea wasn't so much for finished books, it was, there were a lot of authors who were like, "I've got my own workflow set up for creating ebook files, but I can't use Leanpub, because I'm not using your writing process. Why don't you just let me use my own tools, and upload the files that I've created myself?" We do have that now.

What that means, is, and here's a sales pitch - if you've got a finished ebook that you own the rights to, you can upload it on Leanpub and be earning 80% off every sale in like 20 minutes.

Ed: Ooh.

Len: We've got an article about that, about like setting up a book and using our upload writing mode.

That's more royalties than you're probably going to earn anywhere else, that isn't basically kind of self-hosting or some version of that. So, yes, like Leanpub definitely is a place for finished ebooks. We'll definitely try and get better about our messaging about that.

Ed: What you just said, that little section where you answered my question, if that was a separate video, I sure would've watched it. Because I was looking for it. So, yeah, share that with the authors. I might've been looking in the wrong place, but it wasn't self-evident. A lot of people do videos, so just take that little tiny slice of a minute and a half, or whatever it was, and, yeah, that was very useful.

Len: Okay.

Ed: Thank you.

Len: Thanks very much. Well we'll definitely think about how to do that.

Well, Ed, thank you very much for taking so much time out of your day, I really appreciate it. It's been almost two hours now. Thanks for sharing all those great stories, and the motivation behind telling them. And thank you very much for using Leanpub as a platform to write and publish your books.

Ed: It has been so easy. It has been such a relief to use Leanpub. It's really been nice. I sure appreciate that you found me, and you read my book, I appreciate that too.

Len: It was great fun.

Ed: Thank you. I should mention, we got up to forty degrees here today, so I am in t-shirt and shorts.

Len: Oh my.

Ed: Yes we haven't been above freezing for a while, and so this was great. Thank you. I sure appreciate the opportunity.

Len: Thanks very much.

As always, thanks to all of you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review it wherever you found it, and if you'd like to be a Leanpub author, please visit our website at leanpub.com.