Welcome And Team Introductions

Ava Hinds 0:00

Welcome everyone who's going to be joining. We're starting just a little early just so we can get started. My name is Ava Hines, and I am the host. And today I'm here with our members of the development team, our engineers. So I'll have you guys introduce yourself and just say what you do here.

SPEAKER_00 0:23

I've been here for probably about nine months, and I'm a full stack software engineer. And I help build the things.

SPEAKER_02 0:43

Full stack developer, build support, fix things.

SPEAKER_01 0:54

Hi, I'm Cody. I'm a junior full stack engineer. I'll have been here a year, I think at the end of July. Started off as QA, but recently moved into my position a couple months ago.

What Full Stack Really Means

Ava Hinds 1:08

Yeah. And then what does a full stack engineer do? Or like what's the difference between like senior, junior, and just full stack?

SPEAKER_00 1:17

Generally, it's time and just um how long they've been working in that position and what they're capable of doing. I would say um uh there's not a whole lot of difference between a junior full stack engineer and a senior full stack engineer at that time because they pretty much know the same stuff, just the senior may have a little more experience with some of the things. What do you guys think?

SPEAKER_02 1:42

Generally, I guess a senior will have like more experience with a wider array of technologies, but you know, in the end, like a full stack is just gonna know the front end, the middleware, the back end, the database structures and everything, and be able to support all those.

SPEAKER_01 1:58

Yeah. I would say time professionally, because I've been doing it for a very long time, but I only have a little bit of professional experience.

Ava Hinds 2:08

Yeah, it definitely makes sense, just the tiers of it. But I thought we could start this off by just kind of explaining how all of the work happens behind the scenes with features and the platform.

From Feature Request To Release

Ava Hinds 2:20

But our first question I'll ask you guys is when a new feature request comes in, what is the journey and where does it come from? What are the steps after you get a request in?

SPEAKER_00 2:33

Um, I would say most often everything comes from product. Product kind of dictates what we will build. Um, they usually come out with a product uh requirements document that we usually then use to build either a proof of concept or some some kind of um wireframe that they can use to go back and ask questions and sort of redesign as necessary. Do you guys have other things to add?

SPEAKER_02 3:04

Um yeah, um generally we'll build tickets in uh a jitter system um and put any sort of information, um data in there that would be relevant um for us to develop. Um and then as well as like later on down the line for QA, so they know exactly what we're changing, what they can test um once it's in an environment that they can uh play around with the data and what we've changed. Um and then after that we'll coordinate to move into production.

Ava Hinds 3:40

Yeah, and then how long does this development cycle usually take altogether from request to live?

SPEAKER_02 3:46

Uh it really depends on priorities. Sometimes tickets can sit in the backlog for months, um, or sometimes they can come in uh that week and be pushed out that same week, um, depending on what it is, like especially if it's a bug of some sort, those are usually like a higher priority. Um we want to get those fixed as soon as possible. But if it's you know a new page or a table or something that can be done within about a week.

SPEAKER_00 4:16

Yeah, I would I would concur with what he said, yeah. If it's a bug in production, we try to get it fixed in the same day, even if we can. Um if it's a new feature, we'll we probably will send it through the regular process, have it go through QA and have it be approved by product before we push it out, generally. That's usually how it would go.

Ava Hinds 4:38

Yeah, so kind of just through product and then to you guys into QA and then to live.

SPEAKER_02 4:43

Yeah.

Ava Hinds 4:44

So product kind of is the start of the idea creation. I think um someone said this where it's product is the how and then dev is the why, or the other way around.

SPEAKER_00 4:58

Um, I don't know. I don't know. I've never heard that. Um yeah, I mean I I guess essentially that would be it, but I think we're the how. Yeah, I think we're the how the how.

Ava Hinds 5:10

I was gonna say I think it's the other way around. I was just saying and then how does who decides like what makes the roadmap?

Roadmaps And What Helps Engineers Thrive

Ava Hinds 5:17

Is it the CTO?

SPEAKER_00 5:19

I I think it's all the executives. I think the CTO might have an idea of what he wants to like, what he's driving at, what he's going for. But I think everybody just all product and the the executive staff get into a room and probably talk it out, like where are we headed, what are we doing, what do we want to do, that kind of thing.

Ava Hinds 5:41

Yeah. And then within your team in development, what are some things that make people thrive in development and like or just qualities that really help them in this role?

SPEAKER_00 5:54

To me, um, I like I like curiosity. I like it when people are super inquisitive and ask lots of questions and want to know how to do all the stuff. Um, that that usually it takes uh it alleviates whoever's working on something to not have to work on art alone so that they can work with somebody else and they can hand things off and they can just partner up with people that can work on things. Um, we often will split things up based on just areas of expertise or um what somebody's already working on. Uh as an example, Zach's working on the front end of this new platform that we're working on. And um Zach um mostly does that by himself. We help him out with it a little bit, but um, Cody and I are working on the back end, Ivo is working on the back end, Mark and some of the other developers that are not here are working on different parts of the back end and uh the performance side of it. Um, so I think that's mostly how we kind of split things up. And for me, yeah, um curiosity and I guess just expertise on what they're what they're able to do and what they feel comfortable doing.

Ava Hinds 7:09

Do you decide the back or the front and work based on like what someone's more comfortable with doing, or just kind of like you just you decide there?

SPEAKER_00 7:17

Yeah, I mean, I would I would I would think so. Like I mean, I I can do the front and the back, but I don't like doing the front because I I'm not a design guy, so I don't really like to like come up with all these different designs to for people to uh say, oh, that's terrible. You know, I don't really want to have to deal with that. So I'll just work on the back end, just work on the routes and have somebody else do the front end.

SPEAKER_02 7:39

That is true. I mean, with the front end, you get a lot of um constructive criticism. Say that doesn't look good there, that doesn't place right, you're forgetting that. Um, and then you also have like all kinds of usability features that you have to factor in as well.

SPEAKER_00 7:56

Um but you also get a lot of praise on the front end because that's what people see. That's something that you see. Yeah, the back end nobody really sees, they don't really know what's going on, but um, there's a lot of complexity there as well.

SPEAKER_02 8:10

Yeah, we have a lot of cohesion because we're all come together for one product thing, even though we have our own separate areas that we're focused on. Yeah, yeah.

Ava Hinds 8:22

Well, it's kind of like a misconception about development in that sense, too, because like with front and back end and it's all over.

SPEAKER_02 8:31

Yeah.

Misconceptions And Why Less Is More

Ava Hinds 8:32

What are misconceptions you guys get?

SPEAKER_02 8:35

Um hackers and coders.

SPEAKER_00 8:40

Yeah, I mean, uh a product sometimes product will um come to us with a very uh minimal product requirements and they don't really know what they want. Um, and sometimes with our expertise from having done this a long time, we can help drive what they want or where they want to go and kind of help define it. Um, but I think people that expect everything to be neat neatly defined before they even um you know have anything built, um, it's usually really hard to get to the product uh end result.

Ava Hinds 9:20

Yeah, would you say a misconception is also just like it's just code? Like it's a little bit more than that.

SPEAKER_00 9:26

Yeah, I mean, I I so one of the things that is often said when somebody says, can we do that? It it's just code and you can pretty much do anything. Um, but it gets more complex um when you're asking for you know features that have to go this way and that way. And um and generally I would say that you you want to really be minimalist in the approach at the beginning. Um and it's easier to uh build everything in at once because you just try to cover everything, but that's a that's a bad approach because then you often are pulling things out that you don't want or don't need. So it's it's it's actually better to build uh less than more, and it you kind of add it in as you need it.

Ava Hinds 10:16

Yeah. What do you guys think?

SPEAKER_01 10:20

Um, I concur. Yeah, I agree. Also, it's a it's a lot more planning than it is coding. You know, I would say about a large majority of my time is spent, especially now with AI, is spent planning out what I want to do and how we're going to do it, as opposed to actually implementing the solution.

Ava Hinds 10:39

Yeah. Like what also goes into the planning part?

SPEAKER_00 10:43

So for me, uh it's it's usually I'll take, I'll sit with the product person, kind of ask a bunch of questions, write it all down, and then I'll um I'll start building something out. Um and usually it's just to get an idea if I'm understanding them correctly. So I'll build something out like a proof of concept, or I'll build a data model, something that I can go back to them and say, is this what you meant? Is this what we're really doing? And if this is wrong, um, where am I wrong? What am I doing that you didn't want, or how should this be structured and that kind of thing? And then we go from there.

SPEAKER_02 11:22

Yeah, I agree. Like it's it's better to spend a little bit of time coming up with small proof of concepts rather than implementing something massive that you have to go back and change. So just you know, a step-by-step process and back and forth to build what they actually want.

Ava Hinds 11:40

Yeah. And then I know one of our core values is daring to fail. Do you guys say there's a lot of trial and error along with also development?

SPEAKER_00 11:50

Of course. Yeah. I mean, yeah. I mean, mistakes happen all the time. And there's definitely lots of iterations when you're trying to go from the beginning of the product to the end, because you start off with one idea. And um, as an example, when we came up with this new platform, the proof of concept that I built,

Planning Proofs Of Concept And Iteration

SPEAKER_00 12:13

um, I built it like six different times. I mean, just there are minor changes and it wasn't a lot of work to do it, but it it definitely was, you know, you do one iteration, you realize the mistakes you made, you build another iteration. And a lot of it is um, at least for what I did with the proof of concept, is stuff that I can reuse. So I'm not completely just building stuff from scratch, it's time and then going to the final product. And I have nothing that I did the last like week that I built that I can't use. Um, it's usually it may not be completely portable, like it may not be exactly what I need, but it usually will work for my next phase of the application that I'm building.

Ava Hinds 12:56

Yeah.

AI At Work What’s Real

Ava Hinds 12:59

And then Cody talked a little bit about AI. So we can go into that a little bit. I know it's a huge topic, but how is AI being used in your day-to-day? And what's real and what's hype?

SPEAKER_00 13:12

Um, I'll let Zach take that one first. Go ahead, Zach.

SPEAKER_02 13:19

All right. Um, I'm just gonna read what I got here. Um ARS AI, or actually what we use here is Claude, is very good at coding and remembering project structure. Uh it can search and drill down and find inconsistencies much faster than we can. It has a ominous brain of our code, and it can you know take that into considering consideration all at once. Um, it can make suggestions, think about edge cases, um, perform safety checks and conformity um all at the same time. Um, so the the speed of development using it is a hundredfold. Um it's just it's monumental, it helps so much. Um, so we don't have to rely on just heads-down coding and syntax and you know running into all kinds of null pointers or undefined or whatnot. It'll it'll handle those cases for us. Um but you have to prompt things correctly too, though. You can't just put in a few sentences and just say, have at it. Um there's all kinds of checking, make sure it's it's creating things correctly. So a lot of times you'll you'll do one step forward and then two back just to like get the right context going.

Ava Hinds 14:45

Yeah.

SPEAKER_00 14:45

Um, yeah, and I agree with what Zach said. And um, I think a lot of what we're using it for now is to um automate repetitive tasks, things that we would have to uh maybe like look up or research on how to do them. It helps us find those answers much more quickly, helps us analyze data. Um I mean, you can you can give it a whole bunch of data and say, put this in a CSV or mix it this way or that way, and it will create that example for you much more quickly than if you were having to hand edit it. Uh, it improves workflows, uh, and it it gives you a lot of great insight into your own code if you've built something that can say, oh, you could make this simpler by doing this or that. I think um ideally it's exactly what Zach said, like it just helps helps you code faster and helps you get to a solution more quickly than you would if you didn't have it. Um, I don't think it's a good replacement for a developer yet. Um, it might one day be, but right now I think um it's just a great tool for problem solving.

SPEAKER_01 16:00

Um I like to use it as a digital lorin so I'm not constantly bothering him. Tons of questions, tons of ideas, get opinions.

SPEAKER_02 16:11

Yeah, that is true. You can literally just question it back and forth and not necessarily actually build anything. So, say, you know, I don't know this part of an application, I've never touched it before. You can ask for a summary of what it does and some sort of flow chart just to wrap your mind around this part that you haven't touched before without actually just drilling down into code endlessly.

Ava Hinds 16:38

Yeah. So you definitely say it's a tool that changed everything, like your work, like for workflows and everything.

SPEAKER_02 16:45

For sure. Yeah. Used to Google everything, now you can use Cloud. Yeah, I I can't tell you the last time I've been on Stack It's Stack Exchange now.

SPEAKER_00 16:54

I I still go on Stack Exchange, but yeah. Um mostly because it it does it does give me answers that I don't like sometimes. So like if I'm trying to debug something or I'm looking for a way around something, I'll if I ask Claude and it gives me an answer that I don't think is um relevant or appropriate for what I'm trying to do, I don't want to just go back and forth with it a lot. Usually I'll just go do the old-fashioned way, which sometimes works and sometimes doesn't. So uh it they're both good tools.

Ava Hinds 17:32

Right. So kind of proof checking it and everything like that, because obviously it's not perfect.

SPEAKER_00 17:37

No, it's not.

Ava Hinds 17:40

Where do you think all this technology

Where AI And Tooling Go Next

Ava Hinds 17:42

is heading next, though? Or I know it's constantly changing, but what are you guys thinking it's heading?

SPEAKER_00 17:47

You mean AI in general?

Ava Hinds 17:49

AI or anything else.

SPEAKER_00 17:52

I mean it it's it's just getting better. Um the uh amount of um the lines of uh injection that you can put into it are increasing so that it can handle more context. So I think um at some point it would be able to handle many repositories instead of just a single repository. And um, that's where you keep all your code and everything. So if if you had all the code in multiple repositories, it could cross the repositories. Right now, it it's not really capable of doing that too well.

SPEAKER_02 18:33

So whenever you have back end changes like for the APIs and endpoints, uh I'm constantly having to sync them with the front end. Right. So I'll run a scan and say, hey, what was changed with the back end? And you know what do I need to do for the front end to sync it up? Um so you can repoint to multiple repos at the same time.

SPEAKER_00 18:55

Yeah. So I think that the future will allow it to be um much more versatile at handling handling multiple repos repositories, and basically you wouldn't have to ever say sync it up with that. You would just say what changed and it would tell you.

Hard Problems Context Switching And Infra

Ava Hinds 19:12

Yeah. And then now kind of moving into some of the problems or things you see on a day-to-day, what would you say is the hardest technical problem that you guys have solved, or just something that's definitely can be a blocker in your day-to-day?

SPEAKER_00 19:29

Um for me, it's definitely um when I'm I mean, we we're handling a lot of different things. We're kind of a lean engineering team, there's not a lot of us, and so we need to handle a lot of different aspects of the roles that we are trying to cover. So, like dev operations, like there's um things where you have to go into the Amazon console to build out things that you would then use for the back end or the front end, and so you need to have um take a little time to kind of understand it and learn it that way. Um, I do most of my stuff through command line interface, like rather than going into a UI. Um, and sometimes that can be a little more cumbersome than going into a UI. A UI gives you it kind of shows you everything, but it doesn't really give you all the information that I like to see. So I tend to use a command line so I can see it all and see all the the values that I need for all the inputs and outputs that I'm looking at. Um and then and then just interruptions, which are natural and need to happen because like people have bugs and uh or they find issues with things or they need to add something that's not there. And so those interruptions, it like it you lose context on what you're working on, and it's hard to switch context quickly.

Ava Hinds 20:58

Yeah. What would you guys say?

SPEAKER_01 21:03

Yeah, I mean, I agree. Having to work in multiple uh applications and platforms, having to switch constantly. I mean, here alone we have about what seven applications that each developer also has to be aware of, at least in some in some way. Um what do you say?

SPEAKER_02 21:22

Yeah, um plus in the inside of that, you'll have multiple tickets, I'll say, or projects inside each one. So you'll be building something on this page, um, and then at the same time, you know, fixing something else on a different page. So you have multiple workspaces at the same time. Um so you're you get to think about what you're doing here and then what you're doing on the other ticket um at the same time. Yeah, that's 15 monitors.

SPEAKER_00 22:01

And to Zach's point, like um because we have so many different um workspaces, which are the um the it's basically like the code repositories where all the code exists for a certain application. It's in many different code um structures and code bases. So we have Java, we have Node, we have we have we we used to have some PHP, but we we have a lot of things that are just in different code base. So you have to think about it differently because they're handled differently.

“Easy” Tasks That Become Nightmares

Ava Hinds 22:32

Yeah. And then what was something that looked easy but actually turned out to be very difficult? I think I saw someone say sticky filters.

SPEAKER_02 22:41

Oh well, I remember that. Everybody has had their hands in sticky filters. Um, it was uh a ticket that was really just to kind of sync inputs and filters on multiple pages that didn't really sync up. I mean, visually that looks like they should, but um they had different logic on each page. So once you would change something on one page, it would handle differently on a different page. So you were in like a vicious cycle of like you fixed this, but you broke this, you fixed this, but you broke this, and um you know we eventually just scrapped it because it didn't make sense to have this to get like for all the amount of work that we're being that was being done.

Ava Hinds 23:30

Yeah.

SPEAKER_00 23:33

For me, it would probably be data synchronization. Um because um we store data in various different places and databases and S3 buckets and Amazon, and um on on a whiteboard or something, it seems really easy to just like say, oh, this just connects to this and this connects to that, and you're done. But in reality, it's it's very difficult because you know the you'll have failures that won't copy the data, and people are saying that it's out of sync, and you have duplicate records, and maybe um a legacy platform that copies the data from one place to another, and um, you have network failures and all kinds of edge cases that can complicate that. And um, and right now with this new platform, we have changing schemas, so sometimes data's there and sometimes it's not. We have to copy data from the old legacy um or the old database schema to the new one so that we have access to the new application with our original cognito subs, which is the user authentication for the new platform.

Ava Hinds 24:45

Yeah. And then just a few more questions

What Feels Rewarding Plus Career Advice

Ava Hinds 24:49

to wrap up. Uh what's the most rewarding part of building all these features?

SPEAKER_02 24:56

Um when it's actually completed and working, seeing and it works. Um it's satisfying. You just sit back, like, I built this.

unknown 25:07

Yeah.

Ava Hinds 25:07

Do you guys have an example?

SPEAKER_00 25:10

Well, I mean, the new platform, we we went from you know, a proof of concept to various iterations, and we're slowly getting to the point where we can actually go in, log in, look at stuff, organize it in the way we want, and it's very rewarding to see it. Um, I would also add that like fixing problems is probably my most favorite thing to do ever. So when somebody says we have this problem, this issue where we can't solve, and I can figure out a way to solve that issue, it that's very rewarding for me.

SPEAKER_01 25:43

Yeah.

SPEAKER_02 25:48

People that use the systems, you know, smile and be like, oh, thank you for building this. It makes my life easier. Um, even though like it was a lot of work for us to do.

Ava Hinds 26:05

Yeah. And for someone listening who is curious in a career in ad tech or development, what advice would you give them? I know you said be curious, but what is something that you wish you knew before going into development?

SPEAKER_01 26:24

I'd say that you don't have to know everything that there is. I mean, one, it's impossible, but I put off, you know, beginning my career search for a very long time because I felt like I just never knew enough. And then when I finally went out there, you know, Colin gave me a chance and definitely paid off. You know, you you you won't know everything, but when you start, you know, just make sure, like Lauren said, be curious, ask a million questions, you know, don't be afraid to ask.

SPEAKER_00 26:53

Um, yeah, I mean, I would I would agree with that. Like it there's definitely things you um, depending on the career you're going into, if you're going into you know um programming um or a career in ad tech, um, I would say learn that business, learn about ad tech, learn what you know a CPM is and all those things that so you know how the ad tech business works. Um, I definitely think um that you should learn how to code and not rely on AI to code for you if you have never coded. Um it's very beneficial to kind of understand how underlying architecture works with knowing how applications are built. Um and if you just use the AI, you may be able to build something, but you might not have any idea how it works. And when it breaks, you won't know how to fix it easily or quickly.

SPEAKER_01 27:49

Yeah. Yeah. And AI can make, I mean, AI can make so many things work, but whether it's working in the most optimized manner also matters. Like you need to be able to just tell that the way you built it is the best way or among the best ways.

Ava Hinds 28:05

Yeah. I think it's also more of a tool rather than like if I can't become a coder just using Claude. Because true, if I were to break it, I wouldn't know how to fix it.

unknown 28:15

Yeah.

SPEAKER_02 28:16

This is broken fix it for me. Exactly.

SPEAKER_00 28:20

You probably can do that, but it probably will, like Cody said, not fix it in the most optimized way. And it it doesn't, it doesn't always tell you the right path. It sometimes will send you down a rabbit hole of lots of other applications that you don't really need. Like it overcomplexifies things and makes them way too busy. And you don't need all that stuff most of the time.

Ava Hinds 28:47

Yeah. Well, that was all my questions. Thank you guys so much. This is definitely great. And yeah, that's the end of our webinar.

SPEAKER_00 28:58

All right.

Ava Hinds 28:59

Thanks, guys.

SPEAKER_00 29:00

Thanks. Bye.