Decrypt with Evervault: Paul Conroy from Square1

Listen on:

• Spotify
• Apple Podcasts
• Amazon
• iHeartRadio
  

In this episode, Liz talks to Paul Conroy, CTO at Square1, the UK’s leading Digital Transformation company. Paul is a pragmatic, solution-focused leader, combining a strong passion for great engineering with a wide range of commercial and managerial experience. With a lifelong excitement for computing starting when he was a child, Paul has had a variety of roles over his career like managing UK's busiest cinema to becoming a product development leader at one of Ireland's leading online brands. While most people might balk at the idea of sifting through obscenely large volumes of data to better understand trends in user behaviour, it’s one of Paul’s favorite things.

A few highlights from their conversation include:

• 05:06: How cultivating and developing empathy in a work context can benefit every developer
• 21:56: Why it’s more useful to “act on the customer’s behalf” and understand the real problem rather than just respond to requests
• 31:14: Ways developers can utilize the power of AI tools and assistants in their workflows
• 38:45: How the right tooling can help with implementation in a very developer friendly way quickly and easily

Listen to the full episode on YouTube or wherever you get podcasts. You can find Paul at conroyp.com, on Twitter @conroyp and on LinkedIn.

Liz (00:26):

Hey, Paul. How's it going?

Paul (00:27):

Not too badly, it's not too bad. Thanks. How's things?

Liz (00:30):

Yeah, yeah, things are good. Things are good. So, tell me a little bit about what you do and where you're currently working.

Paul (00:40):

Cool. So, I am the CTO with a company called Square1. We are a digital agency headquartered in Dublin. We also have offices in Spain and France and work with about 85 people around the world. So, my role is CTO. My background is as a developer. I've been based here in Dublin for most of my life. Yeah, so that's my background and where I got to where I'm today.

Liz (01:09):

Cool. How did you get started in tech?

Paul (01:10):

So I was lucky that as a kid, there were computers in the house from a very young age. I'm old enough now that those computers predated the internet back in the black and white days. I was lucky enough as a kid, that stuff just always clicked with my brain in a particular way. So, I'd be messing around, changing the characters in games just to see what way that would work, or building maps in the original Grand Theft Auto when it was the top down view, rather than the 3D walk around. So, I'm really showing my age there now, but I was lucky enough that there was always something there for me. So, I had that interest. So, I went to DCU, did a degree in computer applications, and finished that up and took a bit of a left turn after college.

(02:01):

So, a few of my friends went off to interrailing or jumping into jobs. I ended up being the manager of the busiest cinema in the UK and Ireland for about two years, which was a bit of a left turn at the time, but a very interesting life experience. But after about two years or so of that, I really needed to use my degree really and get back to computing. So, I applied for a job with a Daft.ie, a large real estate portal here in Ireland. They had an opening for a recent graduate, and in two years out of college, I was certainly stretching “recent” to beyond the point of plausibility there. But thankfully, they didn't look too closely at the dates on my CV and I snuck in the door there at a relatively early stage in Daft's development.

(02:45):

I think I was maybe the 12th to 13 person into the company there. Then over the years, that grew up into what ultimately became the Distilled media group at the time with sites like adver.ie, board.ie, the journal.ie as part of that group. As the company grew, there were opportunities for me. I grew from working as a developer into senior developer tech lead and stepping up in different managerial positions along the way. Then about nine years or so ago, I moved into Square1 with a couple of the guys that I'd met within Distilled, the co-founders. Ciarán Maher and Diego Solorzano were two guys I got on very well within Distilled.

(03:27):

They'd gone out to start Square1, so I followed them shortly after that. Then we went in Square1 and then Square1 has grown from... I think it was the five or six of us back then to the 85 or so people I mentioned there a while ago. So, that's a very short elevator pitch for me and my background and where we got to today.

Liz (03:49):

Yeah, I love the bit that you were talking about when you worked for the cinema. I am wondering, I think that I also have a roundabout path to tech. I love when I talk to other people that have that as well to learn about what they learned in whatever that role was that they've been able to carry forward with them. Yeah. So, I would love to hear, is there anything that you learned or experienced while you were working for the cinema that you've carried with you till today?

Paul (04:24):

Yeah, it's a great question. I mean, cinema is ultimately a type of retail job and retail job puts you in front of all kinds of different customers having all kinds of different problems and different questions and different challenges. It really helps you develop a very different kind of muscle in terms of the empathy for the customer solution and the customer problem. I think there's often a stereotype you see fairly or otherwise of developers who you go through college as a developer, you only ever work on code. When you're working in a real company and someone comes to you and says, "Hey, this user is having a problem with X, Y, Z," and the stereotypical answer is a developer takes off their headphones and says, "Well, just tell them not to be stupid. Tell them to click a different button or something like that."

(05:06):

It's a bit of a cliche, but I think once you're there at 10:00 on a Friday night dealing with five or six people who've paid an inordinate amount of money for popcorn and drinks and had a problem in the cinema, you're dealing with a very different type of customer. That face-to-face interaction I think really helps to put you into the shoes of someone who has a problem and try to see it from a different perspective and ultimately come to a different solution there. Empathy, I think, in a short roundabout way is something you can develop a lot more from those kinds of roles than when you are behind a keyboard and a screen and a million miles detached potentially from the people who are going to be using your product and ultimately acting as your customers.

Liz (05:49):

Yeah, I completely agree with you. I worked retail for a bit as well, and there is something that's different when you have to respond immediately to something also, right? I think sometimes we have this luxury of being behind our keyboards and having time to think about how we want to approach something. Even with that time and space, sometimes we don't always approach it in the best way, but yeah, there's something about that real time feedback and response that you have to have.

(06:21):

It was also when you were talking about that, have you ever seen that cartoon where it's talking about software development, but it's like they want to make a tire swing? It shows all of these different steps where it's like people are trying to communicate that they want to make a tire swing, and the product manager has a different idea of what it's supposed to look like. The developer has a different idea, and the end result is this monstrous Frankenstein looking thing.

Paul (06:50):

Yeah, that's exactly it. Yeah. Communication can break down very easily, I think, in those silos. Yeah.

Liz (06:58):

What was it like for you transitioning from being a developer into being a technology leader?

Paul (07:07):

Quite difficult to be frank. So, in some ways, I was quite well-prepared for it, because I had effectively been leading a team and leading large parts of an organization when I was in the cinema. So, I had some of those muscles or still working a little bit a few years later. But as a developer, my brain is wired in a certain way that when you're fixing a bug or you're building something, you're getting very, very quick feedback. I've deployed a website, I can see it, people are using it, or I fixed the bug, the bug's no longer there. Great. You get that dopamine hit in the brain that says, "Yes, I've done something useful. I've done something productive here." To be very frank, I struggled quite a lot moving into a leadership role.

(07:51):

When you're in a leadership role, it's not so much the work that you're doing as the work you're enabling is more important. You're helping the people underneath you solve problems, helping them grow, helping them deal with issues, and helping them improve in what they're doing. Ultimately, your success is an aggregation of their success. The feedback loop on that can be incredibly long or even not visible. If you're working on my team today, we might have a conversation today about a challenge you're facing and it might be lucky enough that it unlocks something for you. Six months down the line, you achieve a phenomenal result with that. I might not even ever know that I've had that impact or helped to do that.

(08:31):

So, getting the feeling of satisfaction and the feeling of having done something, done something productive is something I certainly struggled a lot with. I know I've talked to other people who've made a similar transition, and it's not an uncommon feeling when you're coming from that developer background that suddenly you have to find a different way to feel productive, to feel that you've done something. I remember early on when I'd gone into a leadership role, I'd be coming home from a day's work where it would've been all day, I would've been doing one-to-one meetings, maybe performance reviews, maybe helping with planning, maybe helping with all of these things. I wouldn't touch a keyboard for the whole day.

(09:09):

You're in and out of meetings. You're talking to people all of the time. At the end of the day, completely exhausted, batteries completely drained. I'm naturally quite an introverted person, so the energy levels are taxed quite a bit when you're talking to people a lot of the time. But you come home at the end of the day, exhausted, and feel I don't feel like I've done anything today versus when you're a developer and I built this application today and I built this widget. Oh, look at this cool animation I built, and you've done something there. So, getting that sense of satisfaction or that sense of I'm actually doing something useful here, that was a significant challenge for me. I mean, I say was a significant challenge. It's not necessarily a fully solved problem.

(09:52):

I still get this from time to time. I need to have maybe small little toy projects on the side where just occasionally when my energy levels are dropped enough, I know okay, I can just jump in here, fix this one small thing, get that little dopamine hit, and then okay, go back to what my real job is at the moment. So, it's certainly a big challenge. I know it's something that a lot of people going through that transition certainly have struggled with, because it's just a fundamentally different way of realizing your own value, of knowing what you're doing. Because I've struggle quite a bit thinking, I don't know what you'd call it, imposter syndrome or whatever, but I'd feel like, "Am I even the right person to be doing this? What is it I'm actually doing here? What am I doing here?"

When I speak to other leaders in the organization at the time, I'd be getting generally positive feedback. They can see I'm doing this right, doing that right, and things are looking all right, but it doesn't necessarily feel like it internally, because I'm used to the little pings in my brain of, "Okay, you've done this, you've built this, you've done that, you've done that." For me personally, in the absence of that feeling, it is definitely very challenging. Certainly, in the early days, it was quite difficult to realize that and to, I suppose, adapt my own sense of satisfaction and my own sense of the worth in the work that I was doing.

Liz (11:11):

Yeah, I can definitely see how that would be a huge challenge because it's also so data oriented I guess when you're doing an IC role. You can look and say, "I shipped this. I wrote this many lines of code, this and that." There's all these ways that you can really point to what you did, or like you said, this is live and now you can check it out. But when it is mentoring, encouraging, nudging people in the right direction, making big structural decisions or organizational choices, it's definitely a different type of way to measure. It's hard. It's funny, because in developer relations, that's what my job falls under. If you go to any developer relations type event or conference, there's always all of these talks about, "How do we measure success? How do we measure what we do?"

(12:14):

Because so much of the work is relationship building and community in addition to some things that are very measurable in terms of seeing how many people viewed what you wrote or downloaded the repo that you created or whatever like that. So, yeah, I think measuring success generally is just a really hard thing when you aren't in a role that's very oriented around a number that you can point to.

Paul (12:44):

Absolutely. When you're at one or two levels removed from the actual metrics that the business will rely on a lot of the time, it can be really challenging to do that. All right. Yeah, and like I say, not a solved problem. So, if you ever crack it, please let me know and yeah, would be happy to hear.

Liz (13:03):

Oh, my gosh. Yeah, you and me both. Maybe we'll both figure it out and then we can combine our strategies or something like that. You mentioned side projects, and I'm curious, are there any side projects that you've worked on that you found particularly interesting?

Paul (13:25):

That's a good question. Yeah, there's a few small things that'd be working on that'd be just scratching an itch in the business a lot of the time as how I would justify to myself, I'm spending a bit of time on this thing over here that isn't necessarily core. For example, we deal with a lot of, say, online publishers and news organizations, support organizations and so on, where things like the page speed of their websites is very important. Google provide you a lot of tools for assessing this on an ongoing basis, but a lot of them require you to manually go to webpage somewhere, paste in a URL, check the results, come back, blah, blah, blah.

(14:02):

So, one little side project we put together when we were working with a number of users who were trying to aggressively address a number of page speed issues over time. You want to be tracking these things fairly regularly and having someone manually remember to go in every day and stick this data in a spreadsheet somewhere isn't great fun for anybody. So, built a little project where we could go in, we could put in these URLs.

(14:26):

In the background, it would go away and fire up all of the different virtual machines it needed to do to simulate real world users, visiting these pages, getting the page speed scores and aggregating them and visualizing it so non-technical users can ultimately go in and see, "Okay, here's the impact we're having on the business by this line went up, this line went down, whatever it is." But that was something that could chip away at on the side. I mentioned things that chip away at on the side. A lot of time what I've found is that, again, coming back to my transition from a developer into a leadership role and where I am now and what I might tell myself at the time, initially, I found it was very important for me to keep my hand in with the development.

(15:06):

I'm still here in the trenches with you guys. I'll take these tasks on you. You take those tasks on and so on. As you go, the pressure's on your time. You can become the roadblock here on the critical tasks and holding the team back. So, with the side projects and the things I keep on the side when I need the occasional dopamine spike or a little bit of feedback, it's stuff that isn't on the critical path. If it's done, it's a nice enhancement or it's something that's going to help move things along, but I'm not blocking anybody. If I don't get to it this week, it's going to take me another a few days. It's not a problem. This current project was one like that where there's an unpleasant manual workaround or manual flow that was being followed by this particular user at the time.

(15:46):

If and when this automated system appears, then great, it's an improvement to everyone's life, but it's not blocking the thing from happening. So, that was one that got put together that worked reasonably well. It's still running away on a server and giving us the results we're looking for. So, that was one that went somewhere. My laptop is just a graveyard of new repos kicked off with a to-do list. I'm going to get round to this and get part of the way there. Yeah, just absolute graveyard of things in there.

(16:19):

Every so often I spin back through the list of them that are there and say, "Okay, well, someone else has built this since and someone else has built this since" and just started to tidy up the list a bit that way. But yeah, I keep lying to myself that someday I'll have time to sit down and just start hacking away at all of these speculative side projects, but haven't quite got there yet.

Liz (16:38):

Oh yeah. I feel like anyone listening to this can heavily relate to that practice. The other thing that I love is when you talk to people about the different domains that they've bought when they've been like, "Oh, yeah, I'm definitely going to build this thing. I'm just going to buy the domain for it now." Then you look back, you get the reminder that it's going to renew, and you're like, "That was a year ago that I did that."

Paul (17:04):

Reminder of shame. Yeah. Remember the great hopes and plans that you had for this domain? That was a year ago, or that was two years ago now. Yeah. Well, I convinced myself if I pay the domain renewal fee, that's a sunk cost now where I have to justify spending all of the time working on it to justify that $5 I've spent on the domain or whatever it is. Yeah, I know it's exactly what you're talking about.

Liz (17:28):

That can be a motivator. That can definitely be a motivator. I think that's a really good practice though, for folks who might be wanting to go into the managerial path, just having a practice like that where you say, "Okay, well, I'm just going to say that I'll contribute something noncritical. I'm just going to have this here for when I really need that." Because I think we all go through phases where the day-to-day just feels like a slog and you just need something else. So, I think that's actually a really good tip for folks when they're looking for something and when they're in that type of role.

Paul (18:10):

Cool. Yeah. Yeah, it's certainly something that worked well for me when I made the flip. Obviously, my initial attempt was well-meaning, but completely wrong and causing a problem for the team in the end. So, yeah, making the flip into I can be a value add when I have the time, I think, was a key difference there.

Liz (18:32):

I'm wondering about when you were talking about how you handle customer requests and things like that, I think that something that I've been noticing is a lot of developers and companies can find it challenging to decide, "How quickly do we want to integrate this customer request into what we're doing and how important is it based against some of our other things that we have that are really critical to get done?" So yeah, I'm wondering how you approach that, how you guys approach it at Square1.

Paul (19:13):

Yeah, it's a big challenge. As you say, you can get all kinds of requests from all kinds of different customers, and ideally, the ideal answer is that you have a very clear strategic roadmap. Everything your customers ask for, you've already thought, and it's on the roadmap somewhere. You might move the priorities a bit, but it's nice and clean that way. Reality, I don't think I've ever seen it work that well. I think when you're getting customer requests in, key thing is to understand what the goal is or the pain point is, because very often, depending on say the vertical you're working with, maybe you're very technical customers, maybe you don't, the way the feedback is given to you, sometimes you get say, hyper specific feedback from someone who says, "I'm trying to do X, Y, Z."

(20:02):

On this page, I want the button to say X instead of Y, and it should really be orange to stand out from this and it should do Y. You're getting hyper-specific implementation suggestions from the users. Sometimes they're valuable, but very often they're masking what the frustration is. So, the frustration in this case is, okay, it's not obvious to me how I need to do Y. Here's my proposed solution for it. So, trying to understand the what from the feedback, rather than how that may sometimes come through can be critical to identify, "Okay, what's the core pain point here?" Then you can start to see, "Okay, are we seeing this with this one particular user? Is this when we isolate what the pain point is? Is this something that's common to a number of our users?"

(20:45):

Okay, let's either revisit our roadmap or put it on there if it's not on there already. That's a challenge. I think one of the big challenges you can get, particularly in the early stages of a product company as well, is when you have feedback coming through from say, a very large user or very large potential customer, which may not be in the general interest of the product as a whole, but were in a position where this is a user we really need.

(21:12):

So, you're at an inflection point there where you start to say, "Okay, are we going to go down the road of taking what we're doing and making it hyper specific for this user who we know is going to pay us a certain amount per month and will give us six months more runway at least to figure out the rest or it'll be staying true to our vision that this is a general purpose tool which has a much larger addressable market?" We just haven't quite found them yet. In theory, you want to go with the large market, but in practice when you're looking at the payroll is coming due, you have a large customer who has money ready to go there. Now that can be a very difficult conversation to have internally and to manage what way you're going to address that.

(21:56):

It can be a big challenge of handling that feedback, I think. So, it's rarely as clean cut as let's take everything the users say, put them into a queue somewhere, and we'll just start chipping away at them one by one. I remember seeing a talk by DHH, the guy behind Rails before, and he talked about how Basecamp had handled feedback in the early days. He said it would be more act on the customer's behalf, if not specifically the request. You're looking at what the goal is or what the general pain point is, rather than specifically, you're not going to get your orange button on this page. Instead, here's a new wizard that should let you achieve generating the report or whatever it is. So, I think that's a key point is understanding the specifics of what you're being asked for there.

Liz (22:45):

That's such a good point, really trying to get to the heart of what the problem is, because I think sometimes too, especially I think because there are so many developers now, and I've found this myself when I am using a product, sometimes I'll get very nitpicky about the UI to your point, just all these little things that you're like, "Well, I would like it better if it did this," but at the end of the day, is that really a problem? Is it just something that would be nice if I had personally, or is it impacting the functionality? I think sometimes there is a functional problem. There is actually something that's not working very well, but it's like because that thing's not working well, you see all of the other things that annoy you and you might be missing being able to clarify what the actual thing is.

Paul (23:39):

Yeah. Yeah. It's the forest for the trees thing, isn't it? You've got this one core thing that maybe you don't even see it anymore because you've adapted your workflow. You're working around it and managing it in some particular way, but because of that, you're suddenly noticing this filter always behaves in a weird way. Why are these check boxes here? Or these small little niggles or things that feel like small niggles, but they're symptoms of the broader cause here that I'm in a state or a part of the application I shouldn't really be in when I'm trying to do this particular this task. That's the core problem that you want to identify and you want to solve. Yeah, absolutely.

Liz (24:13):

I heard you mention Rails earlier. Was that one of your primary languages that you used or currently use?

Paul (24:22):

Funnily enough, no. So, PHP is one of the main languages that we use within the company as a whole. We have a lot of different languages in use. We have some Rails, Native Mobile Development, Node.js, a lot of that stuff. But PHP and Laravel is our core. We've been doing this long enough to go through the whole cycle of PHP is dead, PHP is a toy language, PHP is rubbish all the way back to, well, PHP is actually the ecosystem around it. I think particularly with say, frameworks like Laravel and the way the package management system has evolved over the last six or seven years in particular, I think PHP got a very hard wrap when you look at large successful companies that have built huge things on top of it.

(25:15):

We've managed to build a whole business almost exclusively on PHP for a long part of that business. So, the reports of its death are greatly exaggerated.

Liz (25:28):

Yeah, it's so easy to get wrapped up in the hot and trendy types of frameworks and languages, but at the end of the day, it's like, does it work? Are the people that are working on it skilled? I worked on this project once and I felt really bad, because the most senior person that they brought onto it had never written Python and it was all in Python. At the time, I was still pretty new to software development. So, I don't know. I guess in my head, I'm like, "Ooh, this really senior person, that shouldn't be that difficult for them to pick up because they're so experienced and they're so smart." But it is really hard. It's not easy to understand. Maybe you can get to something that works, but to understand all of the things that a language can actually do, it takes some time.

Paul (26:25):

Absolutely, and real hands-on time as well to do it. I think we've been lucky enough over the years, we've worked with a huge number of really talented developers. I think when you're talking about that case of say, the senior developer who is maybe not necessarily experiencing the technology you're using today but is coming from a very strong background or maybe is very experienced in a different type of technology and you're wondering about transferable skills. We've seen it go two ways in the past. You have developers who have just a generally good technical background. Maybe they've spent all of their time working with PHP and now it's going to be Rails or it was Python. I don't know. We're going to work with Go or something like that.

(27:07):

At a high level, they understand algorithms, they understand the core concepts and translating the language from one to the other. Yeah, it's a bit of a speed bump. Then the real time that they're taking to spin up is exactly what you described there as the idiosyncrasies of each platform to say, "Okay, well, I know the way that PHP handles request caching, but I need to know exactly what way Rails is going to do that, the language or the quirks or the oddities of that. They're the bits to pick up. On the other hand, we've also worked with people who were say very senior, very capable developers in one particular technology, but what they had done was they had effectively ingested the idiosyncrasies of that technology without necessarily having the same level of understanding.

(27:48):

So, when you bring them into another technology, their base level drops very, very quickly because they're spending all of their time saying, "Okay, oh my God, how do I Google for the Rails equivalent of the Laravel request validation, blah, blah, blah, blah, blah"? Because the core concepts behind it are not hugely clear in their mind. The Laravel specific implementation, they probably do in their sleep, but it's very, very set in that zone. So, those people I find have a much harder time transitioning from one to the other at anything close to the level they were before. So, that's certainly been a challenge. We've worked with people from both sides there or both levels of experience going through that type of transition. So, that's been an interesting one to see, I think, because it can be quite hard to identify that gap beforehand, but it's certainly something we've come across a few times.

Liz (28:47):

It makes me wonder what things will be like as things like Copilot and ChatGPT keep becoming more ubiquitous and just generally better and more usable, because I do think it would be cool to see a world in which it could bridge some of those gaps so people could just context switch more easily.

Paul (29:11):

Absolutely. Yeah, I mean, we've been looking at a lot of those tools ourselves internally. I think what's interesting about it is that I think at the current level that those tools are at, I'd certainly be more comfortable putting them in front of more senior developers, rather more junior developers. Take Laravel, for example. I was trying to solve something with a console command recently, and I had it in the back of my head. I vaguely remember, I know there's a way to do this. There's a structure or there's something that does whatever I need, whatever command argument or whatever I needed. I couldn't see it in the documentation. I'm convinced I've written this maybe some years ago. I know I did at some point.

(29:52):

So, it was in ChatGPT, I was asking it, "Okay, is there a way of doing this?" It came back, says, "There is, happy days." So it produced all this incredibly verbose code exactly stuff. I went in and it looked right. It looked right. It rang a bell and looked close enough to what I was trying to do. Went in, pasted it in. No, it didn't work at all. It was referencing functions that didn't exist. It was doing all kinds of crazy things because what it had done was it had taken, say, some of the documentation for say some of the testing in Laravel, which syntactically looks similar. It had just transposed and said, "Oh, actually, yeah, this thing here is actually this thing." It was something which, okay, I was able to get to the bottom of it quite quickly because I could recognize the errors.

(30:35):

I knew myself, okay, maybe there's something a little bit off here. I could identify that quite quickly, but I could see a scenario where a junior developer is given that code and effectively is looking at it and is wasting the guts of a day trying to figure out, "Is it me? Is there a bug in the framework?", all these kinds of things that you don't have the experience to say, "Hang on, I'm going to treat this AI assistant as effectively a junior to mid-level programmer myself, where I'm not going to trust everything they come back with. I'm going to have to validate it." So that's where I think at the moment, those tools are more useful for more senior people who know, "Okay, this is maybe 70 to 80% likely to be correct, but I know I'm going to have to dig in here and tweak it or do something with it."

(31:14):

So there's a lot of potential for them. I love the idea of, for example, being able to go in and say, "Here is my user storage class in Laravel. I need to do something very similar in Rails. So, what would that look like?" Or something in Python with this particular framework or whatever. Give me that mapping. Coming back to the two types of senior developer we talked about earlier, someone who understands the core concepts, you can figure out, "Okay, so that's how Python structured this, or that's how Rails structured this." Again, 70 to 80% chance it's right, 20, 30% chance it's not. But at least you can be taking the error messages and you're further down the funnel of figuring out what's gone wrong here and how can I figure it out based on your experience and your background.

(31:59):

So, I think there's still a level where I would be nervous about putting it in front of people who are relatively new in their career, just from the high likelihood that they're likely to spend more time chasing shadows than actually getting the benefits versus more senior people who will be taking advantage of the boilerplate generation and those kinds of time savers, which I've seen in my own experience. They can be quite significant quite quickly. I don't know about you, but there's all kinds of little things. I end up Googling them all of the time because they just won't stick in my brain, whether it's particular format. The links, they're always purple in Google. I always know, "Okay, yeah, I've been here 87 times before and it just won't stick in my brain."

(32:39):

Those are the type of things now where I'm finding the Copilot extensions in VS Code. I write the comment and the comment is even shorter than the Google query. Suddenly, the code is there and it's been 90% there. It may be a bit of a tweak, but that's saving me bounce out to the browser, do the query, click the link, copy the code. It is not a huge time saving. It's maybe a minute or whatever, but it adds up and adds up very quickly and keeps me in the flow. So, I think from that side, the AI tools are looking very powerful at the moment, but again, with that massive caveat over them that you can't trust everything that comes out of them. They're like a very willing and enthusiastic low level assistant at the moment, I think, is how I'd look at them.

Liz (33:23):

Yeah, I completely agree with you because I think that if I'm thinking back to what it was like for me when I was learning how to code, I remember I would look up tutorials of things and be like, "I'm so lost. I'm already so lost." I think that if you had something telling you this is how you send something to S3 with the AWS SDK, and it gave me the wrong thing. To your point, it would've just been taking up so much time trying to sort out this, "Is this how you do this?" Looking at the documentation, and it would just be taking up more time than it would've to just learn it from the beginning. So, I agree. I think there's certain cases where it's very useful. If you're more senior, you know what to expect.

(34:15):

So, when you see something and you're like, "Oh, yeah, that's calling a method that I haven't imported from anywhere." Obviously, that's wrong. You can spell that and catch it sooner. The other thing that I find interesting that I've been paying more attention to is the security implications of what these tools might have. In the vein of what we're talking about, if we just start cobbling together different things that we've generated using large language models, even if it works, there could be security issues if you're really not thinking about how you're building something from that perspective. So, I'm wondering how you all think about security at Square1 and what your approach is there.

Paul (34:59):

Yeah, I mean, security is a huge challenge, and it's a critical one. We deal with all kinds of different platforms, all kinds of different clients, storing different types of information, whether it's personal, financial, whatever, all kinds of critical information. Figuring out how to store it and how to store it securely and safely is a big challenge because you have application design challenges. You're going to have infrastructure management. You then have monitoring. You're going to have your own policies internally for how people should and shouldn't behave. There's checking in on that. There's a whole world of things that need to be taken into account around security because just the potential of any breach is just nightmare fuel if and when something goes wrong.

(35:43):

That's purely from even a reputation or business perspective before you even start to look at the regulatory impact under the GDPR or whatever of potentially leaking sensitive information. So, in an ideal world, you can't leak data if you don't have it. So, ideally, you don't want to store anything, but practically, that's not the case. So, very often for us, we run into challenges when we're talking to, say, a user who wants to build an application, and you're collecting a lot of information from people. So, we're talking about, "Okay, how we're going to store it, how we're going to manage it internally." The way that you may do encryption can impact on your functionality for example.

(36:19):

If you want to do a partial email search, it gets very computationally expensive if you are encrypting your data internally versus you've stored that all in plain text, yet people can search and do what they like, but you're potentially increasing your risk surface there quite a bit. A lot of the time we get users who say, "Okay, well, we want to get this data and this data and this data and that data," and say, "Okay, well, what do you need all of that data for?" Well, just in case. Maybe we need to target them by gender down the line or something like that. Just in case are the words that just send a shiver down my back when we're talking about applications.

(36:58):

Thankfully, that has dropped a little bit over the couple of years since the GDPR came in, but it's still relatively common that we want to gather as much as we can and then we'll figure out what to do with it later where it's challenging. I mentioned I worked on a classified site years ago, and we at the time were dealing with payment handling. This was before the likes of Stripe or any of that came along. So, it was all direct implementations and the credit card information would come into our servers and then would be passed on and so on and so on, which meant that we needed to get a PCI certification.

(37:32):

Going through all of the paperwork involved with that, all of the processes, all of the overhead monitoring, the recertification, huge time sink, huge drain on everyone involved, which means you can't be doing other things that are adding value to the business while you're effectively ticking these boxes that need to be ticked. They're important boxes to be ticked, because they're protecting secure information, but at the same time, you've a roadmap at the length of your arm that needs to get built for new features, and you're spending your time on this internally. So, when the likes of Stripe came along and said, "Hey, that credit card information, let us worry about that. It's not ever going to touch your servers."

(38:08):

Godsend. You can't lose information or you can't leak information that you don't have. What Stripe have done with credit card information, whatever vault you're doing with pretty much everything else, take that information. Just don't let it go into our systems and let us access it. Sure. But the security and the safety sitting with people who this is their job, this is their main job, they're going to be better at this. They ever will be. It takes a huge load off when we're designing applications and building applications to say, "Okay, here are these trusted partners who know what they're doing. They know this stuff inside out. They've forgotten more about cryptography than we'll ever learn. They know all of this stuff.

(38:45):

We can implement it in a very developer friendly way quite quickly and quite easily. It's a godsend in terms of our application design, because yeah, the potential for leaks and the potential for data getting out is scary stuff. The number of operational processes and stuff you need to have around that. Even with these providers like Evervault or Stripe, you still need to have this best practice internally, but it's good if you pulled off to be able to say, "Okay, well, the really, really critical stuff, we know where that is. We know how it's controlled, and we know what the risk pattern is around that." So that's a huge, huge thing for us.

Liz (39:21):

Yeah, absolutely. I think that there are so many different aspects of security that developers, security teams, tech companies have to worry about. The more that I am spending time in the space, the more that I am realizing just the number of ways that an attack can happen and the number of ways that we just underestimate. People are very creative in a very scary way. So, yeah, it's hard to manage, right? It's hard to balance these things, but I do think it's very interesting the number of companies that are starting to take off that focus on protecting one single area. I mean, I think Stripe is such a good example of choosing one thing to focus on and A, be really good at it, and then B, do it very securely. It's such a trusted name and such a trusted brand.

(40:22):

But yeah, hopefully, we figure more of these things out as time goes on. Yeah, Paul, this is such a great conversation. It was really lovely hearing just about your experience becoming a leader, going from being IC developer to being a tech leader now, and the things you've learned along the way and all of the PHP bits as well. So, is there anything else that you'd like to share before we go?

Paul (40:51):

No, I think that's covered a lot of it. No, just thanks for the time today and thanks for the opportunity to come on and have a chat. It's been great.