Nik Peric's Strategies for Scaling Up a Small Tech Team to a Successful Company

‍

Nik Peric: is a Senior Engineer and Technical lead with a background in business administration. He has over 10 years working with Clojure and functional programming. Currently, he works at Swiss IT consultancy Deep Impact, where they use the web framework Kit for mission critical software. Nik is deeply passionate about working with small teams to create innovative and highly effective products. In a past life he lived and worked in Toronto as the VP of Technology at a market research consultancy Synqrinus, and created the Clojure/north conference. In his free time he can be found noodling on the guitar, trying out all the local foods and drinks, or out enjoying the mountain air.

‍

Host:

Sure, yeah that sounds good. Anyway, how are you doing?

Nik Peric:
Yeah, pretty well, pretty well. Yeah, it's like we had our first snow here a few days ago and it's absolutely beautiful.

Host:
I don't know many people that would say the same in most other places. This is a very unique perspective you have.

Nik Peric:
Absolutely beautiful snap.

Host:
Yeah, you're more a winter sports person or...?

Nik Peric:
Um, more of a summer person, definitely summer. I love the cold, I love the snow, but I don't know... yeah, ski or snowboard or skate, I really don't know any winter sports.

Host:
You're just one of those unique people that like the temperature?

Nik Peric:
Yeah, I think it's super nice, especially when you go from the outside to the inside and it's really cozy. That's the best part.

Host:
Isn't there like, uh, a word... I'm not sure what country, but it's just a word for like that perfect level of comfort?

Nik Peric:
Some... there's some country that has like this one... uh, it could be like some Scandinavian one... like they always have... yeah.

Host:
Yeah, they always have some... You know of... uh... some... I don't know. It's just a very... I found it out a few years ago as a college. There is no word like that for... there's no word like that in the English language, right?

Nik Peric:
So... all these languages all have something that isn't present in English? Like, someone who speaks multiple languages always says, "Oh, I don't know how to say it in English," but it's like it doesn't actually exist in English.

Host:
I always misunderstand.

Nik Peric:
Yeah, yeah. Is English your native language or do you speak anything else?

Host:
I speak... I spoke... I speak other languages, but uh, English is what I usually focus on, or I'm speaking English since I was a kid.

Nik Peric:
I find it's always different, uh, the perspectives people have if you grow up with another language and then, right, uh, pick up English down the line versus people who, uh, yeah, grew up with English. Because I mean it's... I grew up with English. I speak another language too, but I know my ability to explain the logic behind English is non-existent.

Host:
Oh yeah, it just makes sense because that's all you've ever spoken your entire life.

Nik Peric:
Yeah, yeah. 100%. Like the way our vowels work, uh, when the "a" and "a" and in front of vowels versus if there's an "h" and then only if... you know, if the "H" is silent, then it doesn't count, so you use an "a" and it's just like... I can understand how people are like, "You know what? I'm just gonna speak a broken version of this."

Host:
Yeah, yeah, you know. I think it's fair. I mean, at the end of the day, it's about just being understood. Like, that's all language is. You're communicating to someone else and if they understand, yeah, and you understand them, you're good. And if that doesn't work, just hand gesture your way into an understanding.

Nik Peric:
Exactly, exactly.

Host:
Well, uh, thank you for coming on, uh, and taking your time. What time is it over there right now?

Nik Peric:
Uh, it's, uh, just after two in the afternoon.

Host:
Two in the afternoon, and uh, if I got it right, you're in Switzerland right now?

Nik Peric:
Right, yep. Right near Zurich and, uh, I think what for North American standards is a small town, uh, called Winchester, but here it's the sixth largest city in the country, which I guess would be the equivalent of something like Kitchener in, uh, Canada.

Host:
Yeah, I don't know... uh, do you know the size? Is that too much... is that too much, uh, to ask how big?

Nik Peric:
I think it's like 100... it's just 15, 110 or something. It's not a lot of people. Even Zurich is like 400,000 or 500,000.

Host:
Right, that's enough for a soccer game.

Nik Peric:
Hey, that kind of works.

Host:
Yeah, well, yeah, thanks for coming on, and you know, I'm really excited to have you on, actually. I do want to start from the beginning a little bit, so, you know, as I just... just introduce you to the people who are listening... This is Nick, and I got introduced to him from a friend of mine, uh, Dimitri. He is doing a lot of things which we'll discuss today and uh but first and foremost I do want to talk about your interest in closure and why you decided to you know get into that language.

Nik Peric:
Yeah I mean it's a good question and I think it goes back to some point when I was in university. I was studying business at the time and I wasn't particularly happy with uh my choice of studies uh I mean in hindsight I'm glad I took it but at the time I wasn't really sure that it would lead me to a job I like so I started uh tinkering a bit with programming and first I went into the realm of java. This is a language that I learned a bit in high school and I had some familiarity with like I saw you could make cool desktop applications and uh that led me to a few small contract gigs where for like small businesses I would make simple uh desktop apps to automate their workflows and uh in storefronts and things like that. Nothing really fancy but it was kind of like the introduction that got me into programming uh and like a more serious way and at some point I think I think it was yeah over 10 years ago at this point but I I thought okay it really feels like the web is the future building applications isn't so much about desktop apps these days it's more about building uh things that people can access from their phones that they can access from anywhere and I really didn't like JavaScript so I just started looking around um okay what's something that has the like you know can run both on the client and on the back end to like both front and back in and there's many options for that of course uh but the thing that I think yeah yeah I mean especially nowadays I think there's a ton but yeah even back then I think I think you could even do it uh anyways uh there was a bunch of stuff uh but closure was the one that I found in this one red monk Post in oh no wait maybe that that came afterwards but I it was I remember reading something about like ex expressive languages languages that you can do a lot with little code and that was super appealing to me because the thing that I started getting annoyed with in Java was like I kept repeating myself I kept writing the same boilerplate and I I knew there was an easier way to do this with less mental overhead I just didn't know how because I just I'm like a junior at that point uh so then that that led me into closure I think it was the combination of the two I wanted an expressive language and I wanted to write web applications um and then after just I I think it was a lot of bashing my head against the wall because especially back then there weren't a lot of resources available to you there were some like good ones but not the depth that we have nowadays community um and that that eventually led me to introduce it to the company that I was working at at the time and it just grew from there.

Host:
Right and so uh and that's uh how long did it take you to learn it that better way you know because a lot of people you know they get nervous about getting into programming and then uh you know they stop at some point but I feel like you know if you if you just keep going you can get to a level that you're happy with so how did long did it take you to get there to get to a point that I was happy with?

Nik Peric:
I think probably yeah a ton of time uh there's definitely a combination of uh feelings of uh you're not good enough or I'm not uh like I'm not qualified for this I haven't uh taken a formal education and uh computer science so I mean those doubts are always there but uh the one piece of advice I give anyone that's trying to learn coding is to have some sort of project something that you want to build and when you do that you can even even if it's terrible even if the code that you write is total garbage and a few years back you look at it you're like what did I do here as long as you have some motivation to build whatever it is you're going to find a way to make that happen and I know for me I around those years I really was interested in uh tennis and specifically betting on tennis matches.

Host:
Okay um I I don't know which came first but either way it got me really into like some math behind it I just came first the tennis or the bedding, is that what you're gonna say?

Nik Peric: Yeah, I genuinely don't remember if it was like I started, uh, because now I follow tennis almost religiously, but I don't know back then if I did. I think it's like one kind of fed off of the other, uh, but that for me was like this project that just kept going, uh, in the back of my mind and was the thing that drove me to learn more. First in Java, I learned how to scrape websites, how to use Postgres SQL databases, like all these things kind of built on each other that I would later use. But that one project was the one that really kick-started, um, my experience with programming and pushed almost everything else afterwards.

Host: So cool. Having a project, I think, is really the key. But how long did it take?

Nik Peric: Me? I don't know. I would say it was years before I felt confident in my abilities.

Host: How long did that project take you, the tennis betting project?

Nik Peric: Oh, that was like an ongoing thing, but I spent a— I think when it’s maybe my second year or third year of undergrad, yeah, probably second. I didn't have a summer job, so I spent all summer like fully focused on that, working on— um, and that got pretty good for a while, and for a while, it was making some money. I didn't really put much into it. It was more for the fun of it.

Host: Um, at some point, it started decreasing?

Nik Peric: My guess is that, like, probably algorithms also got better at the same time, and they were doing a better job of earning money for The Bookies than, uh, my system could keep up. But, uh, so it took me about a summer to like make something that kind of worked, and then I kept refining it over the years. So like I built ones later. Uh, when I started learning Clojure, it was a way for me to, uh, learn in a new language with something that I was already kind of familiar with and excited, uh, about, even though I didn't really think it would go, uh, anywhere at that point. It was more just for learning and interest.

Host: So you always had it such that, uh, whatever you were building had some monetary return on it, or that just happened to be the first thing you wanted to do, uh, and then you just did it?

Nik Peric: Yeah, I wouldn’t say I— like, I recognize there's this association with betting and you're looking to like get something, uh, some money out of it, but that wasn't so much the aim for me. It was, right, I don't know, maybe I saw a movie or something like excited me at that time about like, "Oh, sports betting, that’s super cool." Uh, I— it was more the— the how do I deal with these probabilities? How do I implement this in, like, in code? And then things just kind of cascade after that, like, "Oh, you can scrape websites, that’s super cool. I can get data off of different things." Uh, so the monetary part really wasn’t important. I don’t think I made much money off of it at all. It really wasn’t, uh, the goal.

Host: Um, okay. And then definitely the things that I’ve done on the side, or at least for myself, haven’t had that in mind, but...

Nik Peric: Okay.

Host: So then, but, you know, I suppose you built all this in, uh, you built all this in Java and then you were able to leverage this to build it in, uh, Clojure, and then if I look here, you really got, uh...

Nik Peric: Into Clojure and became an organizer for Clojure North and, uh, in Toronto, so could you talk a little bit about that and why you started to do that?

Nik Peric: Yeah, um, so let me think. That's like a long time, uh, period, uh, yeah, happened, but, but, uh, yeah, I really got into Clojure. Um, the Clojure community in Toronto is absolutely amazing, uh, and I think even globally, uh, it’s a super friendly and inclusive community. Uh, so I really wanted to help and get involved the more and more I was involved. Um, so at some point, I think we were talking during the meetups.

Host: Okay.

Nik Peric: Um, okay, we have them once a month. Uh, they're still going around even though I’m not in Toronto. I would recommend anyone that's listening that is to go and attend. Um, and we just started talking, "Hey, you know, like there’s all these, uh, events going on around the world and man, I always want to go to one of these conferences." So, but I'd say traveling's like difficult, or some people didn’t have the means. Some people didn’t like to travel, so we started saying, "Why don't we host one here?" Like, we have people that are really passionate about organizing events, uh...Some of us have organized workshops before. Um, ClojureBridge was also—we had a Clojure group for Toronto, uh, so we had some experience. Um, not a lot, and I think we, uh, definitely underestimated the difficulty of running a conference. Uh, but it was enough to get us excited and say, "Okay, let's do this thing." That’s where we started thinking about effective growth strategies to expand and bring more people in. And then it really kick-started that. Building a successful tech team was key to making sure the event ran smoothly with the right people in place to handle each aspect. Um, set up, you know, the non-profit for it. Uh, did all the paperwork, and, uh, that was— that was really awesome. I really enjoyed doing that. Uh, the conference, I think, lasted for two years that we ran it. During this time, we also learned the importance of sustainable growth for tech teams, making sure we could handle more projects without overwhelming ourselves. We stuck to best practices for tech teams, which helped streamline our efforts. Managing tech team members effectively was essential in ensuring we stayed organized and kept everything on track.

Host: Right, right. And you ran it for two years. And then did anyone else take over, or is it sort of on hiatus?

Nik Peric: I think it's in hiatus at the moment. Uh, it's possible that it will come back in the future, but I'm not involved because I don't live in Toronto anymore.

Host: Okay, so I want to talk a little bit about what it was like to have, uh, sort of a context in business and then move into the dev space, and, uh, just talk about sort of what your perspectives were with the conversations you were having with your peers, and what it was like to, I would hope, sort of understand both sides and still be able to communicate some of the concerns.

Nik Peric: Right. I don't think I appreciated the value of a business education and background in tech until having gone through many years of being in tech. Uh, because nowadays I find that the ability to communicate, uh, within your team on a technical level is important, but what's arguably just as important is communicating with people outside of your team and in other parts of the company that aren't technical. Uh, and being able to understand what they're saying but also translate technical concepts to them in a way that's meaningful and important to them, that shows you—that shows the value that your team is doing, that shows the value that you guys are offering the company. Best practices for tech teams often focus on this type of cross-team communication. Uh, and that I think a lot of us in tech struggle with that. And like, I often get super into the details of things, but the business background kind of keeps me grounded in that side of it. Like, I realized that for everything that we're doing, there has to be some sort of monetary aspect to it because that's the way the world works, and you need to hire people and pay them. So you need to justify why they're there and what's the value that they're bringing to the company. Building a successful tech team involves ensuring that everyone understands their contributions in a way that ties into the business's goals. Uh, so I think that that aspect is super valuable. But starting out, I didn't feel that way. I was, uh, I would say a deer in the headlights in some regards. Like, people would say certain terms and phrases and words, and I had no idea what the heck they meant.

Host: On what side? On the technical side?

Nik Peric: Like, there were so many things that, especially as a self-taught programmer, when you don't go to a computer science program, you don't pick up these things as part of, like, a course you would. You'd have to consciously find a way to do that. And when some co-workers might say certain terms, I had no idea what that meant. And, uh, at first, it's—you might feel like embarrassment or a bit of shame. I definitely did. You're like a feeling, "Oh, I don't belong here." I think the thing for me, at least, that pushed me to get beyond that was just asking. Like, I—and I do this now to this day, especially—like, even if I don't understand something, I'm not shameful of it. Like, I'm sorry, like, I don't know what that means. 

Host: Tell me. Tell me about effective growth strategies for learning and development. 

Nik Peric: Best practices for tech teams should include a mindset of curiosity and self-improvement. Managing tech teams is not just about leading but also learning together. I want to understand more. That sounds super cool. Like, it doesn't have to be—you don't even have to say it in like, "Oh, I don't know this. Uh, I'm so bad." You could phrase it in such a way that shows that you're interested in the topic and that you know that they have a lot of knowledge and you want to hear more about it from them. Um, and that's—that's a great way of learning these things, I found when I was starting, and even to this day. Building a successful tech team begins with fostering that culture of learning and growth.

Host: Do you find that—did you find that you had a pretty supportive, uh, co-workers when you were having these sorts of inquiries?

Nik Peric: Yes and no. I mean, I think my co-workers were supportive, but I didn't have a lot of experienced co-workers around at the time I started, I had a very small company. So, there was someone there who did a lot of coding for, um, internally for tooling, and then there was another team outside that the company outsourced, uh, software development to. And they had lots of knowledge but weren't very good at communicating it. Uh, so it, like, I wouldn't say that it was necessarily the easiest environment, but I think any environment you can get, uh, that kind of information, of course, from your co-workers, but of course, I think you need to—especially if you're starting by yourself—you need to push yourself to learn these things outside of work.

Nik Peric: Right. For me, I remember at some point, I joined a reading group in Toronto that was going through The Structure and Interpretation of Computer Programs. I think that's what it's called, yeah. Super solid. Uh, I don't think I ever finished the book, but going through those problems taught me a lot of these fundamentals in computer science that I think you learn at an undergraduate program. Uh, so that's just an example. But doing things like that outside of work helps. Um, yeah. Does that make sense?

Host: Yeah, it does. There's actually a follow-up to that book that I... yeah, you know, that that's pretty good. And, uh, yeah, I was working somewhere and someone, you know, boarded it and I thought I didn’t know there was a follow-up to that book, so I thought that was cool. Uh, so was this all at, uh, uh, Synchronous? Is this where you first started your career?

Nik Peric: Yep. Yeah, so, um, I think when I joined Synchronous, it was a very small company. It was, right, three of us full-time working there, and then it grew to, I think it was well over 20 when I left. Uh, so there was like a period of growth for the company. Um, a lot of it had to do with the fact that we were taking the tech that we first outsourced to other developers and bringing it in-house and growing that, helping automate the process, giving more power to, um, to the team to do what they're doing best, which is, in the case of Synchronous, consulting. Uh, so it was a market, or is a market research company, and like taking, uh, or giving the researchers the ability to do their jobs more efficiently and find deeper insights using the tools that we had was, I think, what pushed the company to grow over those years.

Host: Did you, uh, as you, like, sort of moved forward with your career, what did you think that the people on the sort of project management side or business side—what do you feel like they kind of missed about people who were on the engineering side, where there could be a, uh, a miscommunication that occurs kind of frequently?

Nik Peric: Right. Yeah, um, I remember the biggest one was, uh, at least as I be, uh, I think in the last two or three years of my time at Synchronous when I was the VP of Tech there, justifying why, uh, why my team exists. Like, what value we're bringing. Uh, because you have all of these tools and systems in place that we've built over the years, uh, it lives like a full from start to finish in the market research sphere. Um, collect surveys, analyze data, spit out reports, right? Like, everything in between. So there was a lot there, and at some point, it's sort of being like, okay, so all of these things already exist, like why do we need so many people? Why do we need to maintain tools? Like, what's the ROI on that? So justifying the dollar amounts of, uh, having the people for that. And then, when we decided to scale up the tech team, that challenge became even more complex. The need to scale up the tech team was essential as the infrastructure grew, and we had to ensure that the tools we maintained could evolve to meet market demands while justifying the resources spent. It became clear that effective growth strategies were necessary for us to ensure sustainable growth for tech teams, especially as we navigated the complexities of maintaining systems while scaling. As we focused on building a successful tech team, it was crucial to adopt best practices for tech teams to manage tech teams effectively. Justifying the value of tech investments, especially in non-tech-focused companies, becomes a bit of a balancing act, making sure everything is working and when it’s not, explaining why.

Nik Peric: And I think since I've, uh, uh, so it's been maybe two years or three years since—two, yeah, two years since I've been at Synchronous, but, uh, their mindset has also started shifting in the time since. And they've now split up into, uh, a bit of a tech company and, uh, the market research company, so it's two instead of one.

Host: Well, that's an interesting thing because sort of, you know, if you have something that you built or anything if you have a car, you’ve got to maintain it. If you’ve got whatever it is that you’ve—there are other things that people purchase that they have to maintain. So, what makes this such a hard thing for, uh, sort of this other side to understand? Is it that, is it an operations cost optimization where they’re trying to slice, or are there other things there that, you know, that may not be obvious that make it a little bit tougher for them, uh, to see the justification of the cost or for, uh, for people on the tech side to see why they would want to push in this direction?

Nik Peric: Right, yeah, yeah. I mean, I think you make a good point. It’s like you maintain a lot of things in your everyday life, uh, that you purchase, but I think the car analogy is a great one because sometimes it’s difficult for, uh, especially if you have people in their 40s or 50s from the business side who worked at corporate jobs, selling their lives to understand that, um, technology is kind of like that too. Uh, dependencies become outdated, your systems might get vulnerable, you need to maintain that. Also, the processes of the company change. The people who I worked with at the company, um, changed the way that they did things. The projects that the company did became increasingly more complex and, um, very interesting, but in a way that outgrew the tooling that we, uh, originally built, so there needed to be changes, uh, to their processes. But, explaining all of that always takes some time and patience, and eventually, I think people do understand. At least the people I worked with were fantastic, and they had, uh, on the business side too, I mean like they could see logic and follow through that, okay, this does help us and help the bottom line in the end. Um, but it’s, I think a bit of a balancing act between, how do you do that and also satisfy the developers, um, being like, how about of course, like, this is obvious, we need to deal with technical debt, duh. And that’s when we realized we need to scale up the tech team to address these growing challenges. As we continued to scale up the tech team, it became evident that these adjustments weren’t just about maintaining but evolving. This was key for managing the increased complexity and ensuring that the team could handle the growing demand for new features and systems. By doing so, we could adapt faster to the evolving tech landscape while staying true to the initial goals.

Host: So, you know, I’d like to ask you, so how do you feel your role changed as you sort of moved into different spaces? So, you’re very much hands-on, and then over time, you were just sort of overseeing. And where do you see that your, uh, sort of the distribution of your role changed, and how did that sort of affect you and how did you adjust to that over time? Because it was a bit, it was a small company, so you would no matter what, the adjustment, I would assume, had to be really quick and there’s very little time to onboard yourself from a knowledge perspective and from doing the work time perspective, so there was a way to change there, you had to really cope with it. So, um, you know, that’s one set. And the other side is sort of how did the, you know, do you feel like what you did before, so that non-tech field, where it was able to help you do that faster or at least give you the edge, where they give you a little less work to do?

Nik Peric: Okay, yeah, um, like, I mean, you’re very correct, my role has shifted a lot over the years. Um, and it’s a bit strange to reflect on it. It almost like, I don’t think it dawned on me until you’ve mentioned it because it all felt very natural in a way. Uh, there were a lot of, in a small company, you have to do a lot of different tasks and often things that you don’t want to do, uh, that are not in your job description and you don’t expect to do, but we have to get things done and exist, uh, so that’s what, that’s what you do. And I think the business education helped with that because there’s, yeah, um, it kind of gave you like a rationale as to why you’re doing the thing you’re doing. Like, you realize, okay, I’m going through an Excel spreadsheet, I’m checking numbers for analysts for, um, some reports that need to go to a client, I’m doing that because there’s four other people here and that client is paying half of our salaries. There’s good reasons for the things that, uh, you’re doing that, uh, especially when you have like the bigger, uh, picture in mind, uh, you can kind of rationalize and justify for. But I, I think the role changing is super interesting too because going to be to be more of a manager and a lead and doing things like um interviewing uh new hires

Interviewing students we we took Co-op students so I think for anyone outside of North America that's like the equivalent of apprentices or interns uh who are still studying uh coming and working uh at your company for a short period of time in the case uh synchronous we had uh co-ops for four to eight months and that they're I think having the I I learned all of this on my own kind of thing plus the business background helped because all of these guys were learning closure for the first time and they might have some background from school that I think really helped but most of them had to figure out this language for the first time themselves and uh on well I guess with the help of me and the rest of the team but the background of learning it yourself really helped there

Host:
Right, yeah, anyways, I think I've gone a bit off track from your original question, but yeah, uh, that I think was a fun time. I really enjoyed the changes, and even the changes up to my role nowadays. No, I think it just does make sense because, you know, all the people that you were bringing in were also learning and changing, so this sort of like an expectation to learn and change. For you, it became quite natural, so you just took that mentality with you to all the other levels, and you had enough background on both sides to give you a foundation to keep rotating forward. It sort of speaks to what it's like to be in a culture that allows you and, you know, justifies change and encourages change. It becomes natural, and that's what a lot of people really want in their companies anyway, you know, so that they can change the market conditions. So, it just speaks to the value of that kind of culture and culture in general, and how it can affect people who work in those companies. So I think that's pretty cool. And as companies grow, there's a need to scale up tech team to support these changes, which can make all the difference in adapting to new challenges and pushing forward. In fact, scaling the tech team becomes essential for maintaining this kind of innovative and adaptable culture. It's really about how companies manage to scale up tech team without losing sight of the learning and growth culture that fosters such success.

Nik Peric:
Yeah definitely I think uh well everyone wants to learn and grow I think that's almost like a human drive we want many things like beyond the shelter and food and water we need to live uh running is one of them right uh so moving back a little bit to the tech side I want to talk a little bit about kit and why you did it and what it is
Yep, uh so Kit is a web framework that, uh, Dimitri and I started on I think in 2021. The origins of it, uh, come from the Luminous framework, which Dimitri, uh, built a long time ago and was like de facto the most known, I think, web framework for Clojure. I remember one day at my new role here at Steep Impact in Switzerland, I started working on a new project, and as I would always do, I would spin up a Luminous project as a template. But after the day ended, I realized I replaced almost everything in the template with something new. My way of working had changed so much, and also the Clojure community evolved so much from what Luminous built on. There were many things that were still the same, and lots of the libraries that Luminous provided I was still using, but in just very different ways. So that kind of led me to start thinking, "Oh, okay, this is something that I can adapt and maybe make my own template for personal use," and that's how Kit started. I had a bunch of backend libraries that played well with Integrint, which is the backing for Kit, and I was quite happy with it. I thought, "Oh, this is cool." I think it was on a call one day when Dimitri and I were talking, and I told him offhand almost about this thing. He said, "Oh, that's really cool! I was thinking of redoing Luminous or something. We should work together on this." That got us really excited, which led to some of the other ideas that are still works in progress—really cool things like co-generation. It's the way we have the templating to make it also work with modern Clojure tooling, so a lot of things got us both excited. That really gave us the push to refine it and get the documentation ready, to get it to a place where at least other developers can work with it, like build some examples and things like that. So that's the origins of it, and now it's been out in the wild for I think about a year or maybe less. I forget now; it's been some time. Looking ahead, we're considering effective growth strategies to scale the framework and make it more accessible to a wider audience. We're also focusing on sustainable growth for tech teams to ensure we can maintain the quality of Kit as we expand. As we continue building a successful tech team, we’re also adopting best practices for tech teams to help ensure a smooth development process and make it easier for new contributors. Managing tech team members effectively has been key in ensuring we can meet deadlines and grow the project over time.

Host:
Yeah, I think you finished end of 2021, right?

Nik Peric:
Yeah, so it must be then, about a year or so.

Host:
Okay, about a year, yeah.

Nik Peric:
Yeah, yeah, damn, that's fine.

Host:
Okay, how are you feeling about it now?

Nik Peric:
I love the community response. I love that there are people contributing to it on a regular basis, asking questions, creating PRs, adding modules, things like that. It's awesome seeing it grow. I also love it because I use it at work. So for us at Deep Impact, it's really important because it's the basis of a lot of our web services, and helps us make sure that they run stably and can scale horizontally and do nice things like surviving DOS attacks.

Host:
Right. Do you guys use ClosureScript on the front end?

Nik Peric:
No, so we mainly use TypeScript and React on the front end. That's why I think—so this is maybe, in my opinion, one of the improvements we could have with kit. We have a ClosureScript module which generates the front-end side of things, but by default it's not really part of the template because at least at the time I was really focused on back-end development and the stability of, like, how do you scale on the back end and how do you do it efficiently? So that's one part that I think we could improve on and make a lot friendlier for ClosureScript developers.

Host:
Are you one of the million people that have tried OpenAI and sort of that new way? Have you seen anything in that space?

Nik Peric:
In ChatGPT, you mean?

Host:
Yeah, yeah.

Nik Peric:
It's funny you're bringing it up. I think it was on Thursday a friend of mine from Toronto messaged me and he was absolutely like over the moon about this thing, and I'm—I don't know, I was kind of skeptical. I thought, "Oh, maybe this is just hype, it's just another chapter."

Host:
Yeah, yeah.

Nik Peric:
I'm not too into some of the things that have come out of the tech world in the past couple of years, so I was like a little bit reserved. But then I started using it on Thursday. I just started asking some basic things, like, "Here's some texts I want to send a client, can you make it less technical?" and it gives you almost like a 95% perfect thing that you should send in an email.

Host:
Right.

Nik Peric:
I was super impressed, and then you can even start refining it. You can ask, "Okay, make it shorter," or "Make it less formal," or "Make it more formal" or whatever, or even to generate code. It did—it's not always working code, but it's like a start.

Host:
Right.

Nik Peric:
And I—it's like the first time I think in a long time that I've been super excited about a new piece of tech. I don't know yet what we can all do with it. It almost feels like we're on the cusp of something new and we're all trying to figure out, "Where does this lead? What do we do with this new technology?" But it's genuinely impressive.

Host:
I think so. It's interesting. I always thought of Closure as something that made meta-programming easier, and then we have ChatGPT that is sort of making meta-programming easier. So I'm always wondering to myself, you know, how do we get closer into that space in a way, right? Because Closure is built on the idea that it can really do that. The whole structure of that language is very suitable to reconstructing itself and sort of improving on itself. So, you know, I just thought that was interesting now that this has come out.

Nik Peric:
Yeah, and I mean, I think lots of features that we've seen in functional programming and Closure specifically end up in the mainstream or have ended up already in the mainstream in the past—well, since I started working with it. Like, we have lots of new functional features in Java now, in JavaScript. Also, uh, yeah, yeah, C-sharp, which is Java also essentially on .NET, uh, yeah, so it's, yeah. And I mean, yeah, also I think we talked at one point about like React and, uh, things like Reframe was Redux before Redux existed and then some of the things that React's now doing is essentially like a reagent atom, uh, right?

Nik Peric: Exactly, it's cool.

Host: Well, you know what? Thank you so much for being on the program and like trying to talk to us about some of the things that you're doing. Uh, it'd be great if you could tell us where we can reach you, where we could find you, and, uh, some of the things that you're interested in doing aside from...

Nik Peric: Okay, yeah, totally. Uh, so, uh, you can find me on GitHub, uh, just search I guess for the Kit framework or, uh, I don't know, do I give you my GitHub URL? If that's, if you feel comfortable.

Host: Yeah, it is. It is easy to find.

Nik Peric: Yeah, exactly, so you can find me there. Um, yeah, I, Dimitri and I have some plans for Kit. Uh, we've been talking about it recently and, uh, I'm not gonna announce any of them yet, but next year I think we're gonna push for some new features and development there. Uh, and outside of that, genuinely, this ChatGPT thing has me over the moon, so I'm really trying to think of what I want to do with this, uh, and maybe I'll start playing around with that space as well.

Host: Well, thank you very much for being on. Thanks for taking the time. This is Nik Peric, and, uh, you know, enjoy your winter.

Nik Peric: Yeah, thanks. You as well. Take care.

Host: Thank you.

‍