#217 Paul McBride from RAF soldier to self-taught web developer

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Paul McBride 0:00
I think the most important thing that you need to know as a developer is that there's nothing you can't solve with a well with a well formed Google search. And at the time, I thought searching Google was because I was junior. And because they didn't know what I was doing. And the longer I spend as a developer, the more I realized that one of the most important skills you can have as a programmer is knowing like what to type into Google.

Tim Bourguignon 0:24
Hello, and welcome to developer's journey to podcast bringing you the making of stories of successful software developers to help you on your upcoming journey. I'm your host team building your own this episode 217. I received Paul McBride. Paul is a software developer, and head instructor and a tech nerd currently living in Belfast, Northern Ireland. He bootstrap we code and I a job board for developers in you guessed it, Northern Ireland, and currently worked at Na hi, nice. I heard it's called nice, but there's multiple eyes in there. So I must say. Well, welcome, Dave.

Paul McBride 1:05
Thanks for having me, Tim. Oh, it's my

Tim Bourguignon 1:07
pleasure. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up. If you would like to join this fine crew and help me spend more time on finding phenomenal guests, then editing audio tracks, please go to our website, Dev journey dot info and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guest. So but as you know, the show exists to help the listeners understand what's your story look like? And imagine how to shape their own future. So as always, let's go back to your beginnings. Where would you place the start of your tech journey?

Paul McBride 1:58
Good question. So I think like a lot of people on the show, I didn't take the traditional route into programming, right. So that my the very start of my career, I guess, was when I was when I was a child. You know, like, like most people that end up getting into programming. I played with computers and stuff when I was younger. I was big into my video games. I played a bunch of RuneScape I don't know if you ever played that when you were younger. And that

Tim Bourguignon 2:22
reminds me something I don't have a picture in mind that name definitely rings a bell. What was it about?

Paul McBride 2:29
It's like a massively multiplayer online role playing game. So it's kind of like a you go around your mind stuff. It was kind of like, a Minecraft before Minecraft sort of thing. Okay, so I learned a lot when I was younger. And from that I got a lot of time as a kid with computers, like I, you know, play with my friends I played on Xbox, they call that kind of stuff. And one day, I decided that I wanted to be able to play RuneScape with some people that I didn't know. And I wanted to, you know, build my clan kind of didn't have a clue how to do this. But as as we developers know, if you want to know a question, Google exists for that. So sort of googling how to how to set up a website how to how to connect to people that you don't know, because this was before social media and stuff really, like MySpace was just about getting started. But the kind of the kind of nerds that were like, you know, 1112 years old, playing Runescape didn't really have much. So yeah, I started learning how to how to write HTML and CSS. And this was back when HTML and CSS were pretty hairy. I think the service I used for hosting these at the time was geo cities. I don't know if you remember that.

Tim Bourguignon 3:34
Okay, that's that old? Your old? Yeah, yeah, of course.

Paul McBride 3:42
So that was sort of the vintage of like web development that have come from, but never in my life that I like, certainly at that age, that was not how I thought I would be making money later in life. That was just I was doing it for fun to play video games may like my childhood dream was to join the Royal Air Force. And so when I finished school, that's exactly what I did. just signed up, went down to the recruitment office, I applied to become a pilot. And they looked at me and said, Yep, cool if you got an A test, and unfortunately, because they didn't have 2020 vision, they said, You have to pick something else. You don't need perfect vision to be a pilot. It's just that they get 1000s of applicants for every pilot job, right. So they use that as a screening criteria. So had a look at the list of other professions I could pick in the military. And right below pilot was police. And so that was the next thing I picked, and I joined the Royal Air Force police. So for the next few years, I kind of you know traveled all over the UK and and the world with the RAF police. I was mostly best after I did my basic training, mostly based up at Lossiemouth on the north coast of Scotland, a beautiful part of the world. And from there, I got deployed to Afghanistan a few times but got to do some really, really cool and it was actually in Afghanistan whenever I was like, You know what, this this whole military thing? I don't think it's gonna work out long. Turn from me. And so I was like, I've got to figure out something else to do. And we're not here to talk about war stories, or any of that kind of stuff like, Afghanistan was Afghanistan. And I remember after a particularly hard week, sort of coming back to like, Camp Bastion, which is the world of the UK forces are best, and you have like some internet access and that kind of thing. And thinking, No, this isn't for me. And Googling, well paid jobs in Belfast to find out, you know, what I could do after I decided to leave the military. And programmer web developer came up. And I was like, I vaguely remember something about this from from when I was building my Runescape websites. And yeah, that's that's kind of where it started for me.

Tim Bourguignon 5:42
Wow. How long did you send him in the military?

Paul McBride 5:45
I was in for a total of five years. Oh, that's a long time. Yeah, like, the average person that signs up for the UK military, I think the minimum contract you signed up was for nine years. And then if you want to extend you can, but if you want to leave early, and there's availability to do so you can. So I had to give, I think it was two years notice whenever I said I wanted to leave, because the RF police were a little bit understaffed at the time. And they wanted to make sure that people being trained up to replace me whenever I left, and so like, whenever I put my notice and to say, Yep, I don't want to do this anymore. Like give me basically two years to figure out how to how to code.

Tim Bourguignon 6:19
That's my next question. How do you plan two years of training before before entering workplace when you know you have two years ahead of you? When you pretty much know the space already? I mean, at least you have some know some some some milestones, you know where where things are. And when you hear CSS, you're wondering what kind of worm that is, how did you how did you approach this

Paul McBride 6:42
problem? So as I said, like, the very first time I looked this up, I was in Afghanistan, and I Googled well paid jobs, Belfast, programming, web developer, that kind of stuff was the some of the the highest ranked, you know, enjoyable, like people like those jobs, and they get paid well to do so. So I still on Afghanistan, Google, how do you do that? And the website I are the sort of training school I ended up signing up to was Team Treehouse. So I think they're still going actually, I signed up to there. And the sort of 30 minutes of Internet access I got per day was spent watching Team Treehouse videos, and learning HTML, CSS, JavaScript, and whatever other languages I could, you know, I could get my hands on at the time. And no, I didn't really have a grip computer. At the time, I was in the middle of a desert, there wasn't a lot I really could do. So that kind of got me inspired and interested. But it didn't really start building things and learning how stuff worked properly until I got back to the UK. So when I went to go back to the UK, I went back to working up at Lossiemouth in Scotland, and as a police officer, a lot of my work was done on night shifts. And during like the weekdays especially there was very little work to actually do do some patrols. And then you'd be sitting in the police office with nothing to do. So I bring my laptop into work, and most night shifts, and I don't tell my boss this, or my boss was on a podcast, I guess. No, I pulled my laptop up. And most nights in work, I'd be not doing my work, I'd be building things and building little websites. And so over the next few years, like as my skills and that sort of grew, I just keep taking on more and more challenging ideas. And and thankfully at the time Treehouse, and even though I'm sure they do as well had gripped curriculums. So you kind of pick what track you wanted to do. I picked web developer, I think it was. And they sort of brought you through you do several CSS courses, there were several in HTML and CSS JavaScript, and then they would encourage you to go on and pick like a back end language. And I kind of just follow their courses on through. And it worked out well for me, in the end, I got to the end of those two, in fact, probably six months before the end of my time in the military. I was like, right, it's time for me to start applying for jobs. Even though I couldn't work for six months. But looked at a few of the companies that were sort of in the area of Northern Ireland, I was moving back to find five or six of them. And every month, I would pester them, I'd send them my resume, tell them about some of the things I learned that month, and let them know I was ready to start working for them. And almost every month, the six or seven companies would reply saying stop emailing us or hiring. But I'm nothing if I'm not persistent. As the months went on every month, as I got closer to moving back to Northern Ireland, I'd send another one of my resumes with, you know, like my, my skills that have tan on all the languages I've been learning and they'd all be up one number. And I'd be like, Yep, I've learned some more stuff. Can I have a job? And again, that to me, leave them alone. And eventually, I moved back to Northern Ireland that centered like sort of one final last ditch email saying, Yep, I'm back in Northern Ireland. I can start tomorrow. Here's my resume. Here's some of the new stuff I've learned. kind of come work for you guys. And again, most of them were like, No, we're not hiring. Stop talking to us. But luckily, one of the companies did get back to me and they said, listen, we're not hiring, but we can clearly see you're not going to leave us alone. So do you want to come into the office for a day and do like some work experience and find about what it's like to be a developer, because, you know, I'd never done it before. And I was like, I've got nothing better to do. So that sounds great. So this company was called, it's the company still going X is called a killer. They were a little web design agency in Bangor County, done in Northern Ireland. So I went along there, I spent the day with them. And I had like, like a fake little interview at the start of the of the day, where they asked me, you know, about my background, and I told this story. And then I got to spend the day working with a few of the developers there. So I built some like terrible HTML, email templates built, I don't know, some some silly front end template. And I went home, and I thought, Well, I'm gonna start applying for jobs again. But it turns out, one of the guys that I like sat with all day actually really, really liked the work that I did. And whenever I left, he went to his boss who'd interviewed me and stuff and was like, you know, for someone that's sort of self taught and has been, has no experience. There's, there's potential here. And his boss agreed, and they called me back and offered me like an internship basically. And so that was my first job in programming, and I will forever be grateful for them to help me get my foot in the door. And it's everything since then. It's just been job after job, you know?

Tim Bourguignon 11:11
Awesome. That's really cool. How was this this learning period, in in this internship, compared to what you've done before? So one, one was solo, video based, etc. The other one was on the job was probably colleagues or mentors, and I call them how did that match your way of learning? How did you adapt to that, etc.

Paul McBride 11:31
It was, it was really interesting, and quite a bit of a contrast. So obviously, when you're learning by yourself, there's no timelines, there's no deadlines, there's, there's no pressure on you. Whenever you're working for an agency that's like the complete opposite from from, from working by yourself. So I find that like, it's not like it wasn't used to working under pressure, you know, I'd been, I'd been to Afghanistan, I'd worked in high pressure environments. And like, this wasn't anywhere near that. But it was the first time from a software point of view where I'd had, you know, a fire under my ass to kind of get some work done. And I think certainly, when I was younger, I needed that, you know, having someone there been like, you said, you'd have this done when I like, it wasn't done yet. So that helped me sort of, it's a lesson that I've sort of taken to later in my career, and that there's a balance to be had between perfect and being done. And something that isn't shipped, that doesn't matter how good it is. So I think that was sort of where I started to learn that lesson. You know, ship the thing first, and then make sure it's good enough afterwards, iterate once you once you're in production, as long as you can, you know, build something that isn't terrible before you put it into production. But yeah, having colleagues that ask questions and people to lean over my shoulder when they're doing code reviews, and be like, Yeah, don't do that. Or Yep, this is great. Keep doing that was was super useful. You don't really get that with video lessons. So it was definitely sped up my learning.

Tim Bourguignon 12:58
Did you continue learning something else via views during the time where you're really focused on

Paul McBride 13:05
your agency? know for sure, I kept learning stuff there, too. Like most of the work I was doing for this agency was the sort of grunt work you would give to someone that didn't really know what they were doing. It was mostly just email templates and building. I can't even remember what the CMS they were using at the time was, but it was mostly to building HTML templates with some CSS, which super valuable skills, they're things that, like I still do today. But it was the kind of low value work that their veteran more senior engineers didn't, didn't have time to do. And it worked out well for me. Okay,

Tim Bourguignon 13:37
I 20, did it change? And it would, when did you? Did you start getting different kinds of work? Yeah,

Paul McBride 13:42
it was, it was my next job. The agreement I had with this company, whenever I came to work for them, they were happy for me to take time off work to go and apply for other places. And to go interview. They were they were honestly really doing me a favor by giving me this first bit of work. So it meant when I was applying for my next job, I had real world experience had actually been employed as a developer. And so they encouraged me to seek out other opportunities. So that's what I did. And moved to another agency. I actually wasn't there for very long, I think it was 12 weeks or something. And it was just sort of get my get my foot into the industry, and then and then start looking for somewhere else.

Tim Bourguignon 14:19
Okay, okay. How did you approach this, this new research phase? The first one was really coming from this. I have no idea I've never applied before for developer jobs. Now you had done it. You had earned a few refusals. I've earned one success. And now you go at it again. I was the second time.

Paul McBride 14:36
So at this stage, I was very much in the early part of the Dunning Kruger curve, where I'd had my first job so I was pretty sure I knew everything at this stage.

Tim Bourguignon 14:47
Don't we all

Paul McBride 14:50
think I think my ill founded confidence carried me quite far for the next little while. So I was applying for jobs that definitely I was not qualified to do. The next job I applied for was I'm actually a senior PHP developer. And I was very clear in the in the job title that I was not a senior developer. But I'd seen this advert on the internet for a little while. So I was like, maybe they're, maybe they're willing to lower their requirements a little bit. So, and they were so I mean, I emailed them, I was upfront, you know, I'm not a senior, but I'm a fast learner. You know, I've, I've taught myself, I've managed to get my first job, and I'm just what you guys need. And they happen to agree. And that's what I moved to afterwards.

Tim Bourguignon 15:29
Okay, so how did that go was a company that at first wanted to have a senior, and then to q1, your potential?

Paul McBride 15:35
Yeah, so very much a drop me in the deep end, I had a few weeks of, you know, getting on board and pair programming with our lead developer at the time. This was a WordPress agency. So they were just doing similar kind of work. But I got to take on a bit more of the responsibility building some of the actual PHP back end for these websites. And that was a great a great place for me to start to stretch my legs a little bit and not just work on front end, and CSS for to actually see how databases work. It was the first time you know, I got the work by taking a payment processor and processing credit card details and that kind of stuff. Which beforehand, I had like that was black magic to me. And then you see it happen for the first time in your like, this actually isn't too bad. So it was yeah, it was really another really good opportunity. I think I was there for a run a year. It was the first time I'd made a proper mistake in production, though. Oh, tell us about it. So this company had built a few of the console websites around around Northern Ireland. And one of the things that you can do on the Council website is purchase new, like rubbish bins. So if your bin is blown away or stolen or whatever, you can buy a new bin. So this was this is how I learned how to take credit card payments. And when I was testing this to make sure that there was certain spending limits and stuff. You know, I had hard coded the quantity of bins you could buy done at noon, and tested it Friday all worked grip, deployed, it didn't turn that back down to the actual value in the in the slider. And so a few people came along. They needed to replace their bin and they bought 99 bins and were charged for there's 100 bins are easy to collect.

Tim Bourguignon 17:15
In New in the large ones with wheels that you have to Yeah. You almost always need $99

Tim Bourguignon 17:25
Of course, of course. That was my first proper mistake. I like I got the email on the Saturday my boss had find it after they got complaints fix that and I was like, Well, you've got to find another career. No, I'm definitely gonna get fired. But that's not how it works. You know, they were they understood that it was it was a mistake. People make mistakes, and I definitely learned from it. So

Tim Bourguignon 18:33
Know the school did that influence the way you approached mistakes or potential mistakes afterwards that are definitely

Paul McBride 18:42
Well, it seems like they were kind enough to you know, correct my error, like helped me learn from it. And I'm hopeful that now that I have juniors working under me that I show that sim, Gris, that they showed me and I try to make sure that whenever one of my colleagues makes a mistake, or have made a mistake in the past that I'm like, we're all human. I've done it too. And you know, regale them with my stories of the 100 bins

Tim Bourguignon 19:09
it's really helps grounding you connecting with the persons who obviously feels bad after doing something like this and then connect the dots again and say okay, what went wrong let's Let's analyze this. Let's make sure we understand what really went wrong you are part of the process obviously involved but now you're part of the solution is well, and cetera in Israel, your learning experience or a chance to learn something? First of all, yeah, awesome. Awesome. How long do you say that

Paul McBride 19:38
I was there for a little over a year I think. And I didn't like I really enjoyed my job there. The reason I moved on was because I wanted to this was when react was just starting to take off. This agency had no reason to use react like they were cranking out WordPress websites, they were making money doing so you know, why change a formula if it's if it's making you money, but for me, I wanted to, like, I've always been more interested in JavaScript than I had in PHP, I wanted the opportunity to write more great more JavaScript and more react. And so I started learning. On my own spare time over like the sort of my last three or four months there, I'd master on the built, you know, the, the To Do app that everyone builds whenever they're learning any framework. And so again, at this point, I was still young and very naive about how much I knew I built my To Do app. At this point, I was a JavaScript expert, right? So started applying for JavaScript and React jobs. And I got I got asked in interview for a company that didn't exist anymore, called piggy pot. They had like, it was like a savings app. And so got invited along to this, this interview. And I was able to sort of waffle my way through the interview and show that I knew how to, you know, by the variable credit function, iterate over an array, that kind of stuff. And they were like, Oh, I noticed in your resume that you've mentioned, you've you've built some projects. And I was like, yeah, they're there on my my other laptop. I don't have those with me. Because I mean, they didn't really exist. They were terrible. And so Oh, yeah, no worries, if you could just email those into us for Monday. So I had a had a pretty horrible weekend, that weekend, had to go back through my CV and be like, Okay, I said, I've built this time to go build that. So I mean, this, this is not great advice, don't don't lie on your resume, it comes back to bite you. But I was young, I was dumb. And it worked out for me. In the end, I was willing to sort of sacrifice that weekend, and build the things that actually claimed a build. I'm glad I did, I loved that job. It's probably the one of my favorite jobs I've ever had, it was a great bunch of people. It's the first time I'd worked in a product agency, rather than, you know, an agency that builds websites for other people. So it was the first time that I had to write code that I then had to maintain. And I think that's a skill. Like that's, I think, whenever you start to become less of a junior developer, and more of a mid level or a senior developer, and less maintaining code you've written and code other people have written. And you don't get to do that so much in agencies, because, you know, the quicker you can get the product out the door, the last time you spent on it, the last it's cost you and the more money you can make. When you're working in a product type team. That's not the case at all, if you write fast, quick code, and I you pay for it later,

Tim Bourguignon 22:27
there has to be a trade off that you make, because you know what you're getting out of it, knowing that it's gonna hit you back of the head right after.

Paul McBride 22:36
Absolutely. So the pendulum swung the other way from you, then it was less about cranking code out as fast as I possibly could. And I became a little bit too obsessed with writing perfect code and making sure there was 30 tests for every function that I wrote. And, and later in my career, you know, it goes the other way, again, like, at that time, I was like, everything needs tests, need tests, those tests these tests

Tim Bourguignon 23:06
in so many ways.

Paul McBride 23:10
But this was the first time I was I was exposed to it. And I was like grip, the machines are testing my code, so I don't need to test it. And I can never sell 99 bins ever again. So problem solved. You know, everything's all grim. But that that obviously didn't last very long. Because at this point, you've still got code you need to ship. And customers don't care about your tests. They just care that their app works. And as you know, as I spent more time on this job, and especially as I moved on later in my career, you start to find that, like there's a balance to be had there. And harks back to what I said earlier. Like, there's no point writing completely perfect code. If customers can't use it, what's the point in writing software if it's not being used? So you need to be pragmatic about test coverage and performance and writing the perfect code versus writing code that customers can actually get their hands on?

Tim Bourguignon 24:03
Absolutely. Absolutely. Did you remember in this early phase, you mentioned tests as one of the things you really started doing all the things that you weren't doing before and found to be actually good to do and realize, oh, there's there's some value in there.

Paul McBride 24:18
Yeah, it was a bit of a culture shock entirely moving from a, like a web agency to building a product, there was a lot of things that were done differently. So this was the first time I'd worked with, you know, the likes of Webpack. And any kind of build tools from a JavaScript, all of a sudden, there was JavaScript that was like the secret JavaScript that you couldn't write because it didn't run in browsers. And I could start writing that myself. And this was like when es five was was released, and all of a sudden you have arrow functions and, and all kinds of the cool new features. And beforehand, before that, that sort of stuff became a JavaScript was a bit of a crazy language. It was inconsistent there was there was you missed a lot of stuff moving from any other language that could Uh, my background was in PHP at this point, you know, and there was a lot of stuff coming from PHP to JavaScript, I was like, You mean that we can't just, like work with dates and times. And in fairness, you still can't really JavaScript. But there was lots of stuff that with the introduction of ES five and and all of the versions of ECMO script afterwards, because we were using a bundler that I could write that in, in a language that makes sense to me. And it's easy to maintain and right. But it gets converted to that runs in any browser. And this blew my mind. So that's whenever I started actually becoming interested in the standards and, and seeing new, exciting JavaScript. Because previously, I was like, this is for like, you know, academics. This isn't working man's JavaScript, but all of a sudden, it was available to everyone.

Tim Bourguignon 25:47
And it's cool, it's cool. I can't remember at this phase when I went through it, but I know we all went go through it. And we have this phase where we realize, oh, okay, now I can use all I can use it, oh, this is solving so many problems. And they obviously you overdo it, but and then after some some some some time a temper your your your hopes for this newfound method and come back to something more moderate, as you say, and realize, okay, there's good Oh, good, critical that there is value in this, in this method used properly. There was like it for me like that, for me with TDD. I went gung ho on TDD for a while. And it was just unmaintainable. It was way too many tests. And then at some point, you come back and refactor the tests you you wrote and remove a lot of them and really construct a test suite that is really helping you and there's not so brittle that when one fails, then you have 20 Other that fails down the line. And you don't know which one was the first one. So

Paul McBride 26:45
totally, I think especially for front end development that, like whenever you're first getting into testing, it's so easy to write terrible tests that aren't testing what you think they're testing. They just like, you get, like that line of green ticks. And you're like, This feels great. I mean, it's total nonsense, but it feels good. You know,

Tim Bourguignon 27:06
you have a first the first read in your database, and this one fails. And so 250 tests fail, because you're all doing some some kind of a read in the database. Absolutely. And then you start searching, which one was the real one? Okay, so how do you know how long did you stay in this in this product shop or practice company

Paul McBride 27:27
I was there for. So early in my career, I clearly jumped around quite a lot. And I think there's value in doing so. So I was there for I think, six to nine months, something like that. Oh, that's a short. Yeah, I wasn't there for long. And it wasn't because I didn't enjoy the job. Like, as I said, it was probably one of the favorite jobs I've ever had. But what had happened was that the next job I moved to, was started by a close friend of mine, and they had just got funded, and he swung a big bag of cash at me. You know, it's, it's hard to say no to that. So I jumped ship, and I moved to go work with with a few friends, it's a company that's still going like, without getting too much into it, I would say it's, it can be beneficial at times to to keep like a separation between your personal life and your professional life.

Tim Bourguignon 28:16
I feel there are some stories that we say here, but maybe that's not the place we should go. For the sake of friendships,

Paul McBride 28:23
I am still very good friends. company was started by a few people, right? I'm still very good friends with a bunch of them. There's another bunch of them that were less than good friends, shall we say? So I was I was there for about a year. And like, that was the longest year of my life. It was It started off great. It was a lot of fun initially. And then. And then it like the company wasn't doing so well financially, for a little while, like they're doing great. And I honestly, I'm happy for them to be doing so. But at the time, they weren't doing so great. And it was a company that was just getting started, they just got a bunch of money. They had never really ran an engineering team before the the business founders were inexperienced. And so there was a lot of like, thrashing back and forth. We'll do this. Okay, that's gonna take more than 30 seconds. So we'll do this instead. And you know, they were jumping out quite a lot. And from, from an engineering point of view, that was really frustrating. It was really difficult to set up any kind of principles and set up any kind of workflow that made sense if you were only ever working on a thing for the half dozen people were interested. Yeah, exactly. So that that became frustrating. And eventually, the engineering team was kind of fighting the product and business team. It just became it became untenable for me. So we moved on.

Tim Bourguignon 29:45
Okay, did you remember when you decided to move on? Wow, that that felt or were the decisive moment.

Paul McBride 29:52
That was so that was like a pretty low point in my career, because it felt like a personal feeling for me. Were like, okay, like, this is it All throughout my career, up until that point, from a programming standard point of view had been pretty plain sailing, you know, I'd never come up across, I've never come across a problem that I couldn't solve with Google. But this was one of those problems, it was really difficult. The issue wasn't with engineering, it was it was out of my control, but it was still affecting my daily life, you know. And so it, it became, it became like, after, after I left on when I was in the process of leaving, I kept looking back and like, what did I do wrong? Like, what could I have done differently. And that was the first time in my life, like you hear about imposter syndrome all the time amongst programmers and developers. And that was the first time I was like, Maybe I'm not as good as the 23 year old me thought I was when I got my first job. Like, maybe, maybe I've still got a lot to learn, do I need to go back to university? Like, did it? Have I been bitten off more than I can chew? And yeah, that was, that was a tough time for me. And eventually, I can move on, I got another job. And that's where I am now, in fact, and it was totally different. You know, the engineering wasn't the problem, it was like a, it was a bad culture fit for me, and for a few of the others that were there at the time. And that can make a huge difference in a job, you know, like, if, if you feel happy somewhere, and you have that, like psychological safety, to make mistakes, and to learn, because, like most of engineering is doing stuff you've never done before, right? And so like estimating how long a piece of code is going to take to write is as difficult to do and, you know, determining your value based on the number of lines of code you've written is a pretty useless metric, right? And so it totally depends, like, for me, no, as I said, I took that job because they swung a giant sack of cash at me, and I jumped at it. And I know that I'm a little bit older, and a lot more settled in my career. Like, I think it's really important to find a balance between, yes, you can have all the money in the world. But if you're not happy whilst making it, you know, what's the point, I think it's important to find that balance, if you don't enjoy your job, no amount of money is going to make it okay. either fix your job or find a new one, if you're unhappy. And that's like, when I was younger, I would have been like, money can solve every problem. But I'll try.

Tim Bourguignon 32:14
It's not a new, if you were to. That's a very, very interesting y'all was if it's interesting thought experiment, if you were to go back now, knowing what the what you know, knowing about this, this this bad culture fit, as you said, knowing what could go wrong, but being the senior you are now and being back in this context, starting at this context, not knowing obviously, this is going to go bad, what what would you do differently? What would you approach with the seniority?

Paul McBride 32:43
Good question. I've actually, I've genuinely thought about this a few times. And I think the difference would be that I would treat it like a job. And I think when I was a bit younger, I was working with friends. You know, I'd go in there. Yes, I'd be working with friends. But you know, I'd be working as an engineer, and I would, that would be my sort of focus. I think the mistake was that you go and you work with friends. You can both everyone's would take each other for granted on the work that each other does for granted. And whenever it's or at least they can I don't think that's a working with friends isn't necessarily a bad thing. This just happened to be difficult because of, you know, the financial pressures of starting a business being new founders having a fairly young and inexperienced team. I think no, I'm sure I'm sure the other folks that work there would agree they're older and more mature now, too. I think, if that company was to start again, no, I think there wouldn't have been the problems that we eventually ran into. Because we're a little bit older, a little bit smarter. We knew what mistakes can be made. And I think I think it would really work out differently. No.

Tim Bourguignon 33:43
Okay. I see. I see. I think so you moved on. He went to another company, a product shop again? Or will Yep.

Paul McBride 33:49
The first time after that is where I am now. So I started working for nice. And this I've been at nice now for three and a half years, I think which I'd say the military is the longest I've worked in any job and contrasting to the previous job. It's because I I totally love where I am. You know, the work is challenging, but not so challenging that it's just impossible for me to do. But challenging enough that it's interesting, you know, the difficult problems to solve. We have an incredible team and an incredible like culture here too. So, you know, every day, the first thing we do, it's a small little team. We jump on a zoom call together, and we play like there's a Have you heard of the card game Exploding Kittens? Yes, I have. So there's a mobile app. The first thing we do every day is play a game of that. When we talk about work, we just sort of you know, shoot the ship, talk to each other, find out what we're doing in the evenings or if it's on a Monday, we talk about the weekend. And I think especially during like our transition to being remote, that was huge. Like the guy Chris that found a nice, his primary concern was we're not going to see each other. There's gonna be a breakdown of trust, it's not going to work out. And this was the solution to solve that. And it was a stroke of genius. because I've heard other people complain about how it's difficult to work remotely and how, you know, how do you know everyone's working on each other. But in this scenario, like, we're all, I'm going to contradict myself now, because previously, I said, don't work with your friends. But now at this point, like I consider all my colleagues, close friends, we have a lot of fun together before we even do any work each day. And it's really easy to like, there's no way, whoever is not gonna be doing the work, because we're all working together, we know what our mission is. And we trust each other to get it done.

Tim Bourguignon 35:32
I know this little experiment, how do you avoid creating some kind of monoculture with some rituals like this, which are very deeply anchored in in the core team who is always there before some of the people joining?

Paul McBride 35:45
That's yeah, that is a hard problem to solve. And we're just getting to the point now where our team is starting to grow. So we've we've on boarded a few people recently, and it's actually been, is like a pretty good hiring pool for us that almost everyone that works there has worked there for quite a while, and no one has wanted to leave because it's enjoyable. We openly talk about the kind of activities we take part in as a team, the fact that we play game, the fact that we have like, Friday afternoons, like we get together on Zoom, and we talk about our plans for the weekend and stuff. And that works really well, because we're a small team. I think as the teams grow, especially as we start breaking off into like, an engineering team or product team, a marketing team, that becomes more difficult, because there's no way you can have, you know, 50 people on a Zoom meeting, just talking about what they were doing at the weekend. That's an expensive meeting. I mentioned you can play with 50 people Exploding Kittens, unfortunately, yeah. Six people is the limit. And we have recently crossed that. So we look forward to that whenever people have days off. So we can all go back to

Tim Bourguignon 36:50
the new standard. You know, we talked about one two pizza teams. It's one two groups playing Exploding Kittens to me team. I think

Paul McBride 36:56
that's that's an effective way to limit your team

Tim Bourguignon 36:59
size. Awesome. coined it.

Paul McBride 37:02
Okay, in terms of what actually solve that? I don't know the answer. Talk to me in a year, I think and I'll have a better answer for you.

Tim Bourguignon 37:10
I'll take you on that just one eye on the clock. When did the training and giving knowledge and helping others grow? Enter your professional career?

Paul McBride 37:21
Good question. I think like, most of my career, I was self taught, right, which I'm doing air quotes, what that really means is community taught, right? I learned from other people being generous with our time. And to me, like that was just part of being a developer was helping teach other people because that's, that's how I learned. So it wasn't all natural, are weird are a big leap to to do that myself. Like you see the likes of Kent C DODDS. And whereas boss and stuff, those guys are super inspiring to be able to see, they're super generous with their time, they create great products, and they help a lot of people. And also they make bank and their three of my favorite things. So it's not a problem. Like it's not like any leap to want to go and do that myself. I was lucky enough, I got in touch with the fantastic folks at OCAD. Like I'd been making, like YouTube video tutorials. And quite honestly, they're terrible. I was like doing little jokes and kind of like sinking down below the camera when the videos ended. And, and that kind of stuff. But like I was that was back. This was whenever it es five es 2015 or whatever it was called the keynote. And we got the array methods where you could map and filter and that kind of stuff. So as critten little tutorials on those, because do you remember Did you ever watch funfun function yesterday? So I love that show? And MPJ? I think that is that's it was? Yes. Yeah, his stuff was fantastic. Like, funny entertaining. I used to love Monday mornings, and there just weren't enough Monday mornings. So I wanted to create that kind of content myself. And after creating a few of those I reached out to Egghead because I'd been a subscriber myself for a while. I was like, I think I want to do this. And they were kind enough to, you know, onboard me and help me start creating content with them.

Tim Bourguignon 39:04
Okay, how do you find ideas for for new trainings and your video, so you can do for a good?

Paul McBride 39:10
If you find a good way to do that, please let me know. That's the question. That's the hard part. Egghead have done this, right. I think most In fact, all of that has instructors are developers that aren't full time instructors. They're, they're working programmers, right. So we come across an interesting problems every day in our jobs. And it's being able to take the lessons you learn from the work that you're doing on real products. And being able to distill those down into bite sized lessons. That's I think that's the sort of that's the shtick of aircard. Right? You take working lessons, and that's kind of what I've been using for inspiration. Now. I say this like I regularly release okay, but it's been a little while. I've got some stuff in the works, but I haven't released anything for a while because work has been Monique

Tim Bourguignon 39:53
the weed sometimes yes, that's what I see as he as he. I'd like to come back to actually my birth First question, because it's still bugging me there was this period when you and you put your notice. And then you knew you had two years before you enter it. Would there have been one tip one advice? One, one thing that could have helped you better approach this this this very first experience getting toward web development at that time?

Paul McBride 40:19
Sure, I think the most important thing that you need to know as a developer is that there's nothing you can't solve with a well with a well formed Google search. And at the time, I thought searching Google was because I was junior. And because they didn't know what I was doing. And the longer I spend as a developer, the more I realized that one of the most important skills you can have as a programmer is knowing, like what to type into Google.

Tim Bourguignon 40:45
It's awful when you're missing one word, you know, there must be one word for except you just don't have it. You can search for hours until you find this, this this one word, and then you type it, and you have it. And they're lazy answer. But as long as you don't have it, you know, you don't have it. So you don't know what to do to know and you can turn around. That's really true. That's really, really

Paul McBride 41:08
true. Like, one of the the second job I had at the agency when I made the mistake with the billing hundreds of bins. So that was the first time that was a smaller team than the first team I'd worked for. And the guy, his name was Darren, he was he was my boss. And anytime I had a question for him, you know, I roll my wheelchair over his desk, and I'd be like, hey, Darren, how do I do this thing? And he would open up? Have you ever been to the website? Let me Google that for you. Super passive aggressive. So we talked about it, and he sent me the link. And I go back to my desk, and he came over with me click on the first link. And he's like, read that over and over and over again, until eventually I was like, hey, I can cut out the middleman here. And I can just Google that myself. That's a lesson that stuck with me.

Tim Bourguignon 41:51
Okay, pretty passive aggressive. Indeed, I try to refrain from doing this. Except when when people give me exactly the keywords, I would type in their question. And sometimes say, Well, you know, let me Google that for you. Type that in there. But yeah, now I'm really stuck. Personally, I've I've really had this this experience a few times where you don't have you don't know the right keywords. And then it just really stinks. Because as long as you really don't find anything, and you're you feel dumb, completely dumb, and learning how to to find what you don't know, to approach this to, to corner the concept. And finally, find the right keywords is really a skill you have to master. It isn't. And it takes years, it takes really long time.

Paul McBride 42:38
And as you get on with programming, you eventually start to internalize a lot of stuff, right? You don't need to go to Google for everything. But there is and I cannot stress this there is zero, Shem and Google and things like that is a skill. And it's Oh,

Tim Bourguignon 42:50
no, oh, no. Did you do find yourself sometimes googling form an address and concept and trying trying to find something that might be very topic that might be really related, but not the right one hoping that in this concept in this in this blog post or video, you will touch at some point, the thing you you're interested in

Paul McBride 43:10
Absolutely. All the time. And one of my favorite things to do when searching for a bug or an issue of one and two is to go to the GitHub repo for the library I'm using, go to the Issues tab and find the closed issues and hitting Command F and searching for the things I'm struggling with.

Tim Bourguignon 43:26
I did that yesterday. Oh, that's pretty cool. That's pretty cool. Fall. It's been a fantastic ride. Thank you very much for sharing your story.

Paul McBride 43:35
Yeah. Thanks for having me on. I've enjoyed gallium

Tim Bourguignon 43:37
OS. Awesome. Where would you the best place to find you online and then continue this discussion or start a new discussion?

Paul McBride 43:42
So I have my personal website, which is Paul mcbride.com. And I'm also fairly active on Twitter. And my handle on there is the pole McBride. And that's my handle across pretty much every social media. I'm on GitHub and that kind of stuff to

Tim Bourguignon 43:55
okay and on Egghead as well. That's why, okay, awesome. Anything else you want to plug in before you call it A?

Paul McBride 44:02
No, I just wanna say thanks again for having me. I've really enjoyed chatting with you,

Tim Bourguignon 44:06
my viewer pleasure. And this has been another episode of developer's journey. We'll see each other next week. Bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms to show appears on on our website, Dev journey dot info, slash subscribe. Creating the show every week takes a lot of time, energy, and of course money. Would you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate. And finally don't hesitate to reach out and tell me how this week story is shaping. near future you can find me on Twitter at @timothep ti m o t h e p or per email info at Dev journey dot info talk to you soon