John McKeague is an experienced automation developer with a large arsenal of tools and technology under his belt. In this episode, he explains how he went from being an astrophysicist to becoming an automation developer.
This is the raw essence of a 2-hour conversation on a variety of things, including:
- RPA with all its benefits and drawbacks
- More advanced forms of automation involving machine learning
- How to get started with automation
I am really glad that we got the opportunity to connect and I want to give a shout-out to the wonderful website and community www.indiehackers.com where we met in the first place.
You can connect with John through LinkedInResources:
Arne: [00:00:04] Hey guys, welcome to the first real episode of automation masters. I'm super excited about my first guest, John McKeague, and I'm hoping that I'm pronouncing that right. John is an astrophysicist by education, who then went on to become an automation developer. He has worked on a bunch of different projects and I think that you will quickly see that he absolutely knows what he's talking about.
We ended up talking for over two hours, but since nobody goes to the gym or commutes for that long, especially right now, I brought it down to the absolute essence. We are speaking about his journey from astrophysics into automation, the benefits and drawbacks on conventional RPA tools, the impact on people's work content and a bunch of other things.
John also shares a few tips on how to get started in the field, and you can find a bunch of links in the show notes of this episode.
Hey, John, good to have you on the show.
Why don't you tell us a little bit about yourself, maybe your background and how you got into the field of automation in the first place.
John: [00:01:07] Yeah, of course. And so at the minute, I'm currently working as a, well mainly RPA developer with a company called the robotics change and based in Belfast, Northern Ireland. And so it's kind of an interesting story how I got into the field, because I don't really know how I got into the field, which I think was true for a lot of developers.
And so for me, it started at university probably in my final year project. I started doing a lot of machine learning and data and analytics. I started physics. So after I graduated, I joined the company, Ernst & Young , again, based in Belfast as a data analyst. And when that, and when I joined that position, what I assumed would be able to give them data sets, I would find patterns in the data set and visualize the data and stuff like that.
But I was actually then moved into the RPA team. We used Blue Prism to automate a lot of, eh, a lot of processes, mainly within sort of like government sector, like healthcare was a big one. And, and the NHS [National Health Service] and stuff like that. And it was mostly be as the roadmap, financial, well, sorry, me personally, it was mostly based around financial processes.
And then I left EY and I joined the current company, The Robot Exchange, and again, working instead of Blue Prism and we use UI Path at this company. But my skillset was kind of unique in that I could program in Pythonand .NET and just, you know, sort of like a higher, this was a higher level of complexity. So a lot of what I do know is actually building extra functionality for UI Path or a sort of even change cut out UI Path completely an automated workloads without this RPA software, just using the .NET or Python and Selenium, if you've ever heard of it.
So that's, that's kind of where I might know. ,
Arne: [00:02:56] I also thought it was interesting what you studied in particular, and maybe to repeat this as again, you have studied physics and astrophysics and then making the leap into a, into automation, into RPA - that was a striking to me at least.
John: [00:03:12] Yeah. Yeah, it's a, it's strange. So I, I just love physics and massive nerd for stuff like that, and especially astrophysics. So I choose to do that at university. And if I'm being completely honest, about halfway through I realized that God, this really hard, I'm not sure I'm actually very good at physics, but what it was good at once the the program side off it, so it was Korean simulations, the data analysis and preparation and visualization.
when I went into my final year project, it was studying dust: spectral analysis of dust from comets, which a lot of people laugh at cause my, my project was on dust, but essentially what we were doing was trying to figure out what was the comet made off, what was its size and shape, et cetera.
And there was no machine gun and actually involved in it. And then I just decided, because I was interested in it, they just asked my project advisor, you know, I have two weeks left. Do you mind if I just try a little bit of something extra just to see if I can get extra marks? So what I did was I tested a lot of different methods using Python on the scikit-learn library.
And essentially it was trying to figure out, is there a machine learning way to predict a lot of these data points when you have less information. So you know less about the comment of the comments further away, for example, and you'd have less data points: Can you try and make predictions based on previously examined comments and things like that?
And I just find it so interesting. So when I left university, I knew that I didn't want to do a PhD. I knew I wanted to do data analysis and programming, and when I joined EY, I was doing data analysis and then they kind of noticed that I was very good at Python .
So they moved me into the RPA team, and basically I was doing a lot of the automation, so when I was in the healthcare world for the healthcare client, I would automate a lot of the financial sort of spreadsheets that they would use for accruals and, and you know, predictions of what next month and it kind of, I suppose, helped me make a name for myself to automate things outside the functionality of typical RPA products like Blue Prism, while also I was still using Blue Prism. That's the main sort of automation platform. But then topping it up with this extra functionality, which allowed us to take on a lot of air.
A lot of new clients, and I suppose I kind of, you know, in a weird way, fell in love with it because it reminds me of physics in the sense that you have a problem and you need to break the problem down into the logical small steps that you can sort of achieve.
You know? Literally, you can actually program, you know, and figure out how to automate that. And it's, I don't actually know how to explain it a bit, cause I, I don't understand it myself, but a lot of the skills I learned at university are definitely, definitely applicable in the workforce.
Arne: [00:06:06] Right, applicable. But, I hope they are not the, the one condition in order to be successful in this field, right?
John: [00:06:13] Oh, absolutely not.
Arne: [00:06:14] We are going to talk about that a little bit later.
could you take us through a project of yours?
John: [00:06:19] A project of mine? I'll use the healthcare finance ones. So what the, the process was was that this was a hospital based in England. was that each month, they had, a finance team and they would their download spreadsheets from all the different departments in the hospital of different costs that were encouraged or in that particular month and it was all sort of joined together into one spreadsheet and then they would do a little bit of sort of predictive analysis on, eh, how much, you know, the total cost of running the hospital essentially was at that particular month. And then try to sort of use the business of that then to predict what the total running cost would be next month so they can have the money prepared.
I believe that's what an accrual is, but I'm not entirely sure. So what I had to do was, firstly, use Blue Prism to gather all the data, get all the data that we need it to start the process, and then essentially just based on on the requirements of the client, you know, picking the correct pieces of data, building pivot tables, taking the data from the pivot tables and ended different pivot tables.
And then, you know, there's all the different Excel formulas and stuff like that. And essentially the output was the final a spreadsheet. And it was, it was actually the reason I picked it was because it was probably the most complex process I've ever done. Quite proud of myself though. It was even through it and up until I actually left, before the process went live, but it was done.
So I don't, to this day, don't really know what, what happened after that. It was still being used, but it was just a good example of. A somewhat complex process for to automate, but it's probably relatively simple for a human to do, but it just takes so much time. you know, This guy would spend, I think it was something like half of the month preparing the spreadsheet.
And then, and there and the second half of the month, you would have to then try to like finish all the rest of his jobs that he had to do. So when that, this is all automated, he didn't have to fill this and that anymore. So he freed up so much of his time to work on things, you know, that are human-based, you know, that only really humans can do a complex, sort of like human-based logic and stuff like that.
so I think it's just a good example of a process, you know. And I hope this is the way RPA is going in general, where you're not replacing the person, you're freeing up the menial tasks to leave them with the free time they need to innovate and work on harder, complex human tasks.
Arne: [00:08:56] Yeah. Yeah, definitely. no, I, I think this is a great example and, it's, it's this archetype of somebody really pulling together data from different sources. And they're not really putting intelligence into it, like human intelligence or interpretation or analysis really. But it is simply plugging in numbers.
John: [00:09:18] Yeah, definitely. I think there was a, it's another important aspect to RPA as well, that you know, this, this process I'm talking about, it's a good example. When you go to automate a process in generally in my opinion though, this is an absolute fact. You shouldn't automate that the way that the person does it.
Because the way a person can achieve a result is generally vastly different than the way you can achieve a programmatically. So a human, for instance, you know, if they give you the requirements for the process, and there are copying data from one lactam, maybe say 10 spreadsheets, a lot of the time what they'll do is they'll bring off an that sort of blank, that Excel spreadsheet, and copy it all into that intermittent spreadsheet.
that. A robot can hold that all in it's memory. So what you need to do, I think, is it's going look at the process and then change the process, essentially like streamline that make it better because, because of that reason lasted.
And also because a lot of people inherit processes from the people who did it before them. and then, you know, three generations down the lane, there's things people are doing that they don't know why they're doing it that way. That's just the way they've been taught to do it. And they don't question it when in reality, probably half of what they're doing isn't really necessary to automate because it can be achieved in a more streamlined, quicker fashion.
So there has to be a lot off. I personally, I think the hospital a lot of sort of review of the process to, you know, if you, if you automate about process, you know, the robots just going to do it by job. You know, you need to automate good processes.
Arne: [00:10:54] And how did you do that in this project that you were speaking about?
John: [00:10:58] Yeah. So, and the one of the examples I'll just give you know, was if a user is copying data, they may put it into a sort of intermittent spreadsheet and then take it all from there and put it into the main spreadsheet. So like I said, a robot doesn't need to be. Or a robot doesn't have to do that. And another part of the same process was when they were calculating all the, you know, financial accruals and stuff like that, there would be addresses of the different departments within the hospital.
And you know, this guy who, who, who did the process, he couldn't remember all the separate addresses. So what he would do is he would just Google, you know, the address and say, Oh, that's, you know, this hospital. Okay, cool. Eh, but rather than. Eh, rather than building the robot to, you know, open up from Google, the address we just find an API, you know, I think it cost 5 pounds a month that you put in a postcode and on a, or you've just put in the address essentially, and it returns the name of the company or the host or whatever details you need to do with that address.
And, and you know, it's, it's just a much more streamline, faster, better way of doing things, in my opinion. And, you know, then just copying what a human would do, which would be go on to Chrome and Google it, you know, API isn't my favorite thing in the world because if you can find an API for something, I will use it every single time because don't reinvent the wheel.
Arne: [00:12:22] Can you explain that to your, to your grandmother? What an what an API as please.
John: [00:12:29] An API. So I don't know the strict definition of it, but to me, an API would be a sort of a, an application that you can interfere, eh, without a user. So you can access without a user interface and you will send a get request and that will give you back. Eh, whatever. It depends what the API does, but it will give you back data based on that request.
Arne: [00:12:53] Okay. So there was a little bit of a detour into APIs and I know that you are excited about that. but, I just wanted to make sure that, everybody in the audience also knows what, what, you were talking about here. And I also think it's, it's great that this technology is, expanding so rapidly, and I'm probably , going to do several episodes on just this matter.
So, You guys out there. Stay tuned.
But I wanted to get back again to your project that you were talking about because I think it's, it's a really cool case and it's the sad thing is that this happens over and over and over again. It's so many different companies, people essentially taking information from different sources, pulling that together in, for instance, a spreadsheet or a presentation, and then delivering this to either a different application or to their management. But it, it keeps repeating over and over again. And I think this is, this is a really, a place where RPA can be of tremendous value.
John: [00:14:01] Yes. Yeah, definitely. So I know we're going to sort of touch upon the intelligent process automation as well later on. But that's one of the main benefits of RPA I see, is that it, when it comes to simple tasks, it's very, very good. I'm using these drag and drop workflows, that UI path and Blue Prism means that the entry level or the, the barrier is very low compared to, you know, pure programming.
So what I would. Like to see in the future is that anybody in any sort of company is able to use these work flow tools to automate the simple processes. And that's kind of like a tool in their back pocket. You know? So I could be, maybe not me as an example, but somebody could be working and you know, say the NHS and they see a process that they have to do every NHS. This is exactly what they need. Cause overheads are massive. It's under threat, you know, it's just the way they do . thing. They need to upskill their workers on how to these pretty simple tools because that worker could then say okay, well this is something that I'm doing all the time and I've seen a lot of my time, but I know know how to use Blue Prism, or I know know how to use you UI Path.
I'm just going to automate that. the onus should be on the individual, you know, who owns the process to do the RPA in the future. Hopefully when, when things sort of stabilize, I think when the industry stabilizes a bit more, and then people such as ourselves would then look at automating the more complex costs because once a robot goes live that, you know, it's like a child that has to be looked after.
Arne: [00:15:39] it sounds like this is possible just from a user standpoint that they could in fact maintain and, and watch that a child doing, doing work on their behalf. Is that true or is that, something that is. In the brochures of these companies selling the software, but in reality, it's not really, fit for that purpose, meaning that you would have to have a developer really looking into these things.
John: [00:16:06] No, I definitely think that's a reasonable thing to expect because this software isn't particularly hard. It should be the company that has the process that needs to be automated, should have their inhouse staff. Do you know our robot isn't going to replace your job. It should be like a personal assistant. It should do the jobs for you that you don't want to do. Allowing you to focus on things that you do want to do. I think a good example that I heard, I'm stealing this from a colleague of mine, but. I don't know in Germany if they're called the same thing, but Marimba is like a little robot that I remember in primary school over put in the floor where, and you press an arrow up three times and then left once and it would kind of follow that path.
You know? That's like a physical example of the software that RPA is. You press up three times and go left and then go up again and down one, you know, it does exactly what you tell it to do. And in that set of instructions, but I couldn't tell Marimba, okay, now go to the shop and get me some milk. It's not smart. It just does what you tell it to do.
Arne: [00:17:09] I think this is the major frustration that you're getting when, or those you have when you're getting into code, right?
You start learning that the machine is doing exactly what you tell it to do. And that's, that can be frustrating at times, right? Because a, it turns out computers are not that smart. And, I, I think it's a, yeah, it's a perfect analogy, for, for what you just said, on, on the RPA side. Now before the show, when we spoke, what I, what I really liked was your image of RPA being used as a, as a plaster. Can you expand a little bit on that one?
John: [00:17:45] Yeah. So it's just a fairly simple analogy at that. If, if it up, RPA is just putting a plaster over a problem, you know, it's not there to fix the problem longterm. It's supposed to be a short term solution. So then you can kind of say, right, well that's going to go do that process now for the next two or three months, and I can focus on actually building a better, more reliable way of fixing that problem.
I think. The plaster analogy can came over from, you know, you can use a, you don't use a plaster on an amputated as like, you know, if it doesn't fix the problem, you know, the bondage it up and I'll stop bleeding. But you still have to address the whole problem. You know, you can't just leave it like that cause it's just going to cause more problems down the lane.
For example. you know, if, if a, a software update to the, the interface, all the UI elements have changed. Well, no, your robot's got a break. And you don't want to have to come back every three months to fix that problem. that affects the robots. So what you should do is just use the robot to fix the problem short term, and then that gives you the time you need to fix the problem longterm.
Arne: [00:18:55] Yeah, absolutely. And there, there was another thing that I, that I picked up, and that was around the UI and why we have it in the first place. could you expand on that a little bit and connected to what you just said, with regards to the, to the plaster ?
John: [00:19:10] I am profess is literally only there. For the user. So if you remove the user or you're building an automation robot, or why are we using the UI, you know that it makes some sense because there's a person there anymore. Nobody has to see the screen, you know, you don't even need a monitor.
So I, my personal opinion is that if the way automation needs to go, it can't be through the UI elements cause that's there for humans. It has to be, you know, like, I think you were mentioning the beer, you know, like back end API access is, which are a lot more secure, a lot more reliable and much, much faster.
Arne: [00:19:47] We've talked a little bit about RPA here, and I think we both agree that it's not the silver bullet in all situations. And I wanted to move on now to the, to the second topic, to this intelligent process automation. And I want to be a bit provocative here. I feel like the humanist building, the automation, that's the intelligent piece of it. So why do you think we need a new term on the market?
John: [00:20:15] That's a good question. I think if somebody was asked me what I do, I would say automation. I wouldn't say RPA. I wouldn't say intelligent automation because, I'm sure you'll agree with me on this one, The definitions for those are not set in stone. What does intelligent automation mean. I have a general idea, but you know, one company will say that they're doing it intelligent automation when all they're doing is using RPA software.
Another company, I'll say they're doing intelligent automation because they're using machine learning to make human like decisions. You know, it's not entirely clear to me what the definitions of these are. I think people, I think companies just see them cause the grab your attention. But no, I don't think that needs to be new terms. It's just automation. It's process automation.
Arne: [00:21:04] and yet I think that the market is kind of settling on these terms at least. Right. So, I mean, this RPA has been around for some time, and I mean. Already having a robot in your, in, in the description of your product is suggesting that there is some intelligence behind. What I feel like when I'm looking at some software vendors, there seems to be a trend that intelligent process automation, this term is used whenever there is machine learning involved to some degree. And we can expand a little bit on how much machine learning there really is. And how much if and then is actually running in the background.
It will be to get your view on this, but still what you, would you agree that this is kind of where companies are drawing the line?
John: [00:21:57] I think so. Yeah. If you were to ask me what the difference between my personal opinion on the difference between RPA and intelligent process automation, it would be that intelligent process automation involves some form of machine learning or sort of data analysis to change what it decides what to do with the process.
So, you know, if you think an RPA you use, like if statements, you know, if the value is that school, that route, and if the value exists without route, but then you start to make problems, you know, with more complex processes. Like if you know. You know, I'm kind of actually think of an example off the top of my head, but let's say a month X, if this phrase is, is, you know, positive.
If it's, they are more happy, positive, free is, you know, it's able to look at text and based on the words on the page, you know, it's not exact, but it's able to make decisions based on what it's reading like a human would. So it can sort of make decisions by itself on what it should do.
The company that I used to work for, sorry. It was a massive company, so they would get thousands of expense reports every day. The problem with that was that people, you know, essentially they take, you know, they buy things that aren't kind of fall under expense reports. So for instance, alcohol, you know, you're not really meant to buy alcohol and then submit an expense report for it. So what I had actually built was that it would look at expense reports and read the language and the things that they, or read the receipt, sorry.
And read the language that people have submitted these expense reports and try to pick out anomalies. And a couple of examples of interesting ones that I found or, one example of an interesting ones I found was shotgun step shells. You know, this guy had submitted maybe 500 lines of expenses, and in the middle of it there was 20 pound for shotgun shells, you know, and it flagged it up.
You know, why is this guy buying shotgun shells and then trying to get the company to pay for it. You know, it was very strange, but that's the power off it. And it could go through millions of lanes, you know, a second as opposed to Harbin, 200 people, you know, in some office, in a dark room, reading through these, they've got a mess, things like that.
They're not going to pick up on it, you know, as a human would. Cause that's not what we're really designed to do.
Arne: [00:24:16] But that's a reality, right? I mean, this is the world that we live in. We have, we have these jobs. It's, it's. It's unbelievable. But yes, they exist. Exactly what you just described. armies of people looking at such statements and trying to filter out, for instance, shells
John: [00:24:35] It was so strange. You know, you, you mentioned that I don't like RPA, that that's true to an extent. It's not that I don't like it. I think we need to set realistic visions of what it is. And you know, it's not this hyper intelligence and the robot that can do anything you decide to do, which seems to be what a lot of people think it is.
You know, I'm, the better a a developer is the better they can make the robot, obviously. But there is always going to be a ceiling limit of how complex a process can be. But you know, when I, sometimes I tell people what I do, I've actually kind of had to stop, believe it or not, because you get these, that you occasionally get people.
When I say no, a automate processes for companies, then they immediately kick up. Oh, so you're making people redundant, you know? And then they're not happy with that. But the truth is, is that, you know, people aren't happy doing those things. I am very much dope antibody is hobby ribbon lanes and lanes of tests and trying to figure out is this legal or is it not legal?
And things like that. You know, I, I would argue that if you give the people the option to have these robots to free up their time. They would absolutely take it, but it's on the company to find jobs for them to do, you know, afterwards, and to utilize them as opposed to just getting rid of them. I don't think I've actually met a robot and it's replaced the person completely.
I've never seen anyone get fired. So I think that's a myth. That robots, at least at the minute, are going to cause mass on employment. I think it will eventually happen, but I don't think it's going to be soon because the robots are just not smart enough to do that.
I think, you know, personally, I believe that a lot of, you know, as humans. We need challenges. We need things that are challenging to do in order, you know, fundamentally to be happy. If you're sitting reading lines of expense reports, you're not going to enjoy that. And if you're doing that every day for the rest of your life, you're not going to be a happy person.
So, you know, if I was to take a sort of idealistic world, you know, of, you had asked me in 50 years time, you know, everything went perfectly well. We would have robots doing those jobs. And then a work for some people working on the harder stuff and actually getting sort of, I suppose, good work, work satisfaction because of working in things that they find interesting that are difficult and challenging.
And that that's how innovation happens as well. You know, people have a problem that's very hard to solve and then they eventually solve it. But if you have 90% of your workforce, you know, like zombies at a computer where then you're missing 90% of the population working on difficult problems cause they're doing menial problems.
Arne: [00:27:15] And that's when you need these, these huge armies of people right in the first
John: [00:27:19] place.
Arne: [00:27:19] Place.
I mean there There are still manual jobs. In my previous company, we've had, many, many forklift drivers. And so on. People are actually physically handling things but in, in many cases, you also need these armies of people in order to handle these, these tasks that we were just talking about.
Right. And, so if these could be automated in a, in a smart way or in a, in an effective way, this, this would then take this whole company forward.
John: [00:27:44] Yeah, definitely.
Arne: [00:27:45] Can you take us a little bit through a project where, which you would consider, man, this was intelligent process automation for me.
John: [00:27:57] So one that I'm working on at the minute, I have to be very general in this example cause I've signed NDAs and stuff. But it's again a financial company and they deal with that. So they essentially a person in debt and they are trying to alleviate that debt and instead of maybe declaring bankruptcy, they will go to one of these companies and make an application to your, there sort of some sort of debt relief.
And, and the way the application process works is that they don't load a PDF, a PDF of a form. They fill out the form and then they either email it back or maybe they write it up on the computer and email it back or scan it and send it back and stuff like that. So. What I'm working on at the minute is a law of OCR is that we get these scans and we have to prepare the image that we have.
You know, if it's a scam, for example, there could be a lot of sort of dark patches on the images that we'd have to clean the image up and then we have to all see our, the image. So we get all the text from it. Then we have to go through all the tabs and pick out the bits and pieces. Eh, that we want sort of like the persons in the IOM, how much is the debt for, account numbers, stuff like that.
But the difficulty becomes that there are still many different variations of how these forms are filled out and the templates of them. So you have to, you know, use machine learning and natural language processing OCR and stuff like that to, to pick out the particular things that you are interested in and sort of get rid of the rest of it Then, once we've collected all that data through the OCR and the natural language processing and stuff like that, we then put it all into a spreadsheet, and then that's fed into the RPA robot, which goes onto their application.
And that essentially submits all that data wherever it needs to go on the application. And that's not, but I've been working on, so I don't know massively the details of it, but it will take, you know, the person's name and search for them, and then update all the relevant, relevant information that we got from the PDF or the image, eh, and then continue onto the next one.
So that, that's a good example, I think of joining the two things together. You know, machine learning and intelligent automation. To the robot that then picks up the menial part of the job, which is just data entry.
And then to tie it back to what I was saying about the plaster analogy, you know, we fixed the problem relatively well, very well. It's a complex problem, but you know, you'll notice yourself machine learning, there's probability based. So read OCR, for example, as a, as a type of machine learning, it uses neural networks generally to sort of predict the characters.
But: it's probability-based. So it's not saying "that is the letter a, and this word is John". It says it's 90% likely that this were just John. So you know, if you expand that though, that means if you give it enough iterations, it's going to get it wrong. Sometimes. Which isn't ideal, but we've put the plaster of the problem.
So no, they have the time affects the problem and you know, they're not actually doing this, but what they should be doing then it's saying, right, well that's, you know, maybe create a web form where people can fill. So in a standardized way. And when people are, you know, when we get all these different templates, we need to go to the other companies that we work with and sorta make it universal, make a universal template that everybody can work with, so then it's much, much easier than in the long run. You know, you can get rid of the robot because everything is so standardized and generalized that it's almost going to work 100% of the time instead of 90% of the time or 50% of the time.
Arne: [00:31:43] And, and even if you had this a web form, you could still, for certain cases, you could still offer to have it in a, in a templated way. because you have all these structures already set up, right?
John: [00:31:54] Exactly. You know, it's kind of like I help fix the problem. So now, they sweep it under the rug and re knowing that again, and I will guarantee this, that in two months time they're going to call us up and there will be a problem. So I'll have to log back into their computer and fix the problem, which obviously is fine. That's my job. But a much smarter idea would be then to take it the next step, like, like we were talking about and just make it much less, less variables and ho to receive the data and make it universal and that there's just like, honestly would just alleviate so much problems for me on them and, you know, in terms of their company processes.
Arne: [00:32:36] So what would be the tools that you would be commonly, or what that you are commonly using, in order to get to this more intelligent level of automation?
John: [00:32:46] Yeah. And so I would start by saying that I'm not one of those developers that is always pacing or always C sharp or C++ or are, you know, you need to use the right tool for the job, whatever that may be. You know, and you have to be adapt, adaptable. but in general, if I was automating a process that hard sort of complex intelligence that that would be Python.
and that comes with a lot of packages. Scikit-learn is one, NLPT for natural language processing and it's just so good. because all I have to do is import that library and I can get started. The danger with that is that you get a lot of people who work on you got lot of people who use machine learning, but they actually have no idea what was happening under the hood that's just a black box. They just import the library and read the article off Medium and they've bing bang bosh. There you go. You've got it. But the problem with that is, is that you can overfit and udnderfit data that cause it's all probability in nature. There's some, there's so many different algorithms you can use.
What's the precision and recall and which is essentially like better measures of the accuracy of the algorithm. You know, people don't then do their analysis of how well the algorithm is working after that. Or this is the results and think, yup, that's working.
Arne: [00:34:10] John, I'm so glad that you, that you held yourself back there, or you pulled yourself picketed because, when you started and said Python was all that easy. I already pictured a few listeners thinking, I've, I've tried it and I don't think it's easy. so I, I think the word easy is subjective right?
John: [00:34:27] Yeah. Sorry. It's easy compared to a lot of other languages out there. It's just the tool, you know, it's a Harmer. The difficulty really comes from what you're trying to do with it, as opposed to the language Python. It's easy to learn in the sense that relative to other languages, it's easy to learn. It's still difficult to learn.
Arne: [00:34:48] I think the one point that already comes across now is that as opposed to this RPA field, there are not so many tools which you can just pull out of your box, and you install it on your machine and it starts working instantly. Right? I think the market is heading there so, I S I see some tools popping up here in there, which gives you machine learning, deep learning straight out of the box.
John: [00:35:13] No, no, I fully agree with that. Yeah. And you know. For instance, I think, isn't that a zero have a sort of like set up that you can start using really complex algorithms and stuff, which is, you know, the benefit that they see from these drag-and-drop, you know, workflow-based problems or a solution, sorry, is that you don't have to be a programmer to use them, which I think is a great thing because not everybody wants to be a programmer.
But I think the world is heading in a sort of direction that everybody needs to have a sort of baseline understanding of ho to automate and how to do simple programming and not necessarily to the extent that I do it or you did it, but that's the way it's going. So we do need these simple drag and drop sort of user interfaces for, you know, you know, for what it's typically complex, like a complex problem.
Because that's where we're having every, you know, everybody has to have access to the sort of technology. And if that means having the applications like this, you know, I know some people, I know some programmers who get annoyed because they think people are stepping into their fields that shouldn't and don't have a right to do that.
But that's just ignorance. You know, we need that. We really need to have these tools, but you also need to realize that these tools have limitations, you know, and you need to understand those limitations.
Arne: [00:36:39] It's, it actually reminds me a lot of, what's, what is happening in the programming or RPA space where the machine only gets so smart as how you train it or how you teach it. Right? And, if we are adding machine learning to this whole equation, then also the machine is just. As smart as the data you fed into it.
And if you, if the machine hasn't seen all the data, it cannot be possibly I'm taking the right decisions on your behalf right.
John: [00:37:09] Absolutely. Yeah. And you know, and that's another good example. We'd say machine learning, and we say intelligent automation, but even by today's standards, you know. It's a relatively new field, that machine learning, you know, it started in the 60s but they couldn't get it to work because they didn't know the algorithms and computers weren't fast enough but now it's kind of had a revival. But I would still argue that a lot of these algorithms are not smart. They're incredibly stupid. if I turn an algorithm that can look at a picture and say "that's an apple", "that's an orange". But once, if I give it a picture of banana it doesn't know what banana is. It's ever seen a banana before all. And the only thing it can open is apple or orange. So when you feed something new to a machine or an algorithm, it tends to just output a result, I guess. you know, it's completely wrong. so that's another limitation. That's not that general intelligence sort of situation.
Arne: [00:38:04] But this does not mean that you cannot build wonderful things with these tools, right. It just means that, if you don't expose these algorithms to what you eventually want it to, to predict, then it has absolutely no chance to make a transfer from our, so I know that this is an Apple, this is an orange, and this is then the next fruit.
But it's simply. It tells you it's a, it's an Apple because it's yellowish.
John: [00:38:31] yeah, yeah,
Arne: [00:38:31] all the conclusions. It's drawing from it. But of course it's, it's utterly wrong. So it doesn't have any self-correction mechanism as aJ just as a child doesn't have that the first time. It's, it's a starts of, being, being followed, becoming philos philosophical about, what a banana is, right?
Like a child doesn't know that either until you tell it. So, But then the learning curve is a lot different than a, as compared with a machine.
John: [00:38:59] Yeah, absolutely. And you're correct that it doesn't mean that we can't use these to be very, advanced. and you know, have a button itches to us. It just means that we have to be very careful. I hope we train them on how we use them. and so essentially the data that you use, the train, the algorithm has to be a very good representation of the data.
It's going to see in a, in a life situation,
Arne: [00:39:20] all right. the third topic that I just wanted to briefly go over, is more generally speaking about your view on automation. I know that you're all kind of sum it up under a automation anyway but what I wanted to ask you was what are some common patterns that you're seeing when you're dealing with clients of yours?
John: [00:39:44] The biggest one is definitely just misunderstanding what is achievable with the technology that we have at the minute. And when I say technology, I sort of mean two things. One, the RPA software, and, and two the actual computer systems that we're using, you know, the computers are no as advanced as they could be.
there's a lot of clients that they just really do not understand what they're asking us to do. You know, if there's a lot of tests say on, on a, a PDF, and they say, I want you to pick out all the human Liam's out of that.
That's, you know, to a person, that's a very easy problem to achieve. You just read it and look at, there's Arne, that's a human named John McCabe. There's a human them, but to a computer, that is a very difficult thing to do and it'd be good. Don't in the rid of natural language processing, you know, it looks like.
The structure of the words and like Vols and knowns and adjectives and stuff, and then tries to make predictions based on that. And generally it does a pretty good job, but still, like I say, it's probability based and that seems to be the miscommunication at the end of the process. The client seems the thing that if you're using these systems or work every single time.
All the time. But in reality, what it is, is that Oh, work 90% of the time on Oh, kick out errors for a human to look at, for the 10% that's not able to do.
And another pet peeve of mine is that they ask us to, you know. Build a, an automation, whether it's RPA or intelligence-style automation, but then they give us the most basic sort of computer or laptop or, or you know, as their platform set up, you know, that they can possibly find, you know, to gig around them.
And like one CPU unexpect us to be able to like develop on that. So it's a lot of back and forth trying to educate clients. You know what can be done, what is actually achievable, what we need from them, and on, I suppose, the longterm goals of what they're trying to achieve with this robot, which is where I get that sort of opinion that a robot is a plaster.
You know, a lot of clients think that once we build the robot, that's it. Done. But I constantly try to remind them, you know, that you meet the addressing problems in the long run and whether that should come to the us and you know, you go to our software team who build a new application for you, which, you know, if that's what has to be done, then that's what has to be done.
Or if you have to change the process in some way, or whatever it is that, you know, you need to fix the root problem, or you're just going to meet this problem again further down the lane.
Arne: [00:42:23] Yep. Yeah, I agree with that. Okay. Hey, I, I've got one last question to you. And that's, what advice would you give someone who wants to get started in that space? Because I'm seeing a lot of people especially on Reddit who are actually looking into this field as a as as maybe a second career or as an alternative career or as a career in the first place.
And I don't think that everybody has to study astrophysics in order to get where, where you are at the moment, but maybe you can shed a little bit of a light into this and give, give us your opinion on this.
John: [00:43:00] Yeah, of course. I'm so, you're absolutely right. You don't need to study astrophysics a bit to do this. And you know, I've worked with people who use RPA software and they studied theology. They studied, you know, business you know, and they're all as good, if not better than me with this RPA software.
I think, you know. The astrophysics was just beneficial in terms of, I can logically think about problems. It's just a personal thing to me but if you want it to get started, that's a good question. You know, I, I'm one of those people that when I set myself to a task, I almost become obsessive about it and I, I want to learn and I almost do it the hard way.
And I would say, do not do it that way. You know, UI Path, for example, you can download a free version of it. Find an example of something that you do personally every day. That that you don't want to do. And whether it's simply one minute, whether it's if you want or automate that task, you know, it's a real life example and you can read as many books as you want and you can read as many guides on the internet as you want, but you only learn how to program and you only learn really how to do anything but by putting it into practice, you know, so the guides and all are fine. But definitely try find an example in your life, you know, that is beneficial. Whether it's just literally logging it onto Google docs and don't do it in a file, you know, every, every morning for you or something.
Find an example in your life, you know, cause I have a four scripts that do stuff like this for me. And find something that you can automate in your life and you'll see the benefit of automating things and I'll help you identify processes that are automatable and three, it saves you time and you're learning.
I think that's the best way to get into it. And when you want to take it to the next step, so start getting into slightly more complex problems. a good tool is Anaconda. So it's that Python library distribution manager I was talking about, and then also download selenium.
So that's the web automation that you can use with Payson. And start playing around with that. So I'll shoot you how to automate things with the RPA products as well. You know, that, that the benefit of that is too, you're learning how to move away from the basic RPA products and to your, your learning pace, which will sort of lead you or prepared you for machine learning.
Arne: [00:45:32] Yeah, and just, just to get the expectations right on that. if somebody is going down that road, then this is not a matter of one or two days.
John: [00:45:39] Yeah, absolutely. You know, I've been using Python since. probably five or six years now. You know, I'm still learning stuff and every, every day that means that, you know, you never really become an expert and program and you become more adaptable and useful the other, but you never really get perfection out of it. There's always something new to learn and you know, you're right. Don't get frustrated if you can't learn something. Cause you know that happens to me every day, and I consider myself quite good at it. You know? And when you get frustrated, you stop enjoying what you're doing. So again, that's why I think it's good to work on real life problems for yourself when you're programming in general, you know, try to build a practice and do things that are somehow beneficial to you because then you're more willing to go through the difficult periods.
Arne: [00:46:25] John has been great to, it's been great speaking to you. thank you so much for all your time. I think there were great insights in there.
John: [00:46:32] Yeah. Well thank you for having me. I know this was your first episode as well, so, and I'm glad that we actually got talking on the, on the hybrids cause I've really enjoyed this.
Arne: [00:46:44] So there you have it. That's a two hour conversation compress into bite sized 45 minutes. It was probably one of the more technical episodes on the show, but I really wanted to have him in the podcast because of his vast experience in the field.
John mentioned a bunch of resources to get going, which you can find on our website, automation, dash masters, Pogue and German, uh, automation minus or-masters.com where I've added full transcript as well.
before you click on each link blindly and ultimately get disappointed. They are ordered by increasing difficulty, and if you're entirely new to programming, please keep a cool hat and give yourself some time to learn the basics.
I have also edited a book recommendation that John gave after I stopped the recording. It's called the rise of the robots by Martin Ford. I haven't read it myself yet, but it has great reviews and you can actually get a used copy on Amazon for is list three euros or dollars, and you can also find a link in the show notes for convenience.
if you have any feedback for me or the show, or if you want to propose topics of speakers, please drop me a line and I will make it part of the show.
You can help this show go forward through sharing this with a friend, subscribing through your favorite podcast channel and leaving a review on iTunes. I'm already looking forward for the next round on until then: happy automating!