Decreasing Java Build Times with Pratik Patel | Ep. 10

Tim Berglund talks to Pratik Patel (Azul Systems) about his career in developer relations and Java. Pratik’s first job: computer lab assistant at UNC Chapel Hill. His challenge: working at a large enterprise with manual, slow build processes and transforming them through automation.

SEASON 2
Hosted by Tim Berglund, Adi Polak and Viktor Gamov
Produced and Edited by Noelle Gallagher, Peter Furia and Nurie Mohamed
Music by Coastal Kites 
Artwork by Phil Vo 

•  🎧 Subscribe to Confluent Developer wherever you listen to podcasts. 
• ▶️ Subscribe on YouTube, and hit the 🔔 to catch new episodes.
• 👍 If you enjoyed this, please leave us a rating. 
• 🎧 Confluent also has a podcast for tech leaders: "Life Is But A Stream" hosted by our friend, Joseph Morais.

Transcript

SPEAKER_00 0:00

Today, from library assistant to JVM advocate, this is Confluent Developer.

SPEAKER_01 0:06

And everyone was like, wow, this is amazing pratique. And I said, thank you. I did this for myself, but I'm glad you like it too. So I went to the person I work for and I said, Wow, how long have you guys been doing this? Of course the answer is forever.

SPEAKER_00 0:20

I said, why don't you let me fix this? Hey there, everybody. I'm Tim Berglund, and welcome to Confluent Developer, the podcast where we explore the journeys of software developers tackling some of the hardest problems they've ever solved. In this episode, I'm interviewing Pratik Patel. He got his start as a library assistant in college. That was his first job helping people use computers. And now, as the VP of developer relations at Azul, well, he's still kind of doing that same thing. Prateek and I have known each other for a long time, and I talked to him today about an early build automation project he tackled back in the Precambrian era of Java builds, where he learned the importance of having empathy for his fellow developers. Let's get to it. Hey, Deke, welcome to the show. Hey Tim, how are you doing? Doing well. Hey, uh tell us a little bit about yourself. What are you uh what are you doing right now?

SPEAKER_01 1:19

Yeah, so uh I lead the developer relations team at Azul Systems. And what we do over at Azul is we're a Java-only company. Uh we basically make JVMs and tools for people who build and deploy Java applications.

SPEAKER_00 1:35

Incredibly important stuff. And a fellow DevRel professional.

SPEAKER_01 1:39

And a fellow DevRel. I think we have the same job titles, uh surprisingly. Yeah.

SPEAKER_00 1:46

Yeah. That's us. Who'd have thought?

SPEAKER_01 1:48

Who'd have thought? Ten years ago, we not me. Tim is a Tim is all important and famous, and I'm just neither one of those, but that's okay.

unknown 1:56

Okay.

SPEAKER_00 1:58

So um what's the first job you ever had, pratique?

SPEAKER_01 2:03

So um not counting uh the free labor that my parents got out of me. My mother and father owned a small business, uh, and that's not very interesting. Uh it was, you know, doing work since and you know how it is with the family business. You're you're eight years old. You can go and like, you know, mow the lawn or go do this and that, and you know, whatever it's like. Things that are too heavy. But my my first paid job where someone else was paying me, and I wasn't paid in uh a rortie or with you know like clothes and stuff, um, was uh actually when I started at university. Uh I went to UNC uh for undergrad, actually grad school too.

SPEAKER_00 2:43

That's uh Northern North Carolina, not northern Colorado.

SPEAKER_01 2:47

The University of North Carolina at Chapel Hill. So the Tar Heels, as we like to say. You may, if you're not familiar uh with the University of North Carolina, uh you may know our most famous graduate is a fellow named Michael Jordan. Uh maybe you heard of him. You you probably have heard of him. I I met the guy multiple times, actually. Oh, that's another story for later.

SPEAKER_00 3:08

That's another podcast. That's been a target.

SPEAKER_01 3:10

That's a great podcast. Wonderful guy, by the way. Um, so when I first joined, uh when I first went to UNC, uh, you know, like every other uh poor student, uh I needed uh money for Taco Bell and for beer. Um so I took a job as a computer lab assistant. So this is many, many years ago. Uh and my job was to basically sit at a desk, and when someone had a problem with the printer, I would go help them with the printer. If someone had problems with like something on the computer and device they were using, you know, as a computer lab, uh I would go help the student or you know, whoever um sort it out, right? It's like, oh, I can't get Microsoft Word to work, or I'm trying to print this. And and it was actually a great job because I got paid uh for those for those days, especially, uh, quite well to sit at a desk and about 80% of the time I would just do my homework. So it was great. Yeah.

SPEAKER_00 4:14

I love it. Paid to do your homework and flex the flex the computer troubleshooting skills.

SPEAKER_01 4:19

Well, it was actually quite more than that. It's you know, I got to help people. That's how I got into um very, very early on, into kind of teaching, if you will, or you know, training kind of stuff. You know, it's like, oh, I don't know how to do this in Word, or I'm trying to use this software to like build this diagram for my class, and I would go and help them and stuff like that. And uh I got to meet a lot of great people through that. So some of the folks that would routinely come into the lab that I worked in, they would uh, you know, I would see them on campus and uh they would say, Hey, what do you hey there's pratique? You're the dude that helped me do, you know, figure out how to make words italics in Microsoft Word or something. Uh and they're like, Hey, we're going out to this bar on Friday, why don't you come? So it was just a great way to meet people as uh, you know, as you do at uh at college, uh to you know, you meet people and expand your horizons and your friend groups and stuff like that. Exactly. Yeah.

SPEAKER_00 5:14

Oh, awesome. Yeah, and teaching's always been, I mean, for the 15 years I've known you, that's always been a part of who you are.

SPEAKER_01 5:19

So that's uh and it's it's great. Uh I took a little bit of an aside uh to to do a startup for Bent, and even when I was working in a large enterprise company, uh, as you know, we both did uh a little uh technical road show that had training for many years.

SPEAKER_00 5:35

Yes.

SPEAKER_01 5:35

Um and then uh we both we both maybe at the same time pivoted to doing developer relations, which our job is basically helping people learn our technologies. Um that's what we do every day, right?

SPEAKER_00 5:49

That's what we do, and uh we both love it.

SPEAKER_01 5:51

I certainly do.

SPEAKER_00 5:53

So to be to do to do what we do, um, you know, there's a lot of teaching, uh, but it also requires being technical, having uh background as an engineer. So in your your history as an engineer, tell us about the most interesting problem you've ever solved.

SPEAKER_01 6:13

Okay, so uh as uh as you can imagine, there are many of them in a long storied and uh select, shall I say, in famous career.

SPEAKER_00 6:22

It's just hard to pick because there are so many good ones. I well, you can we could have you back on the show. So yes, of course.

SPEAKER_01 6:28

So so I think my my favorite one, uh it's not super, super technical, but uh I took a job um at a uh large company here in Atlanta when I first moved here uh after being in uh in London, England for five years, but out of grad school. Uh another story, of course. Um and uh at this, and this was a many, many years ago, right? So so for those of the younger listeners out there, uh you probably have not heard of this version control system called PVCS dimensions.

SPEAKER_00 6:58

Okay, it was we'll put a link in the show notes to the Wikipedia page.

SPEAKER_01 7:04

I I'm sure somebody still uses it, but but anyways, this is before subversion, and you know, and after that came Git, which is what everyone pretty much uses now, as you know, as uh the folks uh listening now. So, anyways, it was it was it was a version of control system, okay.

SPEAKER_00 7:21

And one that kind of was larger companies, a commercial enterprise kind of thing, right?

SPEAKER_01 7:25

Yeah, it wasn't open source. Yeah, it you know, back then there wasn't really any um it's CVS, but but but even but even predates uh CVS, yes, exactly. Okay, yeah, yeah. It's like it goes way, way back, right? Um, and it wasn't the most uh flexible, it was quite a rigid tool. Um and anyways, we were using this thing to manage our source uh con uh source system, and when you wanted to check stuff in, it would lock the repository so no one else could check anything in until you release the lock, etc. etc. Right. Actually, that's not the main crux of the story. So uh so so you know there was a bottleneck there, all right?

SPEAKER_00 8:03

But those are it's not the crux of the story, but I want to make sure everybody understands. There's one thing you do to lock and then you check in code, and then there's another thing you do to unlock. This is not like a transactional or you're you it just waits till you commit the transaction, maybe you die, maybe you go home for the weekend. What could go wrong?

SPEAKER_01 8:20

So what could go wrong? If it was extremely inefficient to the way we work today, so thank God we have git. Um, so what would happen is that you check in code, and then uh the the way that we did a build, like today we we have you know CI pipelines and we use tools like you know Jenkins or whatever, and it's like it's it's amazing, right? Uh it it makes us more efficient as a dev team uh today. But uh so there was for every uh release of approximately 30 developers on this team, they would pick one lucky person, and that person's job was when they received an email that said, Hey, I need a build, that person go and lock the repo. They would pull down the source code and spend uh I would say the next two to three hours typing stuff in on the console and clicking things to produce a build. And that build they would then shepherd into a server for people to test.

SPEAKER_00 9:20

World class automation here.

SPEAKER_01 9:22

Yeah, and again, again, for our younger viewers, this is many, many years ago, right? So it's this is what it was like this is what it was like in our day. Right. So Tim, what does the word sneakernet mean?

SPEAKER_00 9:33

Sneaker net, that means uh you write uh data like a file to a floppy diskette, and using your sneakers, you walk over to the computer of another colleague and insert the floppy diskette into that colleague's computer so they may copy the file.

SPEAKER_01 9:50

Yes, so that's that's great, right? So what thankfully this was past the sneaker net era. But so so the the the problem there is that now you had to essentially dedicate an engineer whose primary task for those three months was to build and deploy the software. And I came in and uh within uh a day or two, I was like, it was incredibly frustrating because I was like, all right, I'm ready to do a build. And I email somebody, that person's out to lunch or coffee, wait for them to come back, they do the build, and three hours later I am able to click a button somewhere to see if my code worked. And you can imagine very frustrating. Um, so I went to uh the person I worked for and I said, Wow, how long have you guys been doing this? Of course, the answer is forever. I said, Um, why don't you let me fix this? Um and uh I I did have a purely, you know, let's improve the team motivation, but I had an extra motivation on top is because when I first started there, I was working as a contractor, getting paid hourly. So his question was, well, you know, can you do this and your regular job? And I said, Yeah, of course I can. Just pay me overtime. And they're like, Okay, uh, how will this help? I said, Well, you can take that one person you assigned to do this, and instead of them not being very productive and contributing to you know features or bug fixes, sure, they will actually be able to be part of the development process for the customer.

SPEAKER_00 11:26

Do things that help make customers' lives better and not just before. Yeah, yeah, yeah. Build features.

SPEAKER_01 11:30

Right, let's just say keep it at build features. And so they agreed to it. I got paid a bunch of overtime for the next two months while I pulled this together. Uh, and everyone was like, wow, this is amazing pratique. And I said, Thank you. I did this for myself, but I'm glad you like it too.

SPEAKER_00 11:44

And that that was the thing that you pulled together to talk about that. Now, a quick word from our sponsor. Confluent Developer the Podcast is brought to you by Confluent Developer, the website, which has everything you need as a developer of data streaming systems. And it's completely free. We've got curriculum, hands-on exercises, conflicts tutorials, the online data streaming engineer certification, also free. A way to find a meetup near you, folks are free, everything out there. I really want you to be successful in your journey as a data streaming engineer, and this is the site that has what you need. Check it out at developer.confluent.io. That's developer.confluent.io. Now back to the show.

SPEAKER_01 12:26

Yeah, it was basically just uh I just wrote some bash scripts. And, you know, the hard part was figuring out how to interface with uh PBS PVCS dimensions uh because they had like some low-level library thing and being able to automatically pull that code. And you know, it was like was basically uh I think a good way of doing uh putting it, it was like the the pre pre precursor to DevOps. Um so it's like you know, let's automate this the this DevOps thing, or basically this development thing, or what we would call now DevOps, uh, because it should be automated and uh you know things will be faster and everyone will be able to be more productive, and I can finally release my frustration of having to wait three hours for a build. I was able to take it from about three hours to the automated build took, I don't know, it's it was still slow. It took about 15 minutes with all the tests and pulling the code and building a jar file and then putting it on a server and all that kind of stuff. But hey, 15 minutes is still better than three hours.

SPEAKER_00 13:24

This was this was Java.

SPEAKER_01 13:26

Um it was a Java application.

SPEAKER_00 13:29

Was um if I may dig into it, I think there's more story you want to tell, but I just want to build tools like Make. I mean, make predates our careers. Uh we both started writing software in the 90s, and uh Make was there when I walked in the room. Um I didn't personally come into the Java world until about 9099, 2000. And um my first Java builds were with make, because it's what I knew. I had been writing C code and I I just I wrote make files for Java. And then kind of ant came along. What what was building the Java code in this incredibly non-automated build that you started?

SPEAKER_01 14:13

Um you actually just said it. Uh we were using a combination of makefiles and ant.

SPEAKER_00 14:19

Okay. Again, links in the show notes. Um kids, ant is yeah, we'll we'll we'll we'll link link you to it. You can read about it.

SPEAKER_01 14:27

Yeah. Uh yes, and uh it uh I mean it was it was a combination of ant and make files, and then when I got done with it, uh some bash scripts. Um I I avoid using Perl uh whenever possible, even though that would have helped me do it faster. Uh, because I I like to say that pearl is a write-only language, right? You write some Perl and then you come back Yeah, you you come back like an hour or two later, and you're like, I don't understand what this does anymore.

SPEAKER_00 14:58

I have um I don't know if this is a flex or a shame. I've never written one line of Pearl. So I just never never touched it.

SPEAKER_01 15:07

I don't think it's either a flex or a shame. I think you you you you chose the right path of like being. I I did some Pearl when I was in grad school and I was an undergrad because that was kind of you know, you can do it work.

SPEAKER_00 15:18

You didn't think that was gonna end up on the internet. You know, it's we it's we've all made mistakes. Yeah, um, so you the the bash was automating the ant and make and testing and and was there testing that it was executing?

SPEAKER_01 15:34

Oh yeah, we we we wrote unit tests. We wrote unit tests, and there were integration tests too. Okay, those were kind of thin, but uh there were uh unit tests. We were using it was there J Unit? Was has there it indeed was J Unit. Okay so J Unit's been around for a long time. Yeah, it has.

SPEAKER_00 15:48

That's all that's all like stuff. I mean, Kent Beck was doing that stuff pretty early on, so yeah, okay.

SPEAKER_01 15:53

Yeah, yeah. Thankfully, you know, it was uh and and this place had uh uh this company had a fairly good level of understanding of code hygiene. Uh you know, no, it it's even back then. Uh back then we we didn't have uh as an industry, we didn't have that much of an emphasis on writing unit test. So we wrote unit test. We would, you know, if today we take a different approach to unit testing. It's much more rigorous, and we have things like code coverage, you know, and we we we've evolved as an industry with a design discipline as much as anything, right?

SPEAKER_00 16:27

It's an approach to designing software at a low level.

SPEAKER_01 16:31

Yeah, absolutely. But but we were writing unit tests. Um, you know, they we would write them, you know, we would do it differently today. We'd be a little bit more exhaustive in writing unit tests and stuff, but we did write unit tests, and that was a metric that uh that we used. Um, and that's something I pushed later uh quite hard. Uh like okay, let's put some rigor around these this automated testing stuff. You know, instead of having 30-40 percent of our stuff covered by unit tests, let's get to 70% at least. So that's uh something I pushed a bit further uh after I was there for a little while and uh you know had uh a little bit of street cred, as they say, within my team and my company.

SPEAKER_00 17:10

So and it's it's funny, pratique, because this kind of thing is is just table stakes now. Like this is this is just what I mean. We've got uh you know a diversity of tools, and people get in fights about which tool is better for building things, you know. It's it's it's sort of the uh the the luxury of being able to have infighting around how we automate builds. Back in the day you had to write all this stuff, and it was an initiative that you uh you had to do a little persuading. So I mean I see why you you chose this as an answer to most interesting problem because uh you know, I I can see how transformative it was. But talk to us. What happened in the organization? What did you learn? Like, what did you carry with you?

SPEAKER_01 17:55

Um it's it's uh it it it it was transformative. Uh obviously down like you know, at the lower end of the development type of uh discipline. Um but uh once once my team did it, other teams were like, oh wow, this is awesome, right? It was it was a big division that had multiple multiple teams inside of it, and everyone was kind of doing it the same way because that's how everyone does it, you know, this is how it's always been done kind of thing. Uh, you you're well aware, and our and our listeners will be well aware of uh, you know, what momentum uh means to different dev teams or to dev teams. You know, this is how we've always done it, right? And then someone has to go in and shake things up and say, let's let's try to find a better way to do it. And you have to convince people, and you know, and thankfully, uh I feel like most people in our discipline, uh in uh in the careers that we do uh generally tend to be open-minded about uh making positive change, especially when it's stuff that saves time and you know allows you to have less frustrating experience. Um, right. So, I mean, part of the stuff that we do, for example, Tim, is we focus on part of what we do is focus on developer experience, right? How do we make it easier for Doug people to do stuff? Um, and you and I both think about this not all the time because you know we have the education portion and other things that we do as part of developer advocacy and relations. But uh, we you know, I go back to uh my uh product managers, for example, at Azul, and I give them feedback from what developers tell me in the field to say, hey, you know, I was talking to some developers about uh Azul Code Inventory, uh, for example, and I and I say, you know, they would like to see this, and you know, we'll think I'll think about it and say, yeah, actually this makes sense, and I'll go to the product manager and say, this will help improve the developer experience when they're using this tool. So let's try to make it a feature, right? So uh, but yeah, the the impact was was pretty big, uh, you know, again at the low level. Um and uh thankfully it uh it didn't require a lot of it didn't require any additional like hardware and you know stuff like that, just required it just required time. So it was a pretty easy sell uh when I went and pitched the initial case to them. Like, hey, it was actually very black and white in a lot of ways. It was uh we can take a person that is not doing anything productive and make them productive for business features. So not hard to sell that to somebody, right? And all it'll cost you is two months of one person hacking on this and don't really need to touch it again, doesn't need constant maintenance and stuff like that.

SPEAKER_00 20:28

So right, fairly static build kind of thing.

SPEAKER_01 20:32

Yeah, it's I mean we we changed it about two years later uh to use the state of the art in source code management, a tool called Subversion or SBN.

SPEAKER_00 20:43

So early 2000s. That was I mean, that that was uh a remarkable innovation.

SPEAKER_01 20:48

It it was it was state of the art, uh it really was. Um and it ran so much faster than PvCS dimensions, and you didn't have to lock the whole repo, which was the big thing.

SPEAKER_00 20:58

So exactly. Yeah, exactly. You could actually collaborate with people.

SPEAKER_01 21:02

Yeah, yeah. It's it was you know that that's when the joy of uh uh fixing merge conflicts came into being. Uh, but I think we discovered as an industry it's much better to fix merge conflicts and to lock a repo that you know five or ten or thirty developers are working on because that slows everybody down.

SPEAKER_00 21:19

So exactly. No, that's that's that's the thing. Um and uh well, you know, same thing with uh the database rows that we might want to edit concurrently. We uh have higher bandwidth ways of managing that than everybody go away until I'm done.

SPEAKER_01 21:34

Yeah, and actually, if you don't mind taking a small pivot here, uh I gave uh then and you like this because uh I actually watched your video on this topic uh about a month or so ago. It was your little Apache Iceberg uh video that you had up on YouTube.

SPEAKER_00 21:49

Yes.

SPEAKER_01 21:50

Um and I I actually I did a presentation at the Atlanta Java User Group just this past Tuesday on iceberg. Um iceberg and Spark and artificial intelligence, right? now you gotta sprinkle a little AI and everything, right?

SPEAKER_00 22:02

So you can't not.

SPEAKER_01 22:04

Yeah. Um, but but that's one of the reasons I really like iceberg is because it it allows you to um decouple almost your data from whoever wants to use it. Yes and and it gives you the nice catalog so it's described and it like it makes you more efficient as a as a company because now you have different dev teams that can use the same underlying data set and they don't have to it's not you know it's still sitting in one uh once one Amazon S3 bucket somewhere but it allows anybody access to it so multiple teams can use it and um you don't have to worry about because it's decoupled from compute you can you can use Trino to look at that Apache iceberg and I use Spark in my example or you know and of course you know you work at Confluence so I could use Flink or Kafka and I could pump data into the same Apache iceberg you know a warehouse and I don't have to disturb anybody else or or for that matter ask anybody else's opinion if I could do this permission if I could do this I can just make it a separate table or a separate namespace right so anyways.

SPEAKER_00 23:14

It is it's a it's it's uh game changer in so many ways really opening up a lot of stuff. And I just so I you know I've never heard this story from you before you and I have have known each other for a long time but I think it's really cool how uh this there's this early career super impactful thing uh that really was focused around um a little bit of a cheesy phrase but but empathy for your fellow developers right like you know you just want you just want this to be better you want things to be a little easier to use uh it wasn't you know let me tell you about this really cool data structure that I wrote a paper on it was I just want to make this thing better for people so we're not doing dumb work and you know then seeing your career unfold as you know largely an educator, right? Trying to help people be better at things and know things and and be more effective. I I I love the connection there.

SPEAKER_01 24:09

Yeah thank you it's you know I'm sure you have a ton of stories uh around the same kind of thing um but I think uh in a lot of ways it also helped set me up uh you mentioned career uh in in terms of a kind of a longer arc uh for you know not just you know it starts with the empathy of like okay let's make everyone's life on the dev team better to it it's a natural kind of progression into more of a leadership team lead type of role and then you know onwards from there. Exactly um so so you know for for those folks who are newer to this uh software development world uh if you want to uh become a leader that's a great way to have a stepping stone it's like how can I help my people on my dev team right and and that you know that it helps you it's not just the empathy part then it also helps you think about the bigger picture and leadership is a lot as you know and everyone knows leadership is also a lot about thinking about the bigger picture. The bigger picture doesn't have to be this big right it can just be how can I make my dev team more efficient or how can we do cloud deployments that um don't use as many resources so that we save the company money so we can spend it on something else that's more impactful. I don't you know all those kinds of things.

SPEAKER_00 25:28

So my guest today has been Pratik Patel prateek thanks for being a part of ConfLo developer.

SPEAKER_01 25:35

Thank you Tim for having me