#53 Brian Pontarelli thinks like a customer
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Tim Bourguignon 0:06
Hello, and welcome to developer's journey. The podcast shining a light on developers lives from all over the world. My name is Tim Bourguignon, and today I received Brian Pirelli. Brian studied computer engineering at the University of Colorado. After graduating he solved complex technology challenges for companies like orbits be a US freightways X or, and texture media. Brian is also a technology entrepreneur who bootstrapped both his companies fusion ocean and clean speak, where he currently focuses on solving login registration, and user management challenges. Brian, welcome to dev journey.
Brian Pontarelli 0:49
Great. Thanks for having me.
Tim Bourguignon 0:51
Oh, it's my pleasure. So before we talk about your path toward enterpreneurship, how did you start your journey into computer engineering? And how did you end up studying at the University University of Colorado,
Brian Pontarelli 1:06
so I actually started playing with computers at quite an early age, I was about eight. And the school I was going to had purchased the number of Apple two e computers. And we actually had someone there a teacher who was studying programming and had been programming for quite a while. And he was really helpful and just getting everybody started. And we, we took them apart, we put them back together, we started programming, we're able to sort of get very deep into you know, machine language and how those things work, how the computer actually functioned. And that was, you know, again, at a very early age. And I continue to build on that my parents bought an IBM PC, again, you know, we, we modified it, we took it apart, we added things to it, continue to program. In high school, I continued to program and took a number of programming classes. And then it was when I started at CU, I actually was thinking I wanted to try something different. Because I had been programming doing computers for so long. I was like, well, maybe I'll try and do electrical engineering, or, you know, something similar, but different. And after about two years of studying that, I just realized that that wasn't for me. And I really wanted to go back and continue programming. So I actually switched majors halfway through and went back into computer engineering again, and then just, you know, kept focusing on that.
Tim Bourguignon 2:38
What attracted you toward computer science or computer engineering at a very early age?
Brian Pontarelli 2:45
Yeah, you know, I, I was just so fascinated by the fact that you could sit down, you know, type in and back then it was a lot of basic, you know, some some machine language, you know, some assembler, you could just, you know, type these commands in. And then you could have things appearing on the screen. So it was, it was just, it was so fascinating to me that a computer was able to, to do that. And I just I really wanted to understand how it actually did it. So I really wanted to get down to those fundamentals. I wanted to learn how, how would How did the keyboard Connect? How did the monitor Connect, like, how does all this stuff actually work? And that's, I think it was just that, that desire to understand how things work that really got me into computers.
Tim Bourguignon 3:30
It's also the the reason why you switch majors meaning, meaning you started electrical engineering to understand how it works. One level deeper.
Brian Pontarelli 3:38
Yeah, I mean, that was part of it, I really was just trying to see if I could find another engineering that was, you know, similar, but didn't deal with computers, right. So it was more just, you know, circuits and, and logic and like, in those, you know, type of endeavors. And, and I realized, after, you know, taking differential equations and getting really heavy into the math and, and learning about, you know, these complicated circuit diagrams and how, how all that worked, it just it didn't really didn't really, you know, resonate with me, I just actually got kind of sick of the math. And, and I just, I really wanted to focus back on programming.
Tim Bourguignon 4:16
So how did you make your way back?
Brian Pontarelli 4:19
So, So interestingly, like I was, I knew that there are a couple programming classes and I was like, Well, I'm gonna go take those, right, because they, they are a little bit more in depth than anything I've ever done in the past. So I took one programming course just to see and, and I, it was great. I loved it. And so I the next semester, I went over, I switched my majors to Computer Engineering. I actually went to that teacher and I said, Hey, can I can I be a teaching assistant? Can I, you know, start helping teach classes. And he was great. He He immediately put me to work and and started, you know, letting me do to teach and to help. him, I started editing books for other teachers. So I, I really got engrossed in in just the computer engineering department at the University of Colorado almost immediately,
Tim Bourguignon 5:11
what did you want to be a teaching assistant?
Brian Pontarelli 5:14
Um, I don't know, I just I really love teaching people and computer programming and just dealing with computers is complex enough where I think a lot of people end up taking it for an elective, and they struggle a lot, because they just don't fundamentally understand how things work. And I really wanted to see if I could teach them, you know, at a basic level, how to get through a programming class as an elective. Because again, a lot of the people that were in these beginning programming classes weren't computer engineers, they were, you know, they might be in, you know, taking physics, or they might be doing other majors and, and they're taking programming as an elective. And they struggle a lot. So I sort of, I really had this desire to see if I could teach people that, you know, hadn't been dealing with computers their whole lives, you know, how to how to program a computer.
Tim Bourguignon 6:03
In retrospect, how do you think this helped you for your future life.
Brian Pontarelli 6:09
So I kind of carried all of that through into my career, I ended up being, you know, helping a lot of junior engineers, when I was at orbits, I helped do a lot of the architecture and like systems designs, I did a lot of the hiring. I did a lot of mentoring. I did some management as well. So I think just throughout I, you know, been able to sort of help people learn and get better at programming.
Tim Bourguignon 6:41
It makes sense. Makes sense? Okay, so how did your study go after that?
Brian Pontarelli 6:49
Oh, so like the go Lang you mean?
Tim Bourguignon 6:52
No, no, the How did you study? Go further after after being a teaching assistant? And then finishing your studies in computer sciences instead of off electrical engineering? How did your story go further after?
Brian Pontarelli 7:08
Oh, I gotcha. Um, yeah. So you know, I, it's a kind of a funny story. So I, you know, I had been teaching now for like, two years, and, and I sort of made a decision that I didn't want to continue into a masters or a PhD program. And so the teacher who I was a teaching assistant for, had already scheduled me to teach a bunch of classes the next semester, just assuming I was gonna go for my PhD. And so I had to break the news. That No, I was graduating, and I was, you know, I had a job lined up. And so I had been interviewing at a number of companies, both really big companies, and then just a lot of like, smaller local companies and in Boulder, and, and I, you know, I got a position at a company, and I only took, like, I think maybe two weeks off between graduation and starting, and I just, you know, I started hit the ground running and started programming almost immediately on a pretty, pretty big project with about 10 other engineers.
Tim Bourguignon 8:10
Hmm, what's convinced you not to continue your studies?
Brian Pontarelli 8:14
Um, well, I've liked teaching other people, I didn't really enjoy the whole studying part of it. I think, I think it just there, there are a bunch of classes I had to take, and I just didn't find a lot of value in them. And, and I knew that if I kind of kept going, there's going to be a lot of research and, and just a lot more sort of intensive, you know, lessons, rather than focusing on teaching, or going out and like actually creating things. So I, you know, I just sort of made a decision that, you know, maybe I'd go back to teaching later in life. And you know, after I had built a company, and you know, done all of that maybe I go teach after,
Tim Bourguignon 9:05
was the idea of building your own company already in your mind back then.
Brian Pontarelli 9:09
Yeah, so during college, I actually had a couple of friends and we started a company. And two of us were programmers. And so we were programming it, I didn't do quite as much programming on it as the other one of the other founders, but the three of us, you know, tried to get it up and running and failed. And so, took us about two, two years of time. So while I was in college, and, and then after I had graduated, it took me a while to kind of shut the company down. But it was a really good learning experience that, you know, starting a company is much more challenging than just coming up with an idea and building a website.
Tim Bourguignon 9:50
What was the company about?
Brian Pontarelli 9:53
So the company was, it's actually it's interesting because it's very similar to like, Door dash and in some of the other companies, so what we were doing was your, we are going to restaurants and we were taking their menus, putting them online so that you could search for them, and then allowing you to order directly from the website. And we were going to try and fax the orders into the restaurant. So, you know, it's a fairly complicated endeavor. And we got, you know, first version of it, where we can upload menus built. And, you know, it works. But we were just really, we really struggled with the business pieces of it, like how do we go into a restaurant and get them to actually pay us for this service?
Tim Bourguignon 10:38
Um, now that you have two companies under your belt, or at least two more companies under your belt, what do you think was the was the, the mistakes or the rookie mistakes you made?
Brian Pontarelli 10:50
So yeah, the I, there's definitely plenty of those.
hiring people that think they want to be in a startup, but then come to realize that they, it's not a good fit for them, that's, you know, that that's a big challenge. And we've also just hiring people that didn't don't didn't really know what they were doing, or weren't able to, to be self directed. Because when you're in a small company, it's really challenging if everyone isn't very productive, you know, very, very productive and able to, to do their job without a lot of training and a lot of help. And so that those are some of the biggest challenges that I think I've had with all the companies.
Tim Bourguignon 11:38
Yeah, it makes sense. And definitely something you will be struggling with. If you were not you to graduate and still in college. I can see this Yeah,
Brian Pontarelli 11:47
yeah.
Tim Bourguignon 11:49
Yeah. So okay, you graduated and didn't continue your studies and started working at this, um, this company, where you were with 10? engineers? How did it go from there.
Brian Pontarelli 12:01
So we, we were actually working on a project and this was right, around 2000. So this is right, when everything was sort of the crashing, and the projects that required a lot of hours, we are working, like really long weeks, we are trying to deliver this product in a very short period of time. And the client ended up like running out of money. And it was, it was pretty big disaster, actually. But I learned a lot about sort of how to avoid these, back then there were just a lot of businesses that, you know, it could go get a bunch of money, the business idea was pretty bad. And everybody just kind of, you know, tried to get it up and running and really didn't have a plan. And so I think, I think, you know, during that process, we just we learned a lot about sort of how to manage expectations, how to not get yourself into a situation where you can't deliver, try to, like, really think through the business and see if you can actually make money eventually. So you know, it was it was definitely a good learning experience. And I ended up actually quitting after like a year and a half, it was just the company was kind of a disaster. And I just wanted to, you know, try something new. So actually, I actually quit that job and started at another job. And again, this was during the.com. Bust. And, and then the company had moved on to went out of business like shortly thereafter as well, right. So I ended up just kind of jumping jobs, trying to make ends meet and trying to figure out well, you know, what I wanted to do until about a year and a half later, or a year later, and I managed to get a job at VA. And that was during the time where VA was, you know, in very, very high growth mode, before they got acquired by Oracle. That was that was a really, really great job that taught me a lot as well.
Tim Bourguignon 14:04
Before we talk about about your time at ba What do you think were the the key learnings you? You gathered during the.com? era?
Brian Pontarelli 14:15
Yeah, so I would say, um, it's super important to have like a business model, right. And like actually plan, you might have a plan. But if it doesn't actually have any components of you know, making revenue and getting those things up and running, at some point, you might want to revisit the plan. And then the team is just super important. I mean, it's super important, no matter what size company at no matter where you're at, but the team that we had, everybody was really good engineers. And the code that we created was actually pretty good quality and, and didn't require a lot of like, you know, refactoring or didn't have a lot of issues and so on. That, that really helped me understand like how you work in a team, like how does a team work together to generate, you know, really large code bases very quickly without, you know, knowing that you're gonna have to rewrite everything two years down the road. So that was a really good minute experience.
Tim Bourguignon 15:17
Cool, thanks. Thank you for that. Okay, then you learned ba, ba, what do you there.
Brian Pontarelli 15:24
So I was I was actually on a team called the customer centric engineering team, so CCE is what we call it. And essentially, what we did is we, we took customer requirements or customer applications and needs, and we modeled them on va software, and then try to figure out how, you know, maybe there was a bug or they're running to some type of issue, figure out, you know, how to fix it, either in the product, or figure out how to build something on top, that would allow them to get their features down or get their their application built. And so we were dealing a lot with customers. So we were interacting with customers directly a lot of the time. And these were really large customers with really, really large applications. And so that was a really good experience of just learning how to interact with the business side of things like how does the customer, you know how to write emails, and how to interact with them, and how to talk to them on the phone and get on calls? And so that was that was really helpful, because, you know, there are a lot of engineers that can write great code, but they they struggle, in terms of just communicating, and how do you know, discuss things with the client? And so that was a good learning experience. For me.
Tim Bourguignon 16:41
It's interesting, I'm in almost every example you gave until now, you always involve the business side and the customer side. And is it a deliberate? act on your site? Or is it is it subconscious?
Brian Pontarelli 16:56
No, it's very deliberate. And, and I've done it for such a long time, I my family is always, you know, run their own businesses. So both my grandfather's had their own business, my dad had his own business, my mom has her own business. So everyone is very business oriented. And so I've always understood that in order to run a successful business, I mean, you have to have, you have to understand what you're selling, you have to understand why people would one want it, and whether or not they've actually, you know, really want to pay for it at some point. And like, how do you actually make money. And so those things are always a, you know, core to everything that we do. And I think as engineers, we really need to focus on that. And sometimes we don't write, we just we want to write code that's, you know, cool, or we want to solve a problem that we think is neat. But that might not actually be a problem that anyone cares about, or a problem that anyone's willing to pay money for. So thinking about it from the customer's perspective, is so important to everything that we do. And it's something that is it's hard to teach. But I think we do need to teach it, we need to really instill into, you know, the new software developers that are just coming out of college or just getting started, how important it is to have that customer's perspective.
Tim Bourguignon 18:19
Yeah, I totally agree. But it's very hard to teach, because engineers are kind of excited by the technology itself. Also, when it doesn't really solve a problem.
Brian Pontarelli 18:35
Yeah, exactly. And I think there's this great article, and it's a, it's called the magpie developer. And developers get into this, this situation where they something new comes out. And it's so cool, and it seems so exciting. They want to try it. And a lot of times, what will happen is they'll can, you know, they might convince the business that they, they need to rewrite everything in this new language or in this on this new system. And that's expensive. And it actually can be detrimental to the customer, and to the business. And so we we sort of like we have to understand that the things that we've written, if we wrote them, well, they're still going to work. It's not like just because a new language came out, the old stuff is just instantaneously, you know, it's going to fail. And so we have to make sure that when we think through these engineering decisions, we're really considering the business side of things. How would you would you encourage
Tim Bourguignon 19:36
a newcomer to think about the business always first, before thinking about the rest? Do you have a trick?
Brian Pontarelli 19:44
So I think there's sort of two components to it. So if you put yourself in the shoes of the customer, and you can you can even go ask the customer what they think right? You can get their feedback. What if you put yourself in their shoes and say, Okay, I'm gonna click on this button. What would I expect it to do? And it's hard to remember like to remove yourself from what you know, it actually does, but to like, actually think through what the customer would think of. And that, so that's one component that's sort of like the user experience or, you know, UI pieces of it. And then the other piece of it is, okay, the customer is going to click on this button, why are they actually going to click on that button? Like, what? What pain point? are we solving that they have? Is this button going to, you know, reduce their overhead? Is it going to generate them more money? Is it going to make their life simpler? Is it going to reduce stress? Like, there's always some type of pain, right? So it's like, if you think about the pain point, and the business need that you're solving with that button, it helps to inform you of, should you go ahead and code everything behind that button, put in all the effort? And then how much are they going to pay you for that button? Right? So it's a small example. But it's, it's very good idea to think through those kind of simple details, and then try and formulate in your head, a business result.
Tim Bourguignon 21:07
Amen, do that. That's very true. But I find it really hard to focus on this or to, to actively focus on it. It's something that I personally, often forget. And I have to actively remind myself, Well, wait, wait a minute, what would the customer think about this? And what would they do? It's really a, it's a constant, nagging process, I have to I have in my mind, but usually, right. Okay, so what happened after ba.
Brian Pontarelli 21:39
So after Ba, my wife got accepted to the University of Illinois, at Chicago, to do her PhD. And, and so both of us moved out to Chicago, from because I, you know, I'm a, I'm a Colorado native. So obviously, I was, you know, lived here all my life and went to school in Boulder. So we moved to Chicago, and I got a job at orbits. And I started off as you know, sort of just a standard, you know, software engineer, I worked there for about four years, and just, you know, sort of worked my way up. And that was a really large scale change. So even at VA, we were working, we had a lot of code, and we were working on, you know, customer projects, but we weren't ever really getting to the point where we were seeing the size, and that transaction volume and the scalability of something like orbits, or at least I wasn't not my team. And so having worked at Orbitz, you know, I really learned how to make, you know, your code performance, how to make it scale, how to really think in detail about the code that you're writing and the implications it could have on the rest of the system, as well as like how to sort of architect a system so that things can be separate. So if one system fails, it doesn't impact everything else, and it doesn't cascade. So that was a, it was a great, great job. And it taught me a lot about just the intricacies of writing really
Tim Bourguignon 23:14
good code. What was your learning strategy there?
Brian Pontarelli 23:19
So I think he just got it when we were at Orbitz, or, you know, I was at Orbitz and everybody else that I hired on, I mean, you kind of gets sort of tossed on the deep end, and, you know, they're like, okay, we need this feature done, you know, we're gonna train you on the codebase. But then you kind of just got to go code it, and, and then, you know, it might go to production, and it might fail, and you get woken up at 1am. And they're like, Hey, your car's not working, you know, it crashed, can you figure out why and not to go and scramble and figure it out. And as you sort of just on your own, like, you really have to take a lot of responsibility for what you're creating, you know, we did a lot of code reviews, and we helped each other but at some point, you got to, you got to ship it to production, and you got to see if it works. So that's, that was really the the way that we, you know, everybody had orbits learned and, and we got better we got more systems in place to sort of monitor and then to train and just the, you know, code review, but, you know, I was there not, you know, pretty early on I would say and, and so it was it was definitely a different style has like everyone sort of fended for themselves and and a lot of code gone into production all the time and lotta you know, fire drills when things didn't work. So it was, it was a learn trial by fire all say,
Tim Bourguignon 24:44
but it sounds very child actually in very DevOps, to have the people that that should care about a problem really being woken up in during the night and have their hands on it and really care for it and be accountable and responsible. This this is actually great.
Brian Pontarelli 25:03
Yeah, we were very. So we did a lot of microservices. Before microservices with this was a thing. We had a whole DevOps pipeline, we ran hundreds and hundreds of servers for the main app, and then we run ran a few more thousand servers for def auxilary. functionality. So we we had like, massive scale. And so managing that level, you know, you Everything was scripted, everything, you know, had pipelines, everything was very, you know, the humans didn't do a lot of the tasks, right. So everything was automated, because it had to be, it was just too big of a scale to sort of logging into a single server and doing something that just that wouldn't scale.
Tim Bourguignon 25:47
Mm hmm. This is, this is fascinating. Um, if I look back my notes, your first job, you learn how to, to, to try to create a business and try to create working software, then you went into this VA, where you learn how to make teamwork actually work and create a great codebase with a very small team of very motivated individuals. And then you went on to scale things and learn to do it at scale. This is as if it was preparing you to, to go the intrapreneurship way and really build build a big business on your own. That's fascinating.
Brian Pontarelli 26:25
Yeah, exactly. It's, I've learned so much over those jobs. And then when I finally got to the point where I could build my own company, and, and, you know, start start off on my own, I had had the skills that allowed me to build everything and put things into place, and build great software.
Tim Bourguignon 26:48
Tell us about this. So what When did you decide to build the company? And how did you? Did you actually do it?
Brian Pontarelli 26:55
So I think was back in like, 2007 2008, somewhere around there. And I was, I had tried to do a start up. So a few of my friends at orbits, one, you know, quit orbits and started their own company. And they're, they say, Hey, you know, why don't you come come work for us, we, you know, raised a bunch of money. So I went and work for them. And during the course of that, we, we sort of needed some functionality that would allow us to do profanity filtering, and, and moderate, you know, different user generated content. And I searched all over the web, and I could not find anything, I couldn't find anything free, I couldn't find anything open source couldn't find anything to buy, really, there was like nothing out there. And so I was like, well, I can't be the only one with this, this problem, I'm gonna, I'm gonna write it myself. So I started writing it sort of, you know, for the company that I was working for, and didn't get very far. And that project actually got dropped. But I was like, Well, you know, I think I'm going to take this home, and you know, do it, do it like nights and weekends, right, and see if I can, like, get something get this actually to work. And so I worked for, you know, a number of almost a year, just sort of nights and weekends trying to get, you know, the code written, the start that startup sort of shut down. And, you know, it didn't they didn't make it. But I kept going. And I got to the point where I had something that actually works, and it worked pretty well. So I built a website, and put it out there so that people could come and could buy it. And, and people started to come and buy it. So there's you know, there are other people that had the same need. And so we just kind of kept building and building and growing as we went.
Tim Bourguignon 28:43
You see, you see, we had already people around you with not just you?
Brian Pontarelli 28:49
Well, yeah. So um, it was started by an old friend of mine from college, and the two of us started it. And we, we sort of built the first version of everything, got it up and running. But then he, you know, just sort of decided that the startup life wasn't for him. And you know, it was it's challenging. And so he actually left the company. And then I kind of continue to go forward and build. And so he, you know, he went off and, you know, worked, worked at some other companies and did his own thing. And then I continued to build, clean, speak out and build that into a business.
Tim Bourguignon 29:31
And how long do you take for two to become a real company paying for itself and your full time job?
Brian Pontarelli 29:41
So I would say so we launched and then after launch, it probably took another six months to a year to get to the point where the product was generating enough money to sort of cover me Well, almost a year. and a half, I was doing a lot of consulting on the side. So I quit my job, and you know, was making sales, but not enough to sort of cover my whole, you know, all my needs. And so I started doing some contracting on the side, just, you know, programming websites and just helping people out. And just to fill those gaps. Well, I continue to build out clean speak. And then I would say about a year and a half later, a number of very large companies came in, you know, they said they wanted to buy a license. And so that got me to the point where I could go out and actually hire one or two more people to come in and help.
Tim Bourguignon 30:42
Cool and windy. The, the fusion OCE all's I can't speak English tonight. The fusion oath, journey start.
Brian Pontarelli 30:51
So I started. So we actually had a team, right. So we, you know, there were about three or four engineers. And we, we realized that clean speak, you know, it's a great, great product, great business, it's, you know, does very well. But it wasn't, that's not a lot of really large business, right, that's, that's just, it's really nice. There's not a lot of people that can afford to pay for something like that. And they're the companies that can afford it often have built their own. And so getting them to switch is very challenging. So we wanted to build something that would be a bigger business. And so we actually built two different products, we built an authentication system, which became fusion off, and then we actually built a forum, which was called gather at the time. And after we had built them, we sort of just sat down and said, okay, which of these two do we think is going to be a better option. And so we decided that, you know, the while the forum was fun, and it could be really cool to build the it was gonna take them a long time to get to feature parity with all the existing forums like vbulletin, and phpbb, and vanilla. And so we decided, well, let's try this authentication thing, there weren't a lot of authentication tools out at that time that really focused on the end user like customers. Because when we, when you think about customers, the sizes are a lot different than employees, you know, businesses might have, you know, 100, or even 1000 employees, but they might have 10 million end users. And so we, I took the knowledge that I gained from orbits and, you know, some large scale, and we built it into fusion off, so that we could solve these really complicated problems of like, very large user sizes were the big, big sets of users. And at the same time, we wanted to, like fundamentally change the system, because, you know, we've all used LDAP before, and we've all used, you know, really old technologies like Kerberos. And, and they were great at the time, but you know, now it's, we have so much better technology. And so rather than going back in time, and building everything on top of these really old legacy technologies, we said, Now we're gonna build everything brand new from scratch, make it modern, make it fast, make it scalable. And so that's what we did. So we built fusion on.
Tim Bourguignon 33:22
Fantastic. Um, we're slowly reaching the end of the type books, but I want to ask you one question. As you progressed, in your on your journey, how did your your focus change from in engineer towards toward a businessman toward a manager? How do you deal with this changing stance?
Brian Pontarelli 33:44
That's a great question. And you can add in, like accountants, and, you know, financier, I mean, like, when you're starting a company, you have to, you have to do everything. And so I think, you know, the mental shift for me was really an understanding of that, you know, I really love the code. And, and, and it's my passion is to generate really great software. But I also really like solving a complicated business problems and figuring out like, how are we going to make money and like, how can we, you know, get new customers and those type of things. So you just have to kind of train yourself, right? And I think it's just a mental shift, you have to say, Okay, if I'm going to build a business, I've seen businesses that fail, I'm going to build it so that it doesn't fail. And so how do I go about doing that? What do I have to know that I don't know now, so that I can be successful. And that's, you know, you got to study you got to read books and you got to put in the time.
Tim Bourguignon 34:42
And you managed to to grow far enough in each of those of those fields to be to be successful. That's, that's amazing. No room you need to be to be world class in accounting or enough to be to be to have a successful company, you really have to put in the time. And if you want to keep doing development on the side and keep doing management, effective management on the side cetera, it's really it's really a challenge. And I'm challenged by this day in day out. And I really amazed that you that you're so cool, but that's great. Yeah,
Brian Pontarelli 35:23
I guess I just like once you once you put in the time, right, and you figured it out. So like, like you said, accounting, so I didn't, you know, I didn't know what a p&l was, I didn't really know what liabilities were. And you know, I didn't know how to do journal entries. Like, I don't know how to do any of that. So I literally just I had to learn, like, otherwise I would, things would have been a mess. And as an engineer, you like you're like, Well, I have to do this right the first time because I'm not going to refactor my books, you know, a year from now. So I'm going to put the time in to learn in, you know, you read online, and you can, you know, ask accountants, you're like, Hey, can you teach me this? And, and it's, I think it's that constant mode of learning. Like, I want to learn how this stuff works, that allows us this to go further than someone who's just like, will just tell me what button to click, and I'll just click that button. So that's, I think that's a really good module. That's
Tim Bourguignon 36:15
very interesting. That's very interesting. And when do you really when when do you? Do you call it a day and say, Okay, now I need I need someone full time on this.
Brian Pontarelli 36:27
Yeah, I would say like, once, it gets complicated enough, where you can continue to do it, but it takes too much of your time, then you might consider hiring somebody and training them on how to do it, or finding somebody who already has those skills that can come in, and just do it the correct way, right. So they can can see how you've been doing it. And then they can, you know, replicate that, I think that that's, you know, once it's just a little bit too much time, then maybe like 20 to 30 hours a week of your time, then it's probably like, Okay, it's time, time to hand that off.
Tim Bourguignon 37:06
Okay, as I said, oh, we're slowly reaching the end of the time book. So I will ask my usual question. When you hire someone, since since you are your boss, you're an intrapreneur. If you were to hire a junior developer today, what kind of skill would you be looking for.
Brian Pontarelli 37:22
So where we're actually hiring right now, so if anybody's looking. And the one core thing that we look for, like this is super important, is fundamentals. If you understand how computer works, if you understand, like, you know, how the bus in the RAM and the CPU work, if you can understand data structures, if you can understand pointers, and, and how, you know, memory is allocated, and D allocated, like all of those really, really core fundamentals, then it doesn't really matter what language you know, you can always learn the next one, you can figure out like you pick up a new language, you can figure out what goes on the stack and what goes on the heap. And you can answer these questions about any language in any framework in any system. And so it's less important that you know, the language, the exact languages that we're using, it's more important that you understand how a graph works, and how a graph traversal can work. And like how hashmaps or worked in trees, and you know, searches, and those are really more important, because those are the building blocks, and everything else is built on top of them. So if you know the fundamentals, you can learn anything.
Tim Bourguignon 38:31
Yeah, make sense a polio lens is really is really important, if you ever experienced with hiring people that went through boot camp.
Brian Pontarelli 38:41
So we have or we've tried to hire some boot camp folks. And and the really important thing for boot camp. Developers is the exact same. So there's so many boot camps that will teach you how to code. And they'll teach you the you know, how to use a framework, how to get new Angular, how to hook up to a database, they'll teach you all of that. But the question is, like, how does a database actually work? So where does it store it on disk? How do indexes work? Like how do you if you're going to write your own database? How would you actually write it so that it worked? Right? That's a better question. So there are people in coding camps that go and learn that stuff on their own, because they're so excited about technology, they just engross themselves in knowledge and they just everything that they come across they they consume, those are the people you want to hire. Those are the most important. Software Engineering traits.
Tim Bourguignon 39:35
Cool. Thank you for the tip.
Tim Bourguignon 39:38
Um, we really reached the end of the time book. So if people wanted to reach out to you and continue this discussion, where would the best place be?
Brian Pontarelli 39:53
So you can follow me on Twitter. It's B Ponte Torelli. You can email me at Brian at fusion auth.io fusion not that iOS is also our website. And then you can hit me up on LinkedIn. My handle on LinkedIn is void, main,
Tim Bourguignon 40:09
void main. Cool. Um, do you have anything coming up in the in the next weeks or months?
Brian Pontarelli 40:16
Um, you know, I don't think so I've got a I think there's I'll be speaking at a few shows in the fall. But nothing over the summer except for a couple in like investor summits and those kind of things. So I'm bootstrap, but I love to go teach people how not to take money. So I do that.
Tim Bourguignon 40:36
Sounds cool. Sounds cool. Okay. Um, I think we covered it. Thank you very much.
Brian Pontarelli 40:45
Awesome. Yeah. Thank you so much for having me on. That was really
Tim Bourguignon 40:49
my pleasure. And this has been another episode of developer's journey, and we'll see each other next week. Bye.
Dear listener, if you haven't subscribed yet, you can find this podcast in iTunes, Google music, Stitcher, Spotify, and much more, head over to www dot journey dot info. To read the show notes. find all the links mentioned during the episode. And of course, links to the podcast on all these platforms. Don't miss the next developer's journey story by subscribing to the podcast with the app of your choice right now. And if you like what we do, please rate the podcast, write a comment on those platforms, and promote the podcast and social media. This really helps fellow developers discover the podcast and do fantastic journeys. Thank you.