[00:00:00] SY: Hi CodeNewbies. This interview was recorded before the pandemic and was set to launch for our next season, but we decided to release it early in this season because COBOL has been in the news. States like New Jersey, Kansas, and Connecticut all have unemployment insurance systems that still run on COBOL. And because of COVID-19, they’ve been overwhelmed by the number of pandemic-related job losses and in desperate need of developers who understand the 60-year-old programming language. So here’s our episode on that very language. I hope you enjoy it.

[00:00:38] Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host Saron, and today we’re talking about COBOL with Pete Dashwood, CEO of PRIMA Computing, which helps other companies move off of COBOL.

[00:00:53] PD: If you’re going to be a professional programmer, then please try and get a toolbox that has tools in it, and there’s no reason in the world like COBOL shouldn’t be one of those tools and it isn’t hard for you to learn.

[00:01:06] SY: Pete talks about what it was like to be a programmer working in COBOL in the ’60s, what the programming language is good at and the current state of COBOL after this.

[00:01:23] Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. It also lets you use the most popular open source languages to build web apps. Also, you’re locked in to the service. So why not start building your apps today with Heroku?

[00:01:46] TwilioQuest is a desktop roleplaying game for Mac, Windows, and Linux to teach you real world developer skills. The TwilioQuest Program was created in secret to train an elite group of leaders to combat a shadowy organization known only as the Legacy Systems. Take up the tools of software development, become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:02:14] DigitalOcean offers the most easy to use and developer-friendly cloud platform. It simplifies managing and scaling apps with an intuitive API, multiple storage options, integrated firewalls, load balancers, and more. Get started on DigitalOcean for free with the free $100 credit at DO.co/codenewbie. That’s DO.co/codenewbie.

[00:02:40] When you need to focus on building, do you want to get bogged down by your database? MongoDB is an intuitive, flexible document database that lets you get to building. Mongo DB’s document model is a natural way to represent data so you can focus on what matters. MongoDB Atlas is the best way to use MongoDB. It’s a global cloud database service that gives you all of the developer productivity of MongoDB, plus the added simplicity of a fully managed database service. You can get started free with MongoDB Atlas at mongodb.com/atlas.

[00:03:17] SY: Thanks so much for being here.

[00:03:18] PD: It’s a pleasure.

[00:03:19] SY: So Pete, you’ve been using COBOL for around 50 years. Tell us what COBOL is.

[00:03:25] PD: I certainly have. Yeah. Well, COBOL was one of the earliest of the high-level languages, what we call high level-languages. Back in the old days when we first started in the ’60s, everybody wrote in similar languages. There were no high-level languages, and your people who are learning code, there’ll be learning probably high-level languages like Python or C# or Java. In the early days, we didn’t have that. We had Assembler and it was pretty tough. We wrote in small amounts of memory. So COBOL came along and it stands for Common Business Oriented Language. So primarily, a commercial programming language and it was English-like. The idea of it was that an accountant would be able to read the code and see what it did, even if he wasn’t a programmer. So that was the primary purpose of it.

[00:04:09] SY: Interesting. So how did you get into COBOL?

[00:04:12] PD: Well, back in 1965, I decided that I was going to have a career in computers. I was quite young at the time, very young in fact, and I said I had to do something. And I had a choice between computers or copywriting for an advertising agency. And I decided computers were the coming thing. So I went with that. And I learned IBM Assembler. It was all on mainframes, of course, in those days. There were no PCs as we know them. They were just great big machines. And so I got a job as an operator. It wasn’t easy. I had to apply many, many times and finally somebody picked up my enthusiasm and said, “Okay, you can come and work for us.” So while I was operating the system in the early night shift, I was reading the manuals and teaching myself the Assembler language, and they saw that I was pretty keen. So they put me on a COBOL course in 1967. And that was one of the earliest courses in New Zealand at that time. So that was how I came into COBOL.

[00:05:07] SY: So when you were learning COBOL, paint me a picture of what it actually looked like. What does the code look like visually? What was it like to navigate it? Paint me a picture of it.

[00:05:17] PD: Let’s take a very simple language, like BASIC, that everybody knows. If you have a variable in BASIC, let’s call it X, and you want to assign a value to it, you’d say X equals 10, for example, and then that means I’m assigning this value of 10 to this variable X. Now in COBOL, the same statement would be the English word move space literal 10, 1-0, space TO, space X, and a full stop. So it would say move 10 to X. And you can see it’s quite a lot more verbose than saying X equals 10, which most modern languages do assignment in that way. Because of course in our day when we’re all using Assembler, it was not so easy. It’s not as intuitive as seeing move 10 to X. Whereas if you say move 10 to X and accountant reading, he says, “Oh, it’s got 10 in it.” You know what I mean? It’s English-like. The way they sold it was that it was English-like and it was very funny because there was a magazine at the time called Datamation. That’s long since gone. Datamation was quite famous. It’s published in the US and everybody around the world used to read it, but it had an article about what they really mean. And this was when companies went out for a proposal and they said, “We need a computer system.” So the vendor, which in this case would have been IBM, would send them a proposal and they’d have statements in it, and one of the statements that they might have is, “Using our new high-level COBOL language, programs can now be written in the English language,” Datamation said. And what they really mean is 02 redefines X, Y, Z occurs 47 times, which is a valid COBOL statement, but it’s gibberish. Right? In other words, it wasn’t true. They never really achieved being able to write programs in English as such. But it was still better than Assembler. And when we all had stopped using COBOL, there was a lot of resistance at the time. A lot of us sort of thought, “Why the hell do we have to write all this stuff, this wordy, verbose language? We have to write all this stuff and it takes longer. Why are we doing it when we could do it in Assembler?” But gradually, we started to realize that high-level languages are better than low level ones in terms of debugging and maintenance. And the major costs for any computer installation at that time would have been maintenance of the code. It’s not the development of the code, it’s actually keeping it running. So COBOL, gradually, it became the only game in town. And they did come out with another language, which was called PL1. Well, originally it was PLI, Program Language International, and IBM hoped that everybody would use that, but it never caught on the same. So they called it PL1 and said it was their first shot at it, but they never, ever developed a PL2. COBOL just became the only game in town. And through the late ’60s into the ‘70s, right through to the ’80s, the early ’80s, PCs arrived in about ’83, and up until that time, everything was mainframes and all the programming form was written in COBOL. And along the way, desktops were invented and screens were invented. So now we could actually edit, instead of hitting the punch cards and push the chair back into the cards sometimes, which was very naughty, but we used to do that, we were able to just edit a line on a screen, and that made life a lot easier. So that was COBOL in those days.

[00:08:43] SY: What was it like to learn COBOL? I know you mentioned the course that you took, but I assume Stack Overflow probably wasn’t a thing.

[00:08:51] PD: No.

[00:08:52] SY: Right. So how did you learn? Yeah.

[00:08:54] SY: That’s a very good point you raise there and the fact is that there was no internet, of course, and the idea of actually being able to go online and just get information like now, we can just… if we can’t remember the syntax of a statement, we can Google it. You know, it’s easy. But in those days, no. You had to know the language and you had to use the manual. To answer your question, how did I learn it? Well, we had a two-week course, and to be fair, it was not a hard language to learn. It was pretty easy because it was running on a single processor. It was not networked. Everything was central. There was a central processor. You didn’t have to worry about things like threading. You didn’t have to worry about stuff like that. It was one they called Von-Neumann Model, which is just a sequential procedural language is what it was called. So learning it wasn’t that hard because there were a series of statements. It had verbs and it had nouns. The nouns were actually called data names and they represented variables and the verbs allowed you to do things. It’s like a verb in English. It’s a doing word. You could do things with these variables and the whole language had a structure. It had paragraphs and sentences. So it was very English-like. One of the things during my career, of course, I was required to teach COBOL to quite a few people and nobody really had any trouble learning it. It was pretty easy. It’s not hard, but when PCs arrived and then just a little bit further down the road, we got into object-oriented programming, which was a whole new ballgame. A lot of COBOL people had major trouble with it. They couldn’t get their heads around the idea of objects and they were used to having something and you do this and you do that and you read when you want to read, you open a file, you read it, you close it. That’s how it works. And the idea of having objects in streams was very difficult for a lot of people at that time to pick up. If you take people who are pretty good COBOL programmers and you say, “Look, guys, there’s a whole new wave. It’s a new paradigm has come out that’s aimed at networks and multiple processes where we can flash code around the network and we can load level with it and we can send it to a different processor,” and all these things that we can do today that we just take for granted with our languages. It kind of became a bit overwhelming and a lot of them had trouble with it.

[00:11:03] SY: So you mentioned that you can learn COBOL in two weeks, which is a very, very short amount of time. That’s amazing. How long do you think it would take to be competent enough to actually code in COBOL?

[00:11:15] PD: Well, you could become productive very quickly because it was a simple language. It was pretty easy. You do your two-week course, you’ve learned all the verbs and you’ve seen how to define things and you’ve understood how you can make matrices and tables and stuff like that in it, then you start using it. People learned it quickly and they were able to use it quickly. And I wouldn’t say I’ve taken people off the street and taught them COBOL, like they had no idea at all, but I have taken people from within a business and one day they might be managing a department in a business and the next they’re programming in COBOL. And that was no problem at all because if they understood, they understood the business, they could implement business processes in COBOL pretty easily.

[00:12:00] SY: So at the company that you worked at, where you’re first using COBOL, what kinds of things did you do? What kinds of things did you build?

[00:12:06] PD: Well, the first program I had to work on was a report program. You’ve raised a very good point here because we need to talk about something that a lot of your listeners won’t know anything about, and it’s called batch processing. In those days, when we had a single central processor, we didn’t do all the transactional stuff that’s going on now. You have to remember that we didn’t even have terminals, right? There were no screens. They weren’t invented yet. Everything was punch cards and green line flow for output. So we had listings on paper. And if we put stuff in, it was punched into cards or paper tape. The major applications, as I said, COBOL was intended to be a commercial language. We weren’t going to send men to the moon with COBOL. But commerce is a very big part of life. And if one company gets a computer, they competed and said, “I’ve got to get one,” because no one wants to get left behind. There was a lot of scope for people to become computer programmers. I said it in quotes because they were kind of like amateurs, I suppose, but we all were, myself included. I mean, none of us actually had formal training. You went to IBM and got a two-week course. So coming back to the batch processing, all the transactions had to be saved on files and they will run overnight. Okay? So it means that you had to batch all the transactions from the day that will run in groups of transactions against the master files overnight, and that was a sequential process. It was called batch processing. And I have to say that even today if you’ve got some of the larger US companies, the last sort of best eons of Fortress COBOL are in the US. Most of the rest of the world has moved on from it, but you’ve got huge corporations in the US that do still use COBOL and they use it on mainframes and they use it for batch processing primarily. And for that, COBOL is brilliant. It’s a really, really good language to write batch processing in. It’s excellent. If you’re programming your mainframe and you want to do a whole heap of work, you would use a batch process and COBOL would be the ideal language to write it in.

[00:14:08] SY: So by today’s standards, the idea of batch processing doesn’t necessarily sound like the most exciting thing in the world. And so I’m wondering by standards back then, what was it like?

[00:14:20] PD: Well, you’re absolutely right of course. It isn’t that exciting, but the whole idea of being a computer programmer in those days was pretty good. If you went to a party and people said, “What do you do?” You say, “Oh, I’m a computer programmer.” There was this sort of look of awe because they were just putting men on the moon. It was 1969. You know what I mean? And anything to do with computers, there was sort of a glow around it even though what we actually did was very mundane. And I remember one time being at a party in Oakland and I stopped telling people I was a programmer because I got fed up with it. I didn’t like it. People will say, “What do you do?” And I’ll say, “I’m a postman. What do you do?” Right? But I remember one time being at a party in Oakland and a guy who was a bit more perhaps pompous than I am, in the middle of an argument, he said, “Well, speaking as a computer programmer,” like that gave him an argument from authority, you know, “I must know everything because I’m a computer programmer.” And there was somebody there who just said, “Computer programmer? You’re just the space age plaque.” And I feel about laughing because it was true and this guy obviously knew that.

[00:15:38] SY: TwilioQuest is a desktop roleplaying game for Mac, Windows, and Linux to teach you real world developer skills. Explore the Mysteries of the Pythonic Temple, the JavaScript Test Lab, and more all while learning the tools of software development with TwilioQuest. Become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:16:03] No one wants to manage databases if they can avoid it. That’s why MongoDB made a MongoDB Atlas, a Google cloud database service that runs on AWS, GCP, and Azure. You can deploy a fully managed MongoDB database in minutes with just a few clicks or API calls. MongoDB Atlas automates deployment, updates, scaling, and more so that you can focus on your application instead of taking care of your database. You can get started free at mongodb.com/atlas. If you’re already managing a MongoDB deployment, Atlas has a live migration service so you can migrate it easily and with minimal downtime then get back to what matters. Stop managing your database and start using MongoDB Atlas.

[00:16:52] So let’s switch gears and talk about the state of COBOL today. What is the current state of COBOL? Where do you find it?

[00:16:59] PD: Well, you’ll find it in the US. You’re in the right place. The major banks and the insurance companies and the people that have huge volumes of transactions as I said, they are gradually becoming more networked as the rest of the world has. I started off on COBOL here in New Zealand, but there’s not a single machine in New Zealand now that would run COBOL, not as far as I know, and they haven’t been for like 15 years. So where you would find it at the moment is basically in the US and it’s what I call Fortress COBOL because the people that run the mainframes, they see COBOL as the language. In my opinion, they’re still stuck back in the ’70s and the ’60s. I read an article called “Cretaceous COBOL in Jurassic Java” about the whole thing about how COBOL got overrun, well, the new languages, and how the COBOL people had to hang on, right? And today, you’ll find a lot of people sort of, they’re a bit ashamed about putting COBOL on their CV and they shouldn’t be, or their resumes. I’ve actually spoken with colleagues and people who say, “I hate putting the fact that I’ve got COBOL experience on my CV because people look at me like I’m from the last century.” I mean the 19th century. And I’ve always said, “Look, there’s nothing wrong with writing COBOL and it’s nothing to be ashamed of. It’s a perfectly great language.” But what it does, it’s just been overtaken by different paradigms, the OO Paradigm, the Object Orientation is something that COBOL never had. It was bolted onto it as an afterthought. And by the way, Saron, bolting is one of the major feats of software engineering in the last 50 years, I would say. It was incredible. They actually brought out a vision of OO COBOL. And I have to admit, I use it quite a lot for some of my clients. The first thing we do when we’re migrating them is that we move their old legacy procedural COBOL, we move it into OO COBOL and then we can do stuff with it. We can get it to talk to other things and we can make objects in COBOL and they can be used by other languages and OO COBOL can use other objects. It helps a heck of a lot when you’re trying to migrate and get stuff onto a network. But it is a straight procedural language. And I suppose the way I would look at it, if somebody said to me, “How do you see COBOL now?” I would say, “I see it the way that an English scholar would see Latin.” It’s a useful thing to know, and this is why I’m going to suggest, because it’s CodeNewbie, I would suggest that people do learn COBOL. If you’re planning on being a professional programmer, the idea is that you should have a number of tools in your box. Don’t be a one-trick pony. Don’t just say, “Oh, I’m a Python expert. That’s what I know.” Or, “I’m a Java expert. That’s what I know. That’s enough for me. Everything I want to do, I can do in C#.” No, if you’re a programmer, you should be able to work in scripting languages like JavaScript. You should be able to work in other languages and you should at least have a reading knowledge of it. And in my book, that would include COBOL because you may move on to sites where they’ve still got a lot of COBOL legacy. It’s unbelievable to me. I mean, programs that we wrote back in the ’60s and ’70s are still running in production today on some sites. And you didn’t even know. If you’re going to be a professional programmer, then please try and get a toolbox that has tools in it, and there’s no reason in the world why COBOL shouldn’t be one of those tools and it isn’t hard for you to learn. If you already know a language like Java or Python or one of the modern languages, it’s pretty easy for you to pick up COBOL, much more easy for you to pick up COBOL than it is for a COBOL guy to pick up one of the new languages.

[00:20:39] SY: So you mentioned that New Zealand moved away from COBOL about 15 years ago. I’m wondering what happened 15 years ago that led that to happen?

[00:20:46] PD: It started before that. It started in ’83 when people started getting computers and using them. See, there were a lot of people in the industry at that time. I can remember talking when some of the early attempts home computers came out, you know the Commodore 64 and a lot of people were sort of, “Well, this is fun.” But a lot of my colleagues look down their noses and sort of say, “Oh, these are toys. They just toy computers. They’ll never be able to process all of the inventory control systems that we’ve got using these toys. That’s not going to happen.” And then that was probably true up until about 1990 and then things started to happen because they suddenly found out that by connecting these computers, these tiny little toy computers, they suddenly found out that there was a huge amount of power in a network, that networking stuff, you got, what is it, the sum is greater than its parts. So people started to realize not only that, but these mainframes cost millions of dollars and you could buy a PC for a thousand. You know? So companies were saying, “Well, hang on a minute. In theory, we could hook a thousand of these up and we still wouldn’t have spent a million.” Management are trying to move away from it. And as I said, it’s like Latin would be to an English scholar. It’s something that’s useful to have, but we don’t really want to run our business with it anymore because our business has to be more responsive. If you think about batch processing, most people nowadays, they want to do a transaction on their phone or they want to do it immediately. They use payWave and they wave a card at a device and the transaction happens and it’s online and it happens now, right? And most people want instant response. They don’t want to have to wait until tomorrow to find out what their bank balance is., which they did. In the old days, we will get a monthly statement, right? And at the end of the month, you get a statement. It would show with your transactions and your balance. Nowadays with a few mouse clicks, I can get a statement for any period of time I like. It doesn’t have to be a month. I can look at my balance in real time. If I go to a supermarket and buy something on a credit card, by the time I get home, that credit card balance is updated. This is here in New Zealand. It’s like there’s no delay. Everything is real time online and that seems to work a lot better. So I think that even in the last best eons of Fortress COBOL, I think they will be moving away from those mainframes. I believe within the next 15 years, things will change to the extent where COBOL will no longer really be relevant, but there may be some things that they can do overnight. It might be running like a background task as part of the network, if you see what I mean. It could be attached to the network. It could have access to the network master files, but it would be running them in a different way. And you might still want to use COBOL for that.

[00:23:35] SY: Yeah. So that’s kind of what I was wondering about the value of learning COBOL at this point because I totally get what you mean about COBOL being a dying language, and you think that in 10 15 years, no one’s really going to be using it. But I’m also thinking within that 10 to 15 years, if no one is learning it, but the big banks are still using it, I can see people making a pretty lucrative career out of being one of the few people who know COBOL. Is that legitimate or do you still feel like, “No, it’s better to learn a different language”?

[00:24:03] PD: Well, that’s absolutely legitimate. But ask yourself, if universities are not teaching it, why are they not? It’s because they have a responsibility to the students. If you’re paying huge fees to go to a university, you expect a return on your investment. You expect them to teach you something that will be useful to you to help you make a living, don’t you? I mean, that’s reasonable. And if they’re not doing it, it’s because they believe that there are other things they could teach you that will be more useful that will help you make more money.

[00:24:31] SY: So what kinds of programs do you write in COBOL now?

[00:24:35] PD: I don’t write anything in COBOL now. When I’m dealing with COBOL at somebody else’s COBOL and we’re migrating it for them, I have tools that go through COBOL programs and they’ll analyze the structure of the data and they’ll then generate a relational database from it because normally COBOL deals with flat files and there are things that are indexed files.

[00:24:56] SY: Do you miss writing in COBOL?

[00:24:58] PD: Actually, on the odd occasion when I do have to write something in COBOL, because it needs to be because they’ve only got COBOL. They haven’t got anything else. I kind of enjoy it secretly, but it is a bit like going back in time, and to be honest, when you’re coding it, it’s like wading through treacle. It is a bit like that because as I said to you right at the very beginning, when I say X equals 10, if you have to right move 10 to X, it takes longer. It’s more work and it’s slower. So that’s part of the problem with it. It is too verbose. That’s the problem with COBOL by modern standards, right? Because nowadays, people understand a statement like X equals 10, most people nowadays would know that that’s an assignment because it’s only got one equal sign. So if it was a comparison, it would have two equal signs X equals to 10. It’d have two equal signs. But the point is that nowadays, most people understand it.

[00:26:05] SY: Coming up next, Pete talks about resources people can use if they want to learn COBOL and impart some wisdom from his over 50 years of experience in coding after this. Over nine million apps have been created and ran on Heroku’s cloud service. It scales and grows with you from free apps to enterprise apps, supporting things at enterprise scale. It also manages over two million data stores and makes over 175 add-on services available. Also, make sure to check out their podcast, Code[ish], which explores code, technology, tools, tips, and the life of the developer. Find it at heroku.com/podcast.

[00:26:56] With DigitalOcean’s cloud infrastructure, you’ll be able to build faster and scale easier from predictable pricing to flexible configurations, to world-class customer support. You’ll get access to all the infrastructure services you need to grow. Plus, DigitalOcean’s community provides over 2,000 tutorials to help you stay up to date with the latest open source software, languages and frameworks. Get started on DigitalOcean for free with a free $100 credit at DO.co/codenewbie. That’s DO.co/codenewbie.

[00:27:34] So if people are listening to this episode and they’re still interested in learning and programming in COBOL, do you have any favorite resources that you can point them to?

[00:27:43] PD: I don’t know if there’s any online courses. I have thought that in my retirement, which I’m supposed to be in now, when I had loads and loads of time, I might write an online Teach Yourself COBOL Course, but I haven’t actually got around to it and the need for it is getting less every day. So I probably will never do that. I would suggest that they do a search on Teach Yourself COBOL or something like that. I think Sam’s Teach Yourself COBOL in 24 hours might be good. As I said, it’s not hard to learn. It really is not hard to learn. You can learn it pretty quickly. The problem is that if you go into COBOL, think you’ll then have trouble trying to learn other languages, which are object oriented. It’s a completely different way of working.

[00:28:25] SY: So given that you’ve been programming for a really long time, you’ve had such a great career in coding, do you have any pieces of advice, any words of wisdom to people who were just getting started on their coding journey?

[00:28:37] PD: Take things one step at a time. When you find it’s hard, I read your articles, Saron, where you are trying to teach yourself from the MIT thing and my heart went out to you because I know it is really, really difficult when you first pick it up and a lot of people do give up. So what I would say is to people who are just getting started, first of all, all of the languages were needed by people, right? It’s not from outer space. It’s not alien software. It is doable because somebody did it. And if they did it, then you can do it, but you have to do it in little steps. You take step by step and try to consolidate your knowledge at each level. Don’t get overwhelmed with a massive information about objects and all of the jargon that goes with it. If you can take each of the terms and realize what they mean, just work steadily through what you’re trying to learn. And most of all, write code, try it out, even if you’re not sure what you’re doing. You can’t damage anything, right? Hardware cannot be damaged by software. It’s not going to happen. So if your code is wrong, don’t worry about it. You won’t break the computer. Have a go. And if it’s wrong, try and figure out why it’s wrong and then fix it. And in doing that, you’ll learn a huge amount that you wouldn’t learn formally in a classroom. So my advice would be stay calm, do it step by step, but do it. That’s the three points that I would say to new people.

[00:30:08] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Are you ready to fill in the blanks?

[00:30:15] PD: Okay. Yes.

[00:30:16] SY: Number one, worst advice I’ve ever received is?

[00:30:20] PD: The bottom line here is that you have to learn to think, and unfortunately, these days people don’t seem to learn to think. When I was quite young, I was about 12, I read a book called “Straight and Crooked Thinking” and it kind of changed my mind because it helps you to recognize when you’re being manipulated by people. You will recognize if people have a self-interest. You’ll recognize the flaws in their arguments when you’re debating with them, and it’s just a good idea before you start anything. As a life skill, teach yourself to think, and then when somebody comes along and gives you advice, you’ll be able to evaluate it and maybe you get other opinions on it. Maybe you go on the web and do some searching, but eventually you will evaluate it for yourself. So advice is okay, but you don’t necessarily act on it until you decide for yourself that it’s for you. That’s my answer to that.

[00:31:09] SY: Number two, best advice I’ve ever received is?

[00:31:11] PD: Probably the best advice I was ever given was to slow down. I was driving like a maniac. Well, in my 20s, I wreck cars and I had major accidents and a person whose opinion I respect had said to me, “Pete, slow down. You’re going to kill yourself or you’ll kill someone else.” And because it was him, I took his advice and I went off and learned defensive driving and joined a car club and all those things. And that was very, very good advice. So in that case, slow down is a good advice. Life in general, slow down may not be good advice. But to answer your question, that’s the best single piece of advice I’ve ever been given that I can think of right now.

[00:31:51] SY: Number three, my first coding project was about?

[00:31:54] PD: Yeah. As I mentioned earlier, I had a very, very enlightened boss and he was very sympathetic, and I came off the COBOL course and I thought, “Oh wow, great! I’m going to write some production code,” and he wouldn’t let me. And he was right, of course. But he said, “No, no, no, Peter.” He said, “We’ve got this program. It produces six reports and one of these reports is not right. I want you to have a look at it and see if you can fix it.” And that was the very first job I ever got, and I felt like I’d been taken down a peg or two because I was working on someone else’s code and I wasn’t allowed to write my own. But I realized later, of course, the wisdom and what he did, and he was absolutely right, and I’m glad he did that and I struggled to get that program to work and it took me about three weeks, whereas once I had a bit of experience, I could have done it in two days, but it took me quite a while and there was a lot of trial and error. It’s like I said just now, you have to try stuff. If you’re not sure, then try it and see what happens. And if it doesn’t work, then look at it again and it’s an iterative process. In other words, code evolves. The bottom line is my first job was working on a report program. It took me quite a while to get it to work, but I did get it to work and I got the satisfaction of making it work.

[00:33:07] SY: Number four, one thing I wish I knew when I first started to code is?

[00:33:12] PD: I’m not sure that there’s anything really that would have made a difference. I mean, once you’ve done the course and you’ve learned the language, the rest really is down to you, how you use it, and I don’t know that anybody can say, “Oh, by the way, you need to know this.” I think what you need to do is learn the language and in practice using it. That would be my answer to that.

[00:33:30] SY: Well, thank you so much again for joining us, Pete.

[00:33:33] PD: It’s been nice to meet you.

[00:33:41] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.