Breakeven Brothers

Bradley Bernard (00:11)
Hello everybody, welcome back to the Break Even Brothers podcast. We're on episode three. My name is Bradley and here with me is my co -host Bennett. Bennett, how was your weekend?

Bennett Bernard (00:22)
It's really good. Too short as they always are it seems. And I remember what I even did yesterday. It's just so unbearably hot in the Phoenix area that you just sit inside all day. So don't remember what I did yesterday, but it was, it was nice to lounge around. And then this morning was a great F1 race, which was really cool. So really a good race and good way to start the day. And then after that it was, went to the pool for a little bit, but even the pool.

Bradley Bernard (00:33)
Ouch.

Thanks.

Bennett Bernard (00:47)
The water was hot, so it didn't even feel like you were getting any kind of, you know, comfort from cooling off in the water. It was still hot. So yeah, I felt like I was in a jacuzzi and the air is 105 degrees. So yeah, we're just trying to live. We're just, we're just getting by right now out here. How was your weekend?

Bradley Bernard (00:54)
It was like a sauna for the pool.

Damn. You're really selling it.

Pretty good. yesterday I went to Malibu. I did a little day trip out there and it was fun to explore. But it was also hot. I didn't really expect it to be that warm. We don't have the 100 degree weather, but the 80s and sunny down here, which is great. But once you're outside all day, I feel like I was really sun exhausted.

So kind of random, no, no real reason, just exploring the area.

Bennett Bernard (01:23)
Okay.

Cool, yeah, nice. Easy drive up there.

Bradley Bernard (01:32)
Yeah, not bad. Like an hour 20, I think. On the way back it's like an hour 40. The usual traffic on 405.

Bennett Bernard (01:41)
Yeah, yeah. Can't avoid it no matter what time of day, no matter what day it is. It's always there.

Bradley Bernard (01:45)
how was your July 4th?

Bennett Bernard (01:48)
It was good. It was just super hot. So we didn't do anything really until the sun went down and then we had just like a small starter set of fireworks to kind of get the kids excited about. So we did that in our street, but then our neighbors had like the ones from south of the border that are just the mortars that go up into the air. So got to see that, which was pretty cool. So yeah, it was good. It's weird. Weird on a, it was on a Wednesday, I think, right? Or it was on a Wednesday or Thursday, whatever day it was.

Bradley Bernard (01:56)
Okay,

You

That's cool.

Wednesday, yeah

Bennett Bernard (02:13)
Yeah, I just split the week. So it was weird having that day off, but you know, I'll take a day off. So don't get me wrong.

Bradley Bernard (02:19)
Yeah, it doesn't hurt, it doesn't hurt. Thursday, my bad. I'm bad at calendar, Thursday. Yeah. Don't ask me, I'm self -employed. I don't know what day of the Yeah, I asked my partner, I'm like, you have a day off? Okay, so do I. Cool. So yeah, let's jump into it. So today we wanna talk about...

Bennett Bernard (02:21)
Yeah.

Is it Thursday? Okay.

Yeah, it's someday ending in Y, that's all you know.

Bradley Bernard (02:41)
What can engineering learn from accounting and what can accounting learn from engineering? So we bring our kind of expertises together and I think we can dive into a few topics where I feel like engineering has their own kind of processes and little tidbits of how we do things. And then on the accounting side, some of the details of day -to -day work and setups there can also kind of help the engineering side rethink things. So kind of wanted to kick it off a little bit.

Bennett Bernard (03:07)
Mm -hmm.

Bradley Bernard (03:10)
From the engineering side, one thing that comes to mind is I feel like when I think of accounting from the engineering side, I think tons of precision and attention to detail. For the engineering side, we care about the details, but maybe not as much as the raw financial numbers. You don't really have room for mistake there.

Bennett Bernard (03:28)
Yeah. Well, I think too, you know, we talked a little bit in other episodes about my own kind of forays into programming and engineering, just kind of more as hobbies and skills, but not as a career, of course. But I think, you know, one thing in particular that always was very impressive to me about engineering and maybe this is going in a different direction than you started, but I think we'll come back to the kind of precision element. But the first thing that jumped out to me right away was how much available is there available to learn for free?

Like you could just go to the docs, you know, so for those that don't, that aren't technical, you know, most of these like programming languages and the related kind of libraries or, modules you'll use are just publicly posted and shows how it works. Like it's called open source again, for those that are not technical in nature. And it was always super baffling to me that that was just like out there and free to, free to use, you know, free to go and, you know, get resources if you were interested in learning it.

Not just that, but then also there's a ton of like courses, like MIT does like open courses where you can just sign up and learn computer science classes for free, you know, just, and so I think that lack of paywall is super contrast to accounting where, you know, I, you have to take the exams. Well, first of all, we'll get into credentialing later because credentialing is a big thing. That's a big difference too. But if I just want to get a topic, like a book about how to

Bradley Bernard (04:43)
Huh.

Bennett Bernard (04:54)
account for banks. I got one right here on my page. It's a ICPA. Yeah, yeah, I have a handy. This is not a setup. But, you know, this probably cost me like 120 bucks, I want to say. And, you know, I could have googled it. But like, why? And maybe I might show my ignorance a little bit here. But if this is available online somewhere, and I just don't know about it, then correct me. But pretty sure it isn't because I think that's the thing that people make money off of these kinds of books.

Bradley Bernard (04:57)
I love that, he's ready.

Bennett Bernard (05:22)
And so anyways, point being is that like just the widespread like distribution of information for free for like everyone to use is a big difference to me. Whereas like accounting, we very much kind of gatekeep and like paywall that knowledge. and so, you know, yeah, it's probably a very, very big difference from what you're used to, at least in terms of, you know, resources and things that you see out there.

Bradley Bernard (05:47)
Yeah. How I started was even just searching YouTube for coding tutorials. Like when I was learning PHP, all I did is look up, how do I build out PayPal payments in PHP? How do I build out a user registration system in PHP? And thankfully there was so much out there that I could piece together these video tutorial content to make like a pretty good system. I mean, I really didn't know how to code back then, but it felt to me that I could make meaningful progress for free.

in a way that's really accessible. I really love the video content. I think I've transitioned more to be a reader now, but back then it was my whole YouTube recommendations was like either gaming or like PHP tutorials. And there's so many people to thank along the way. there's Jeffrey way and the Laracast side. There's Alex from code course. I think his name is, but there's so many people that put out all this free content, probably have ads on YouTube, but it's, it's really.

just to share the knowledge and get people to where they need to be. And I'm thankful for that. I think the open source on top of that has provided so much value. Like you could just download software for free. People have spent tons of time building and you're off to the races. So I sad to see the paywall situation on the accounting side. I think that's not great. And I think software engineers have a leg up on having so much stuff accessible. I think it was accessible 10 years ago. And as you mentioned, all these courses started popping up.

Udemy, I mean, some are paid, some are free, but there's still so much out there even for a cheap buck to learn so much.

Bennett Bernard (07:18)
Yeah. And I've used Udemy. I used it for, and I'll link a couple of the courses I took actually, for those that are interested, because I use it for databases essentially. So like SQL working with Postgres, I use it for Python, of course. And I've used it for other things too, like just copywriting, math. I didn't complete the math one just to be completely honest, but I thought it looked, sounded really cool. Yeah.

Bradley Bernard (07:24)
Mm -hmm.

That's okay. A lot of people buy the courses and they don't complete it. I am one that I probably bought 10 courses in the past five years and maybe, three out of 10 I haven't completed. And I was so excited to buy them and I just didn't get around to it. It's not that the content isn't good. It's that I just haven't had the time for it. So I think building a course is so lucrative in that regard that people just, they know they want it, but are they actually going to learn it or, and use it? I don't know. Not a hundred percent.

Bennett Bernard (07:47)
Yeah.

Mm -hmm.

Yeah. The, the course sounded really good. It sounded awesome. I didn't, I didn't complete it, but it was like a math business. It's like mathematics or business analysis or something like that. I was like, this is super applicable and I will use this. And I didn't, of course, but yeah. And even then, like you said, there's some stuff that's paid, but like, it's honestly, it's, it's also so affordable. You know, I think Udemy courses can be had for like $9, $10 sometimes, you know, when they're on sale, they're always on sale. So don't ever buy one that's fully priced.

Bradley Bernard (08:18)
Hmm, okay.

Mm -hmm.

Yeah.

Bennett Bernard (08:35)
But yeah, because you can get it for like, normally it says like a hundred dollar course, but like buy it for nine dollars. I'm like, why would you ever buy it for the full price then? But anyways, yeah, there's just so much good information out there. Even if it is paid, it's still cheaper than again, than whatever this hundred dollar book was that I bought. And it's a great book, but like, yeah, a hundred dollars. It just, you know, so the like, again, the widespread availability of information is a big difference for sure.

Bradley Bernard (08:42)
Mm -hmm.

Yeah. I feel like for the engineering side, there's a culture of like continuous improvement. I don't know on the accounting side, but on the engineering side, there's a new framework, a new language, a new tool to pick up what feels like every other week. And when you're at some of these big companies, you might not notice it, but when you're out in the indie hacker space, there's so much stuff that is flavor of the week, flavor of the month. It gets overwhelming. And like, I love having the options, but it feels like you need to stay on top of it and

be the expert of all these new tools. Because if you aren't, everyone else is talking about it and you feel like you're an old timer that's out of the loop.

Bennett Bernard (09:38)
Accounting is different, of course, which I think is a good thing because I think with accounting, you were there to kind of provide like a standard set that people can get used to. And that's not going to change and make things like, the year is 2024. The way that we account for things is much different than that was in 2022. So you can't really compare apples to apples. And it's just too much for at the end of the day. Financial statements are produced for investors and like for owners of companies.

Bradley Bernard (09:55)
Mm -hmm.

Bennett Bernard (10:05)
And so if that is constantly changing and like pushing the envelope, I think that's a bad thing. So I think rarely, I think accounting is good in that it stays pretty static. There's not a lot of, like there's, there's developments, but it's, I think always aimed at like, the goal is to provide more like transparency and like consistency. It's not to like, you know, reinvent the wheel and like push the boundary. I think that, and that's just such a big difference from engineering where.

Bradley Bernard (10:27)
Mm -hmm.

Bennett Bernard (10:31)
Yeah. A new framework comes out. It does everything in the browser or whatever, you know, some decreases the processing time by X amount of percent or whatever, you know, it's just a different, different objective for sure.

Bradley Bernard (10:41)
Mm -hmm.

And like, there's all these people that are using these existing tools, throwing their hands up saying, I just want to make something else. And it's scratch your own itch. Go make this framework. You know, everything that sucks about this other one. I want to make it better in this new one and try to get all this adoption. So it's a constant cycle of, you know, out with the old and with the new. Will it stay? Will it go? A lot of people kind of hold their tongue and wait for a few months or years and you land on something good, but it's nice to hear that there's some stability because sometimes I get a little caught up with.

feeling overwhelmed at how much there is out there on the tech side.

Bennett Bernard (11:14)
I remember I was like on some forum or Reddit or whatever. Everyone is telling me go, like you got to learn Rust. Like Rust is it. That's like, that's like the new, that's the new frontier. It's got like better memory management and it's like compiled and this like, so they were like selling me on it. That's probably like 2019, 2018. And like, you know, I was like looking into it. I never like bothered to learn it because it just.

Bradley Bernard (11:23)
Mmm.

Mm -hmm.

Bennett Bernard (11:41)
I don't need to be writing like system programs. You know, I'm again, I'm usually working with spreadsheets and very basic coding compared to like, you know, what you guys are doing. But I went back and looked at rust probably like last year, and it seems like it's gone off completely off the rails. And I'm not sure if you're involved in or aware of those stories at all or like what's going on. But I was like, wow, good thing I didn't spend all that time. Well, I would say that I'm sure there have been pauses to take from learning that. And I'm sure it's still like usable, but it seems like.

Bradley Bernard (11:43)
Mm -hmm.

Huh.

Mm -hmm.

Bennett Bernard (12:10)
I guess to throw a point in for open source, it seems like they had a little bit of a drama over there. And it's not as hyped as it used to be.

Bradley Bernard (12:19)
Interesting.

I haven't heard of that. I mean, to be completely honest, Rust has always been super hyped because it's like the successor to C and C for those who aren't aware, it's like the low level systems programming. You can think of like programming microcontroller or some really small circuit board. You can also bring C to other applications, but it's pretty hard to write good C code. There's a lot of things that can go wrong. Rust comes out as that evolution of like.

We have memory safety. You're not going to have bugs or crashes that you'd have in C a lot of this stuff is taken care of for you. So I believe it was super hyped. All these tools are being rewritten because they were written in JavaScript. Now they're going to rust and the conversion from JavaScript to rust, the speed improvement, raw speed improvements, maybe like 10 X. I don't know what it actually is, but it's an order of magnitude that people are going to say, it's worth it.

So from my point of view, I haven't touched it really. I maybe wrote a little bit of code in it. It feels very modern, powerful, but also complicated. It's a very specific, like detailed language that you have to be like a very passionate programmer to pick up. It's not like Python or PHP. It's not as approachable as these languages that are simple and straight to the point. Rust is you got to know exactly what you're doing. You got to be careful in the way you do it, but we help you a lot along the way in terms of memory management and safety.

So I haven't heard of the drama. I'm curious what that is, but there has been a lot of work in converting these tools to rust and companies have made products off of it. So I think it's done well. But there was definitely a lot of hype.

Bennett Bernard (13:45)
Yeah.

Yeah. Yeah. And it's great point about C and you'll know this better than I do, but I'm pretty sure that, you know, Python as approachable as it is, and as widely used as it is now, especially it's core Python is C right. I think people will need to like, should know that, right? Like ultimately Python is like to not get too technical. It's like an abstraction or like a decoration of underlying C code, which, you know, I remember when I found that out, I was like, I don't

Again, I'm not a technical person, but I was like, I didn't even know that was possible. I thought it was like its own separate thing, but you know, point point being that there's so much. Base and see that, you know, and again, I don't think anyone would recommend a casual person to learn C, but, it's good to know what it is. And yeah, they definitely are pitching rest as the, like you said, the air and, see, yeah.

Bradley Bernard (14:27)
Mm -hmm.

Yeah, it's the end all be all performance, you know, king. But yeah, I haven't used it. I think it's, yeah, it's good. I was gonna ask, have you done anything in R?

Bennett Bernard (14:55)
So I remember when I was starting off programming, I had dabbled in like, what would it, why should I learn R like, should I learn R? So a very popular distribution of Python is called Anaconda. I think, I haven't used it in a long time, but it was basically like a packaged data science. Like library that like really relied on Python. And I think they also had some stuff about R. And I remember when I was at loan Depot, the team that was

Bradley Bernard (15:03)
Hmm

Bennett Bernard (15:22)
doing all like the super complicated, like mathematical analytics on our mortgage servicing rights portfolio, which is like a derivative asset. So it's super complicated, fair value. They were like doing things in our, so I was like, that's pretty cool. Never like went down the path of learning it because as I kind of like researched it more, it was like, this is really for like almost like math and like data science, but like super heavy on the math emphasis.

And I was like, I don't like math, so I'm not going to go down that path. And it was so, and also too, one thing I found really interesting about R was that the syntax was very unique. Like I can look at PHP, I can look at Python. What else have I looked at before? Like Go, and I can kind of tell what's going on. R, it was completely foreign. Like they use like dash and arrows. Like it's completely foreign last time I looked at it. So.

Bradley Bernard (15:51)
Me

You

Bennett Bernard (16:16)
I remember seeing that and I was like, this looks like a really steep learning curve. And, you know, again, for me, doesn't make sense to.

Bradley Bernard (16:22)
Yeah, I think it was on the visualization front. I've never used it either because I felt the same about very mathy. There's better visualization tools that I've used as an engineer. like I feel like my engineering work is partly building out charts and that's using these open source charting libraries, like charts JS or other ones that I'm fetching data from my backend, pulling into a chart, like showing that I think the R side of things is more.

Like you mentioned, running some complex math calculations, seeing how that plots on a graph, not super relevant, I think, for us. But I think the visualization part can be really helpful. How much are you guys doing visualization in the accounting world?

Bennett Bernard (17:03)
So I actually have a draft blog post about this because, and I don't, I don't mean for this to be controversial at all, but I don't think accounting needs a lot of data data visualization. I think it's probably over, overemphasized a little bit or we make too much of it. Yeah. I think, you know, I can't think, and this is just my own anecdote, of course, but I can't think of a time where I looked at a visualization and it told me something new that was critical that I didn't already know.

Bradley Bernard (17:06)
Beautiful.

Hmm.

Hot take.

Bennett Bernard (17:32)
I looked at like a chart, like those geography charts where it's like, our revenue is from these customers here. And you're like, I have some revenue from someone in the Philippines. I didn't know that. Like, but like it's trivial, you know, it's like, okay, cool. I move on, move on with my day. Yeah. I think if you truly are someone who is close to the data and you have expertise in that area, a data visualization should just kind of tell you what you already know. So maybe I haven't seen.

Bradley Bernard (17:33)
Hmm.

-hmm.

Right, right. No big ideas.

Mm -hmm.

Bennett Bernard (17:59)
Like the right reports, you know, I will say that in, you know, Tableau and Looker, they all do a really good job of like creating these really dynamic visuals, but you know, you click in a little bit and you're like, I already know what this is. Like, it's just telling me something I already know. So I don't think accounting needs a lot of data visualization, at least in this, in the frame that we are used to seeing it. I do have some thoughts on what it could be, but that's not, that's not what the conventional, you know, path is for like accounting.

Bradley Bernard (18:22)
I see.

Bennett Bernard (18:29)
like data visualization for like accounting data, basically.

Bradley Bernard (18:33)
I don't necessarily know if I pull up new insights as more as the engineering side, showing data in a way that's easier to digest where I'm imagining accounting data being, you know, full of lots and lots of data being summed, aggregated, et cetera. And if you're close to the data, like you mentioned, you can probably understand it, but if you have to go present this data to a higher up or like a different cross -functional team.

They might not be so interested in, you know, the raw calculations of more like, how can I extract insight from this data quickly? And I feel like that's where the charts shine. for me in doing engineering work, I think charts have existed for so many different reasons. Like I build charts, but also talking to other engineers, for example, there can be like a dependency graph. So when you build out iPhone apps, you can graph your dependencies and see how heavy things are. So you could have a table that says.

You know, I pulled in this open source code package, maybe it's two megabytes of code and I pulled in a different one. That's, you know, maybe one megabyte and you work on this graph so you can see and dive into these individual open source frameworks and see the weight of the app and how you can reduce like binary size. So yeah, you can have that in a table, but to me, I love these visualizations where like I'm clicking into it, interactivity is there, the insights are that I could probably digest it in a different way, but I found that to be.

quite incredible when you find the right chart that fits the right data.

Bennett Bernard (19:57)
for the context or from the use cases that I've seen, I think that the focus has been, I guess, wrong or just not as helpful for me again, just personally, but to the point of like, you know, giving something to executives and like having a nice visual for sure that can land. I think one thing that I've found in just my own working years though, too, is a lot of times, you know, executives, you have to know your audience. Of course you might have an executive that loves.

Bradley Bernard (20:06)
Mm -hmm.

Bennett Bernard (20:23)
the data and like wants to be in the data with you. And that's totally fine. But you would approach that, I think differently than someone who's like, give me the quick and skinny and then like move on. And it's like, you know, I think a lot of times the hire that I've interacted with, they tend to be more like, tell me what I need to know. And then like, you know, you don't need to like convince me of it. You know what I mean? But certainly, especially when you're like presenting or like trying to convince somebody or something, it's good to have.

Like a visual and like kind of like it can hopefully it can encapsulate like the idea you're trying to present. But a lot of times accounting is keeping score. You know, we're trying, we're counting is recording what's happened. And so a lot of times I think that message. Like that might come from other teams, you know, like from like a finance team that's more forward looking like, Hey, we need to go do this project because it's going to give us this ROI. And here's a breakdown of that accounting in the traditional sense is usually again, more of a historical look.

Bradley Bernard (20:49)
Mm -hmm.

Bennett Bernard (21:17)
And so like the information, all the events have already happened. Like, you know, it's already happened. So I think a lot of times all that data or all that information has already been kind of processed by people. I will, I guess, go back on one thing I said earlier too, is a lot of the accounting data has been like, or the kind of counting visualizations have been like a trend of like revenue over time. And again, I think that's all data that people, you know, it might be helpful to look at.

Bradley Bernard (21:22)
Mm -hmm.

I'm gonna go to bed.

Bennett Bernard (21:45)
I think where I go is a data visualization worth it is if you can make one really quickly, then sure, then make it. But a lot of times those kind of take some time to make, at least in my a Tableau report or something. And so are you getting more out of it to justify spending that time or can you just do a pivot table in Excel and just get the same information? Okay, cool. Moving on to whatever else I got to do. So

Bradley Bernard (21:53)
You

yeah.

Mm -hmm.

Bennett Bernard (22:11)
I think from that, like setting, that's where I've found the most like criticism for myself of like, is this really worthwhile? Actually, we really be investing this much time in these tableau reports or like, can this just be something that we can do quicker and easier a different way? So yeah.

Bradley Bernard (22:27)
Yeah. I love that. I feel like that ties in with automation and like balancing costs and time, because like we talked about in our last podcast episode, I've done a lot of automations and they've been a lot of fun, but have they ultimately been like the most effective use of my time? And so I think from the engineering side, you really have to take inventory and double check on.

priorities of things. There could be very flashy projects that pop up that you get super excited about, but what's important to the business? How long will it take? What do you need from other teams to get it done? And how can you prioritize that against like every other team's roadmap? It's, it's easy to like quickly jump into something and say, you know, it's important to my team. Let's go commit to other people. But I feel like the, the higher skilled engineers really can balance, prioritize and communicate with other teams saying like, this is important.

So I think if you can draw a parallel to the accounting side, cost benefit analysis. Can you run me through what that means?

Bennett Bernard (23:27)
I think that's universal for like anything, not just accounting. I think accounting is of course the financial sense of it, but you know, how much time is this going to take us or how much time does this currently take us? And you know, what is the alternative? Like how much time can we get back or how much are we spending where we feel like we can get back? So, you know, what do we get out of the dollars that we spend essentially? You know, I think that's really, I think it's just a decision -making process.

Bradley Bernard (23:33)
Mm -hmm.

Mm -hmm.

Bennett Bernard (23:54)
And accountants tend to use financial data to make that decision, but I'm, I'm assuming for engineering, it's no different. But you guys are just looking at it from like an engineering perspective of like, if we go this approach, these are the pros and cons that we have to deal with.

Bradley Bernard (24:08)
I think for engineers, we try to break it down into like very smaller problem spaces. So how do we take this giant feature for a website or a mobile app, break that down into deliverables, week over week, we're making meaningful progress and we can actually show something from what we've done. So that's been a pretty difficult task just because working in large code bases, managing people, dependencies, cross team It's really hard to.

estimate correctly. There's a lot of things that can pop up in the way that can affect estimates, but we try to have like a systematic approach to breaking these things down, having deliverable chunks, and then communicating that out to others. And that's probably the best way we have some sort of analysis on the work that we're doing.

Bennett Bernard (24:52)
I think you can probably go into this a bit deeper, but reporting and like data visualization, I think will really hit a special sauce when accounting is using like more integrations and that reporting is on like, I think, I think engineering calls like uptime, uptime monitoring. I want to say where it's basically giving you like exception logs, you know, saying, Hey, we process these 10 ,000.

transactions, these two got flagged for something. I think that kind of, you know, we have like a data pipeline from one system. It's doing some data manipulation and importing it into our financial system. I think reporting and visualizations around that will be helpful. I haven't seen that like in my experience and like, it's probably out there with like, you know, things like Zapier and stuff like that. I'm not saying it's not out there, but that's where I think the data visualization tools.

would be most beneficial that you can quickly just flag and drill down, you know, exception logs and stuff like that, where, you know, you're, you're looking at things like as they process and getting alerted to like, Hey, if there's an issue or not, that's, that's where I'd like to see, you know, some of the accounting, I don't say industry, but like, I'd like to see that get more widely adopted for sure.

Bradley Bernard (25:57)
I see.

Mm -hmm.

Yeah, I use an exception tracker for my websites and apps and wow, it is such a time saver because I don't have to monitor things. I get emailed when, production level exceptions happen. I get sent a stack trace. So what happened in my code that broke it. And then who's been interacting with the app at that time? Like what user, what URL were they on on the website? So that has been super nice. And then on top of that, there is visualizations for

How many errors I have a week, how many errors I have for a device class. So for an iPhone or on desktop, there's so much performance data, exception data that these tools deliver. And it's both in like the tabular format where you can dive into individual issues, but also in these graphs that provide like immediate insights. I'm like, is my application healthy?

Bennett Bernard (26:56)
I think what we have to do because we don't have those kinds of things is like reconciliations. So we basically say a lot of times in accounting, you know, we took this report, we did some manipulation to it and we manually imported it into the system. We don't have like really strong uptime modern.

Bradley Bernard (27:12)
Mm -hmm.

Bennett Bernard (27:15)
We don't have like really strong exception logs. Again, this is the general, it's not, there might be exceptions to that. And there certainly is people that are doing this, but as a general rule being in, being in accounting for the last 10 years, this is what I've seen. And so because we do this manual process to get the data into the system, we now will do a reconciliation where basically like go back and just make sure that everything got imported, everything that was going to get imported, got imported. And like, if there's any differences, why, like we do that all on the backend super manually.

Bradley Bernard (27:21)
Mm -hmm.

Mm -hmm.

Bennett Bernard (27:45)
And it's almost like we go in trying to discover if anything, when I miss and like, I think having a much more proactive system, like you were describing for your code is like the way to go where we can just say, like, we set up this code. And I think engineers do this because you guys are very familiar with like what you're working on. Right. So you guys say, like, I'm going to set up this pipeline to take data from one system and put it into another, another system.

Bradley Bernard (27:51)
I see.

Bennett Bernard (28:12)
And like, you feel good about that process. You will set up some exception logs or, you know, exception reporting, and then you kind of just manage to that. I think accounting, we almost don't trust that that will happen naturally. Like there's a, there's a bit of, I think a bit of healthy skepticism, but I think we can equip ourselves better to deal with that. And like, and that's where I kind of, again, pushed us to get more familiar with like.

Bradley Bernard (28:27)
I see

I love that.

Bennett Bernard (28:39)
the programming and again, we don't need to be engineers, but just get more familiar with it. Really understand it. Ask for, you know, as part of like, Hey, we want to do this automation ask for as well. Like exception reporting, like don't just take the automation and say, thanks. Like we also want to be able to have a way to like, I don't want to say automated review of this, but we all want to have a way to more easily review this versus like just having it go in and kind of having to take it on faith almost.

Bradley Bernard (28:52)
Mm -hmm.

Yeah, I think healthy skepticism is perfect because on the engineering side, we also don't trust user input. So a lot of the times you got to assume there's a bad actor on your website, on your mobile app, doing something that you don't want people to do, but you allow for it. And so you got to have safeguards on your app and websites that people can't just take advantage of it. So it's like double checking your work, locking down your code. So it won't break anything for other people. The worst thing is having one user.

Kind of take down your website because they're consuming too many resources. So I definitely feel that on the engineering side and double checking things. I think for engineering, that's more on the testing side. So we write a piece of code. We expect it to have this input and output. We write a test for it, but that's more of the logic. like you mentioned, you're importing tons of data. It might be from different sources, different formats. You need a massage and get into this final state. You can have a test that tests all these different formats, but at the end of the day, there's not.

a test for every single one in the whole wide world. So like good luck writing full test coverage for that.

Bennett Bernard (30:05)
Yeah. The, I saw a funny, just not to get us off topic, but I saw a funny, I guess a meme or just a something that went viral where there was like a chat. So like, you know, if you go to like a car dealership or you go to like someone's website and it says, hi, like we'd like to chat with us today. And it's like a virtual chat. Someone like typed in, like selects

Bradley Bernard (30:22)
Mm -hmm.

Bennett Bernard (30:25)
All like like customer database and the chat and like it returned like whatever bad code it was, it returned a bunch of customer information, you know, and when you said user controls, I just thought of that because yeah, bad actors. There's a funny, there's a funny Django library. I'm sure Laravel and other frameworks have this too, where you can, you install the library. It's called Django honeypot. I want to say, basically sets up like the fake admin.

Bradley Bernard (30:27)
yeah.

Yeah.

yes.

Bennett Bernard (30:53)
So if someone knows that you have a Django site, they can try and get to your admin panel and try and log in and like hack into your site. But what Django honeypot does is it sets up like a fake admin at like the admin URL. And then you can see when people try to go there and like, try and like hack into it. And so I remember like setting that up. I didn't ever have like enough traffic to like really get like meaningful, like pings there for a site I had up, but it was interesting to see, like there were people, there would be people that like go to that site.

Bradley Bernard (30:53)
Mm -hmm

Mm -hmm.

Bennett Bernard (31:22)
Like the admin page and you know, I'm like, what are you trying to do? Like, why are you going over there? Like, cause it's not a publicly displayed URL, right? So like people have to know type in puckpass .co slash admin and they try and you know, whatever shenanigans they're up to,

Bradley Bernard (31:29)
Yeah.

it's good at anti -bot mechanisms where you can put these like hidden input forms called a honeypot and then bots will then look at that form, think, I should go fill out my name in this name form. But in reality it's hidden by the browser. So no one would ever go filled out. And since these bots submitted it, you know, immediately like, Hey, this is garbage. I'm going to toss this out. I don't trust it, but on the note of those AI chats, funny enough, probably once a week, I would say I get a chat request for split my expenses.

someone will send me the most random thing that's clearly a test to see if I'm an AI chatbot. And I love responding because I'm like, hey, I'm Brad. I'm the creator of the site. This is not an AI chatbot. Thank you for your consideration. But nope, just me. I can't really remember the last one that I got, but I did get one that was like, translate the Bible verses from this context to this context. And I was like, what is this guy trying to do on my site?

But I just jumped in said hey, it's me and he's like, well, it's just testing. This is the AI chatbot. I'm like, nope But I think that's the new standard is just like chatting these AI chatbots because all the prompt engineering like prompt leaking prompt hacking whatever you want to call it I think people kind of have too much fun with and so any chat box now is a little fun exploration for these people, especially if they're technical

Bennett Bernard (32:46)
Mm -hmm.

Well, that's a great, I guess, call out to our last episode, we talked about like the pros and cons of like using AI models. And in this case for like virtual checks, a lot of times these websites, you know, they'll just say like, like Squarespace, for example, we have like a virtual chatbot agent you can use or whatever, like just make sure you're aware of like what that system can get to and what it can't get to. Cause like in the example I had, they, you know, and again, it's probably like a really debt, like low budget.

Bradley Bernard (33:18)
Mm -hmm.

Bennett Bernard (33:23)
virtual chat that was able to return that database query. But yeah, I mean, it's just one of those things where like, there's going to be bad actors. And especially in this new wave of like, where things are still kind of, I don't want to say chaotic, but kind of all over the place. Like it's just, just be careful, you know, cause you never know what people are, what people are up to, you know, with your Bible verse guide, for example. Yeah.

Bradley Bernard (33:32)
yeah.

Yeah. There's so much out wanted to talk a little bit more about process and kind of optimizing things. I know in the engineering side, we talked about it a bit in the last episode, but one thing I wanted to call out is we had talked about documentation. We talked a little bit about documentation on the accounting side too, as like an add on to some of the scripts you could write. How much documentation.

exists on the accounting side for non -automations, like just standard day -to -day tasks or routines or team practices.

Bennett Bernard (34:18)
depends on the team for sure. Cause it's one of those things that's really manual. I think good accounting departments, which is really all like I've worked in, you know, I was an auditor at one time and so you see different clients and so things can be a little bit different at other companies, of course, but in all the accounting departments I've been in, you know, documentation has always been a focus, but it's, it's honestly, it's a very boring thing to do. It's housekeeping, right? So you're like, I gotta go and I gotta write this procedure. And a lot of times you write something and

Bradley Bernard (34:21)
Mm -hmm.

Mm -hmm.

Right.

Bennett Bernard (34:48)
A year goes by, maybe something changes. Now you have to go back and update that if you remember to, sometimes you only remember to. So, you know, a lot of times the places there'll be like a process that says, Hey, like once a year ago, look at this and make sure it still applies. You know, so that has to be done, but then also things change. Yeah. Things change. And so it takes a manual update. So, you know, in my experience, the best documentation that, you know, I've seen in what we, like a philosophy rather is.

Bradley Bernard (34:54)
Mm -hmm. Right, right.

That's smart.

Bennett Bernard (35:17)
document to where someone could come in, read it and understand what you're doing, why you're doing it, like who does it if there's more than one person or people involved. And then also it's generic enough to give you all that information, but then not be so specific where this one smallest change makes it outdated. So like, let's not talk about like specific tabs. Let's talk about like a more general, like information, like let's not say, the bank data is on

Bradley Bernard (35:36)
Mm -hmm.

Bennett Bernard (35:47)
sell C seven on tab X, Y, Z. Like, let's just say bank data gets imported into the workbook, you know? And so like, you gotta have like balance that line of like being specific enough to where it's useful to the reader. And you have to assume that they have no context. Cause I think that's really where like documentation, that's what it's there for. To give that context, but don't make it so specific that you're gonna have to be updating it constantly every time something new happens. Cause it, cause it does. But yeah, that's, that's typically the accounting process.

Bradley Bernard (35:51)
Right.

Mm -hmm.

Yeah. It's so hard to write good documentation. Like even on the engineering side, I've written so much documentation, both as a newcomer, it was usually when I joined a company, you know, straight to the docs, figure out how these processes work, how am I supposed to write code at this company and what practices do they follow? And then two, like when you're in that space, it gives you an opportunity to write more docs. So if you found, you know, there wasn't enough clarity in this section.

as I learn and get answers from coworkers or other folks, create documentation in that area. And step one, create it not that hard. Like you mentioned, there's skills in writing, but two is how do we make sure we keep it up to date? How do we communicate with others to say we created this? There's a whole effort and kind of like concert of people that need to be involved, aware, and like bought into the thought of creating documentation. It's more of a cultural thing. And I think

There's been companies I've worked at where the documentation has been pretty abysmal and like hit or miss and other companies really lean on it and say like, Hey, let's keep this up to date. Like you mentioned, let's have an automated system to say, Hey, we wrote these docs. Like, can you go check it through up to date? And those are the ones that I love and engineers join their productive, they're efficient. They write more docs. It's like almost a win -win once you get there.

Bennett Bernard (37:28)
Yeah, the, I would love maybe this is pie in the sky, but maybe it's not, but like, or something that could be like a reviewer, like an automated review or like a bot or I don't want to say AI, but like a program where like, it would understand what someone is doing. Have the documentation that was like last written. And if that person starts doing something different, be like,

Bradley Bernard (37:46)
Mm -hmm.

Bennett Bernard (37:53)
Let me go back and change this like on the automated way. You know, I don't know if that's even possible technically, but yeah, it'd be nice and save people time. Cause it's just one of those things where again, it's housekeeping. It's boring to do. And so like, you have to like make the time to do it. And a lot of times, especially for accounting, you know, we get busy at specific times of year and specific months or specific times of the month. And so, you know, that's something where you have to make time for it. And like you said, it's a cultural thing.

Bradley Bernard (37:54)
I see. That'd be cool.

Mm -hmm.

Bennett Bernard (38:22)
Again, I've been fortunate enough to be part of like teams that really emphasize that, but you know, it's always something that has to be done. Like it's, it's rare that I think you walk into a place and say, documentations here, it's done. Don't even need to update anymore. It's just, it's just, it's just an ongoing cycle. you have to do it. You have to have to do it. It's like taxes. You got to do it. Not only anyone likes documentation, maybe some people do, but you know, yeah, it's, it's something that has to be done regardless of whether you like it or not.

Bradley Bernard (38:34)
Yeah.

Yeah. And I know on the engineering side, at least for companies that I've worked at writing documentation is super helpful for others. But when it comes to performance review time, honestly, it's not weighted as highly, even though it's like meaningful work. Like, yeah, it can be a chore. But if you think about the raw value out of writing something once, sharing that with hundreds of people versus you having to chat, you know, people chatting, Hey Brad, how does this work? Like, I know you touched this code in this area. Like you're going to get overwhelmed if you wrote a doc that just laid out your decision making.

why you did it, what's important, and then share that with people. Like you're scaling your output, answering questions ahead of time. But I think people don't realize that sometimes, that then like are kind of off put by the performance review considerations when writing docs that if the incentives aren't aligned for performance review to write docs, then at the end of the day, when you're planning your time and like being at a company, you might choose to skip that part given like, Hey, if they don't care about it, I don't care about it.

Bennett Bernard (39:42)
Yeah. I mean, your compensation, your performance should be aligned to like the work that the company values. So the company values documentation, then that should be a completely valid thing to bring up and should be, like you said, weighted as much as whatever new feature that you implemented. Right. Yeah. That's something for sure that, but I hear what you're saying is again, it's kind of just, you know, it's not as shiny object as those new features are. So often it gets overlooked.

Bradley Bernard (39:51)
Mm -hmm.

Right.

Yeah,

Bennett Bernard (40:11)
something I've experienced a couple of times where there's been an issue with some kind of code. So like a integration shuts down. We don't know why it happened or, you know, whatever the issue was, or some issue that happens a bug in our engineering team, they do, it's called the five.

Five ys I think it's what it's called. Does that ring a bell at all? Okay, cool. Well, it's really cool actually. So maybe it's just something that's been unique to the engineering teams I've worked with and they're awesome then. Cause I really thought this was awesome. So they do like a root cause analysis, which I'm sure, you know, anytime there's a bug, that's, that's a standard thing. Right. But then they go through this process where they get everyone in the room, all like the stakeholders, the engineers that built it, you know, for us accounting end users that were like impacted by the bug.

Bradley Bernard (40:33)
I haven't heard of it. No, keep going.

Hmm.

Yep.

Bennett Bernard (41:00)
And they basically kind of go through and say, why did this happen? And they will say, well, it's because this database migrated at 8 PM and it didn't copy all over all the data that I needed to. Okay. Why, why did that happen? Well, because of this. And so they go, they drill down like five they get to this root causes. It's a super thorough, I don't want to say uncomfortable because I think everyone in there has the mindset of like accountability and ownership. So it's.

Bradley Bernard (41:13)
Mm -hmm.

I see.

Bennett Bernard (41:26)
You know, it's not like anyone's pointing fingers. It does get to like, well, maybe I should have, you know, sent out an email that told everybody this was happening, or maybe we didn't consider that in our logic when we first wrote this, because, you know, we didn't know this was possible. Like it'll get to a point where like, there will be a error that caused this that, you know, we just have to fix, but it's just that way of going about it. And again, it was just like the five, I don't remember what it was called, like the five whys or the five questions.

Bradley Bernard (41:29)
Right, right.

Bennett Bernard (41:53)
And it was just like a, something that we just have gone through every single time we have that, that situation happen. And yeah, it's super helpful because it just takes the, it just takes the finger pointing out of it and it makes it really accountability. And, you know, people take ownership of, yeah, I could have done this better or I should have done this or, you know, we didn't think about that. You know, it's just super thorough.

Bradley Bernard (41:53)
Hmm.

Yeah.

Yeah, all the companies I've been at do have a form of that kind of root cause analysis. So I think at LinkedIn, they called it a GCN and Meta was called a SEV. So basically a site wide issue or something of major concern, bring everybody in after the fact, or during the kind of the incident, pull in all these relevant stakeholders from engineering to SRE. So people will keep the lights on unlike the hardware side or software side. And then like product teams saying, Hey, like.

Maybe your team on Facebook .com rolled out a new feature and it broke newsfeed. And so there's so much stuff going on that they just kind of bring everybody in and say, Hey, we got an issue here. And it's usually in a space where people can feel comfortable and everyone makes mistakes. And it's a pretty blameless culture. So people don't feel like, I pushed the code change. it's a hundred percent my fault. Like I,

You know, I'm sorry. It's more just like, Hey, let's fix the problem. Let's move forward and then let's go take a look at it. Once it's done to say, how can that never happen again? So I think when I was at Meta the site probably went down maybe two or three times. I'm not a hundred percent sure, but a little bit of a funny day, because when you're at the company, Meta uses internal tools. Like they're on facebook .com and meta .com like internally at the company. So if the facebook .com site is down as an engineer.

Bennett Bernard (43:11)
Mm -hmm.

Bradley Bernard (43:32)
You can't use any services. And so the site's down, people are kind of messaging each other on other platforms saying, Hey, is the site down for you? Like blah, blah, blah. Like the internet's going crazy. Okay. It's like a day off for us engineers. But after that, people were very kind of like on top of it, like, what happened? Like, how does the whole site go down? And I don't remember the exact root cause, but I think it had something to do with DNS, which is like a very systematic network layer. And once that's kind of shot, no matter what, it's pretty hard to bring back online quickly.

Bennett Bernard (43:43)
Hehehe.

Bradley Bernard (44:01)
And so it was just kind of the funny incident of like, Hey, I think someone just made like a normal routine code change. It's in a little bit of a sensitive area, I would say, but you know, one thing led to another, the sites down, people are kind of just like, what am I going to do today? probably not that much. It's like, I literally can't push code, can't look at code, can't look at documentation. Like everything that Facebook uses down if like that, you know, the facebook .com is down. So I think even going into something as large as that.

Bennett Bernard (44:25)
Mm -hmm.

Bradley Bernard (44:28)
When the culture is so blameless, like I can't imagine being that person that made that code change. And I'm sure they're a smart person. They're qualified to be at meta at Facebook, you know, but I would be scared and just nervous about going to that meeting saying, yeah, I did that code change. But I think having that correct environment, I love the five ys. I can just imagine people saying, you know, like you mentioned, why'd that happen? Why'd that happen? And then each answer to those questions will provide an opportunity to make the system more robust. So next time they migrate the database, like.

They have checks saying, are we sure we got all the data? If not, like roll that back and let's try it again. And so same thing at Meta. I think those DNS changes that kind of ruin the system, at least temporarily, like that'll never happen again. It's not a matter of like if or when, like something big will happen again. And that'll be a problem that will be solved in the future from all these like kind of retrospectives.

Bennett Bernard (45:19)
Yeah. As long as you know, you can take something from it and the culture, the culture has to be, yeah, accountability and not, not be in trouble for making a mistake. Everyone makes mistakes, you know, as long as it's not the same mistake twice. I think you're, you know, most, most of the time I think that's okay because it identifies an opportunity for the most part. But yeah, I think, you know, one thing that I wanted to mention, and I think you kind of teed it up perfectly and what you said there was.

Bradley Bernard (45:24)
Right.

Yeah.

Mm -hmm.

Bennett Bernard (45:48)
You know, it's, it's a culture thing where I feel like engineering is very, I don't want to say like, let me, I guess, let me approach it from the accounting side first. And I think you'll see what I'm saying about engineering more accounting. You know, you go through, I'm going to go down the CPA path. Cause that's kind of the most like, you know, I'd say like documented and like recommended path for accounts to go down. So, you know, you go through four years, sometimes five years of schooling.

The CPA track had 150 hour requirement. They still do. It's very, very controversial. And I think it's starting to kind of, be unwound a little bit as from what I'm reading and hearing out there. So that might go away, but you know, you have to get a bachelor's degree, you know, four years of school. You have to pass the CPA exams, which are, which are no joke. I don't know what the pass rates were, but, you know, it's four tests and they're very, very comprehensive.

So then you can put the letters after your name, essentially. There's a there's a credentialing that is so like it's held in such high regard in accounting. I would argue that like I the things I don't really touch any of my CPA knowledge, to be honest with you, like in my day to day work, maybe bits and pieces of the areas that I cover, but for a comprehensive like I don't do taxes. I, you know.

Bradley Bernard (46:43)
Mm -hmm.

you

Bennett Bernard (47:05)
I don't do taxes like anybody else that just do regular, you know, turbo tax basically, like half the things, maybe even three quarters of things that I did in the CPA exam are not relevant, but that is such a recommended path. And I understand why though too. So where I'm going with this is credentialing. There's, there's the CPA, there's the CFP, like certified financial planner, you know, maybe that's not accounting, but it's still kind of in the finance realm. There's the, CMA.

Bradley Bernard (47:10)
Mm -hmm.

Mm -hmm.

Bennett Bernard (47:33)
Accounting makes a big deal about credentialing. Engineering, I haven't ever seen any of you engineers have letters after your name. And so I guess what's your thoughts on that?

Bradley Bernard (47:40)
Not once.

Yeah, I think, you know, oddly enough, some of the smartest engineers that I've worked with at these companies are arts degrees, language degrees, poli sci, music, even where, like we mentioned in the beginning, the abundance of information for computer science, for programming, for building mobile apps, websites. If you have the drive and desire to do it and you're passionate about it, you can get super far without even a college education.

there's tons of boot camps out there that'll convert you from, you know, not knowing anything could be able to build a full mobile app, web app that's using like the latest frameworks, latest technologies. so I don't like, honestly for job postings these days, there's not really, Hey, you need to have a bachelor's and you could have a degree. You could have no degree. It's really like years of experience, which, you know, some could say, yeah, you need a degree to get like your first job and then kind of prove yourself from there to get that years of experience. But.

I would also say the requirements of being kind of pulled back a little, And then once you get to that actual interview of live coding, personality or behavioral, doing well on those and showing your skills, that's really how you get through these interviews and get leveled out of senior staff, you know, new grad.

There's not really a whole much of like, I'm going to go spend 150 hours, get credentialed. And, you know, once I get that, I have this, you know, cool thing I can put in my profile and show off to other people and get it renewed, et cetera. I like it because I don't have to do that. I'm passionate about it. I probably would get whatever credential there was if there was such a thing on my end, but thankfully there isn't. And I think it probably would hold a lot of people back. And there's so many good people that I've worked with that you would think if you looked at their resume on paper.

these people didn't do any formal CS education or didn't have this or that, but when they show up and do their work, you're just appalled at how good they are. You're like, how the heck did these guys get so good? I don't know, but I love it and I'm loving that I'm working with them. So I'm glad it's not a thing for the CS folks because I would have much less opportunity to work with these people.

Bennett Bernard (49:42)
Yeah. And what I was going to say in the beginning was that it feels like it's much more of a meritocracy than maybe accounting where like, it's almost like, what have you done? Like, show me what you've done versus like, I think accounting, you know, you kind of are using those credentials, whatever they may be after your name. I was like, this is what I've done. But it's like, what does that really mean versus like a portfolio of a site or like an app? But even

Bradley Bernard (49:53)
Mm -hmm.

Bennett Bernard (50:07)
So not everyone that gets jobs at these companies has like a portfolio too, of course. But you also mentioned, you mentioned that second part of, well, they, they, most of these interviews have a coding, like a live coding thing where like you have to like, you know, whatever the coding questions are, there's not like that for accounting typically in my experience, you know, it's not like, like explained, I mean, it's just, it's just a different, you know, career path. Like it's, it's non -technical versus engineering is technical. So it's not really like an opportunity where it's like,

Bradley Bernard (50:12)
Right, right.

Yeah.

Bennett Bernard (50:37)
You know, explain to me the guidance on, you know, fair value accounting, like unless you were interviewing for a specific role within fair value accounting, you're not going to get that question in an interview probably.

Bradley Bernard (50:47)
as one who's coded for 10 plus years, coming into those interviews, sometimes I just forget the most basic things I'm sitting there like, you know, if I had more time, if I had Google open, it's just, it's a little bit of an odd environment being. Tagged into like a 45 minute live coding session when your day -to -day job is working with other people, communicating with them, looking up docs. And then all of a sudden now you need to know the answer right on the spot. Explain perfectly.

And yeah, it's a little bit of a thought process versus like just general output, but I do think it's awkward on both sides. Like I've given the interviews, I've taken the interviews plenty of times. And if you're struggling as a candidate, it's like, you know, I know the interviewer, what the interviewer is thinking. And on the other side, if you're, you know, at a company interviewer, a candidate, you're just like, hopefully they see this or like, I can nudge them this way. And if they don't get it, you're like, like, I'm sure they'd get it at a different time if they weren't pressured right in front of me. But yeah, it's a little bit of a crazy system.

Not a huge fan, but it is what we do.

Bennett Bernard (51:42)
It's so, it's so crazy. And it's such a, like, it's so, I don't say hyped, but it's so dreaded maybe that there's that book cracking the coding interview. That's like sold tens of millions of copies. Right. Yeah. Do you have it? I saw you look around. Do you have it? Yeah.

Bradley Bernard (51:53)
Yep. Yep. Yeah, I do. I actually I do have it. I think I've had it for maybe probably ever since I got out of college. I think I bought it when I was interviewing in college because it was the absolute rave back in the day. I think I read it like one time through and then we'll do questions when I interview. It's great. But leet code is the de facto standard now

cracking the coding interview, I think had, you know, a hundred questions or whatever in different categories of data structures, like strings, arrays, blah, blah, blah. And then leet code is now the online platform for interview prep where, you know, maybe meta has certain questions that they ask candidates. There's like a question bank for a meta or like a question bank for Uber. And so you kind of pay for access to people who have done the interviews before you say, Hey, I got off the phone with, you know, meta engineer.

And like, these are the questions that they asked me. So it's a solid book, good read, but I think in the modern day of interviewing the best resource, I would say is probably leet code for engineers is cause there's so much that changes. And I think that book came out, I don't know, too long ago to even like it's relevant in the basics, but in the specifics where I think a lot of details lie it doesn't help you too much.

Bennett Bernard (53:08)
Hmm. Yeah. I've seen the YouTube videos of like software engineer to interviewing at Amazon and it's like the, the live code example. And they're so awkward to be honest with you. I'm like, this, this looks horrible. I'm glad I've never had to do those because yeah, like it, you know, it's just like, like you said, watching someone sit over your shoulder while you think through something, it's so like, like unnatural, you know, it's like, let me just, let me Google this. I'm going to Google this. That like you said, when you in your day -to -day job, you're going to go to stack overflow. You're going to ask.

Bradley Bernard (53:29)
Mm -hmm.

Very.

Bennett Bernard (53:38)
now chat gbt like why can't I just do that now you know what I mean but hey

Bradley Bernard (53:39)
Yeah.

Yeah. And there is take home projects. So it's not only live coding, which I really favored in my last interview round, probably half the interviews that I took for iOS engineer or software engineer were take home. So they give you maybe an hour to two to three hours to say, here's the description of the project I want you to create spent up to this amount of time on it. And then submit it to us either over email or a portal where you upload it. That was fun, but it's also way more time.

And if they don't give you like a hard time allocation, you can also spend more time on it. And then now you spent five hours working on a project. So you care a lot about it and you want to look good, but you're only supposed to spend two to three hours. So I think in COVID it was really popular to do the take home project. I think now probably flip back a little bit to the traditional 45 minutes to an hour live coding session, just because you can see it as easier on the take home project, but

I think for the candidate, it can be too much of a time commitment to do that like three to four hour project, because you can submit that project, get rejected and be like, great. I just wasted four hours where if you kind of mess up on the life coding, that was an hour and you know, less time spent, I guess.

Bennett Bernard (54:52)
Yeah, makes sense.

Bradley Bernard (54:55)
So we're gonna jump into the bookmarks of the week. I'll go first. So on Twitter, I found a pretty cool tweet. Essentially it was from the user RaulGS. And there's a whole classification of folks on Twitter who are reverse engineering the prompts that are used for various AI tools.

So chat GPT, Claude, like Google, all of these chat models have what's called a system prompt. And a system prompt instructs the AI model in the chat to say, hey, you're allowed to do this. This is your name. This is how much knowledge you have, et cetera. So it's this giant blob of information that describes how the chat agent should act. And so if you use chat GPT, it's a little bit more verbose. If you use Claude, for example,

definitely a little bit more succinct and directly like to the point. And so that's kind of steered by this system prompt. And so what these guys do is they go inside, you know, chat GPT, Claude, and they basically reverse engineer it to get this prompt that shouldn't be exposed to the user at all ever to get exposed to the user. And how they do that is a whole bunch of different methods. Sometimes they like do very like, I don't know, threatening things or bribe it. Like there's, they're kind of weird things to do it as you can imagine.

At the end of the day, they did it and this guy got it and he extracted this 5 ,000 token prompt that Claude uses. So people applaud Claude right now for its intelligence, its reasoning. And this guy, you know, does whatever he does and dumps out this giant, freaking prompt. And at the end of the day, I'm not going to read it off. So it would would about 40 minutes, but I just want a few stats from it. It's 26 ,000 characters. So I don't really know how long that is, but there's like probably, you know,

hundreds and hundreds of paragraphs. So if you ask me to describe how to describe chat GPT, I could probably write you four or five paragraphs, but there's no way I'd be able to write 26 ,000 characters on exactly how to respond. Here's examples. 3 .5K words. So it gives you more context on how long it is. And then 450 lines. That one I don't really love because the lines are very, very long, but it's very interesting to see these guys kind of dump out.

the inner brain behind some of these chat agents. They've done it before for a lot of other ones, but Claude was hyped because Claude has gotten so much good press on like benchmarks and real world performance that people like immediately dove into this guy's dumped out prompt or like, how do they do it? Like, how do I replicate it? In theory, what I could do is take this prompt back to Chatty Butler and my AI would look a little bit similar to Claude. That's kind of like the whole like bread and butter.

They really try to keep this locked down. So yeah, that's my tweet of the week. Really like it. I'll share it in the show notes, but essentially every time you get a sneak peek at some of these prompts, it kind of peels back a layer because there's so much skill involved in crafting this perfectly like able to be understanding text representation of behavior examples on how to respond that I find it absolutely fascinating to see this company that has, you know, millions and millions of dollars and the best in class researchers probably spent like.

hundreds and hundreds of hours on this thing and like here it is, you know, broad daylight. So yeah, super, super, super cool.

Bennett Bernard (58:11)
Yeah, that's cool. That's very very technical but it was cool. If are you gonna read the whole doc? You're not gonna read the whole 25 ,000 words Okay, we'll just do a live loud Cool well mine is actually a clip from a podcast so the podcast used to be called

Bradley Bernard (58:16)
Yes.

No, that's the next podcast. Tune in.

Bennett Bernard (58:33)
the cloud accounting podcast. Now I think they've rebranded and they're just the accounting podcast. I want to say, but, it's run by two, two fellas, Blake Oliver and David Leary. And they're been in the accounting space for a long time, have kind of run and sold and been a part of different businesses in the accounting industry. He Blake and David have turned into the kind of like voices like on industry trends and

software and AI and so they're always kind of on the cutting edge of like where the industry is going to go. So they're great. Listen, this podcast clip that I linked is basically Blake kind of talking about like when should you actually adopt like a software and like when does it not make sense to. So basically I won't, you know, it's a video, so I won't like play it here, but basically talks about like ease of use. Like it has to be easy to use. There can't be like a steep learning curve or just not going to get adopted.

And I think that's something that I've definitely experienced because, you know, you have to spend the time to learn the right things. But if you are spending too much time, like just trying to get familiar with like the windows and a software or like, I need to drag and drop this over here, like, but I won't, it won't let me do it this way. If it's not intuitive, then you're going to hit a roadblock into actually implementing that, especially if you're going to implement it for your whole team or for your whole company, whatever it is.

So, you know, ease of use, intuitiveness, and then like, does it actually solve your problem? So, you know, there's lots of really good programs out there. There's some that, you know, in the accounting space, they give you like a hundred features, but maybe you only need two or three of those. Like, does it make sense to like, are we actually getting it because it's going to solve a problem for us? Are we getting it because it has a hundred features and that just sounds really cool, but in practice, we're not going to use them all.

Bradley Bernard (1:00:07)
You

Mm -hmm.

Bennett Bernard (1:00:29)
And so I personally like that kind of critical thinking about like, what are we actually doing here? Like, what's the point of this? Like, why are we interested in the software or like, are we actually able to implement it? Like, cause a lot of times I think, you know, companies are so good at like presenting a package. Like you go on some websites and you're like, wow. The landing page is perfect. Their features look amazing. Like it's looks so modern.

Bradley Bernard (1:00:31)
Mm -hmm.

Mm -hmm.

Bennett Bernard (1:00:55)
And just like cool to use. Like it has AI, you know, it has machine learning. If it was like five years ago, you know, it has machine learning and all this stuff, right? Like they sell you on these features, but like boil it down. Like what are you, what's the real problem you're trying to solve? And like, can this do it in a way where like it's low friction and easy to use and intuitive to use. So I like that approach because again, I think it's, there's just so much products out there vying for accounting dollars that, you know,

Bradley Bernard (1:01:02)
you

Bennett Bernard (1:01:25)
Just pause and like, do that kind of walkthrough and be like, does this really like, you should almost be skeptical that you need it. I think as like your default approach of like, I don't think I need this. Like let me convince or let it convince me that like, this is what I'm really missing. so I liked his, his kind of approach. And again, I'll try and find the link to the full episode, but I did link at the very least we'll get the link to the clip, from that podcast where they kind of go into that, that topic. So yeah.

Bradley Bernard (1:01:40)
Mm -hmm.

And building software that's like, you know, ease of use in software, even as an application builder, so hard to, I try hard to make it, you know, easy to use, I guess, but it's fricking hard because supporting all these use cases introduces complexity, makes you feel like you need to do more and complicate the flow. But at times less is more in software and as a builder.

kind of creator, you gotta keep telling yourself that, because as you build things month over month, like more and more and more complexity, and yeah, maybe you just need one or two things. So it's good to keep that in mind.

Bennett Bernard (1:02:24)
Yeah. Yeah. I mean, again, everyone's always super busy. So we're trying to find ways to like make our jobs easier to work late, less late nights, you know, but is that really, you know, just always got to think when you're going to pull your wallet out and pay for something, is that really going to be, you know, what's going to let you do all those things? So,

Bradley Bernard (1:02:34)
Mm -hmm.

Bennett Bernard (1:02:43)
Cool. Alright, so let's wrap this up, Brad. It's getting late and I got lots of stuff there. We'll make sure that everything's in the show notes. But yeah, we'll do this again next week. Cool. Alright, catch you later.

Bradley Bernard (1:02:53)
Sounds good. See ya.