Douglas Arcuri 0:00 You know, as a software engineer manager, the last thing you want to do is jump in immediately and do technical contribution. So I was trying to find ways in which I could solve the gnarly problem for the team. That problem was essentially a foosball table, believe it or not, and how I learned about this was really it was doing the initial one on ones initial conversations with the team and this problem was outstanding for and must have been about a year or two. And the problem was, essentially, there was a foosball table that the teams wanted and we had a few really expert foosball table enthusiasts in our teams, but they didn't have a foosball table close enough. And they wanted one. So I said, All right, let me let me take on this challenge as an engineering manager took about two to three months to solve the problem. But what I learned through it was that you know, it helped build a lot of connections throughout the company, everything from the engineering teams, from procurement from facilities from everything, right building those relationships and networks, if you will, with people who will eventually help my team as well.
Tim Bourguignon 1:05 Hello, and welcome to developers journey, the podcast bringing you the making of stories of successful software developers. To help you on your upcoming journey. My name is Tim Bourguignon, and today I received Douglas archery. Duck started modifying the house live video game in the 90s and never left the IT field ever since. He worked as a consultant or mobile developer, and recently as an engineering manager will hear probably about this in a few minutes. Duck. Welcome, Stephanie. Thank you for having me. The show exists to help the listeners understand what your story look like and imagine how to shape their own future. So let's go back to your beginnings. Doug, where would you place the start of your developers journey? I would have to say it started probably in high school. My father and mother weren't really into computer
Douglas Arcuri 2:00 much and there wasn't really any computers in the house. However, they did realize that you know, at one point, maybe it's good to have a computer so they bought me a gateway. And at the time, this is probably about the late 90s. I was already into video games at that time I was playing Nintendo Super Nintendo, and even Nintendo 64 but I received this this computer from my my parents and I picked up a game called half life. Half Life is a first person shooter Half Life is based on a game from from Valve, which is a software development company. And I started tinkering with half life, if you will, by developing modifications for a mode called deathmatch. And at the time, I didn't really know much about software engineering, but I didn't know you had to make some modifications using c++ with is a language. So I basically picked up the Microsoft Visual Studio 6.0. And I started building these libraries to make these modifications. Basically, I first started off with simple tinkering of the game mechanics. So things like, you know, making changes to the ways in which the weapons operate, or shooting more rockets, if you will, and just kind of tinkering from there on out. And over the course of time, I started picking up basically a modification called while at the time I called it cold ice. And essentially the the, the purpose of that modification was to, you know, make deathmatch a little bit more intense. And, you know, I launched the first few modifications on planet HalfLife at that time, so that was part of the the game spy network. And it was really relatively successful, I've had many thousands of people play that. That modification, I guess what I learned through that experience is, is to basically use all the tools in the toolbox as a software engineer. So I learned a bit about developing a website because at the time, I had to develop the website for a planet HalfLife and host that modification called cold ice. I also had to develop the game. So the game mechanics, learning about compiling the DLLs learning about the language itself, what types are, what functions are that type of thing. So the Curiosity got to me, and I became, I think, a software engineer at that point. And then Apart from that, also learning about working online, right, so at the time, this is the late 90s. I picked up IRC, I even had IC q at that time. I've been believe my IQ number was six digits, which was probably really cool at that point. I remember that right?
Tim Bourguignon 5:06 I do I do.
Tim Bourguignon 33:39 You're doing great either. Yeah.
Douglas Arcuri 33:41 So I think, um, you know, has really inspired me to write and, you know, I crafted a few first blog posts. They weren't really that great. But what I learned through the lessons was that feedback is everything. Feedback is a gift. And he would show me he would help edit, he would help Show me, hey, talk to this audience or Hey, do this or, you know, tightening up over here or he made me think in ways that I wasn't hitting on. And he showed me that, you know, anyone anywhere can come into your life. And as a software engineer, wherever you are, they can teach you things and they can show you the way. And he inspired me to write he inspired me to share broadly. So I've been doing that more frequently with my blog posts and these things. Apart from that, I think the other major lesson learned from Viacom was I was laid off I was let go at at a certain point. So at the time, Viacom CBS was a going through an m&a and merger and acquisition and you know, the strategy on the business change and completely restored. fact that and they changed the mission. So instead of making many different apps for Nickelodeon, they wanted to bring in sort of one, one app, if you will. And that strategy didn't fit with some of the teams I built up. So, you know, I think, you know, working for about 10 years, this was my first sort of lesson as a software engineer, as a manager, if you will, being let go from a job. I mean, I was relatively graceful with it, but at the time, it was a shocking experience, right? I have a family, I already had a daughter, I had another daughter coming on the way and this is all happening at the same time. And I think what I learned there is be grateful understand that you know, business change, and you're going to go into interview hiring loops, right. So I was on the opposite side. Alright, so at one point in time, I was hiring engineers. I'm setting up those hiring loops. Now I'm on the opposite side, as an engineering manager, I'm also going to go through those loops as well. So the one lesson I learned going through that it took some months. But I think what I learned ultimately is that you got to respect the process of the companies, and you need to learn as much as you can. So every single conversation you have, through your interviews, learn from it, you know, reflect upon it. If they asked you a technical question, and you didn't do too well on it, reflect on it, try it out, experiment with it, you'll become better as a software engineer in a lot of ways. You know, reflect on you know, the the questions about your, your experiences, how can I answer those questions better? So it's basically a feedback loop, if you will. And again, there was a lot of strong emotions at that time. You know, when you get laid off there, you go through the five phases, if you will. You know, obviously, you're in disbelief. You're angry. You're sad. And then ultimately you come to the conclusion that it's going to be okay. And you're going to do great at whatever interviews you go through. And, you know, I think it was it was a hard process. I reflected a lot. I wrote a few blog posts during that time when I was unemployed. But ultimately, I think it was some of my best rights as well, because there's a lot of passion, a lot of emotion with it. And I was relatively, you know, successful at getting a job. It took me about three or four months, I landed at a place called dealer track dealer track is a place where we specialize in vehicle transactions, basically a one stop shop for dealerships in the United States. And this is my first experience as a manager coming in not building teams, but taking on your team or teams that already existed. And another big lesson learned as a software engineering And as a software engineer is that you have to take a lot of that initial feedback from you know, your your engineers to heart. And you want to solve a very gnarly problem, right? So as a software engineer, if you should join a new job, definitely you want to take on a really difficult challenge or problem that the team has faced. For some time, of course, you're going to build credibility, but you're also going to learn a lot. You're going to connect a lot of the dots. So at this new job, I took that lesson, and I applied it as best I could as an engineering manager net, right? They were an AWS they were building out terraform they're building out scaled API's for the storefronts we're building for these dealerships. But you know, as a software engineer manager lesson you want to do is jump in immediately and do technical contributions. So I was trying to find ways in which I could solve the gnarly problem for the team, and that that problem was essentially a foosball table. Believe it or not, and how I learned about this was really it was doing the initial one on ones initial conversations with the team and this problem was outstanding for and must have been about a year or two. And the problem was essentially, there was a foosball table that the teams wanted. And we had a few really expert foosball table enthusiasts in our teams. But they didn't have a foosball table close enough. And they wanted one. So I said, All right, let me let me take on this challenges and engineering manager took about two to three months to solve the problem. But what I learned through it was that, you know, it helped build a lot of connections throughout the company, everything from the engineering teams, from procurement from facilities from everything, right, building those relationships and networks, if you will, with people who will eventually help my team as well. And you know how to call up You know, certain companies to find the best foosball table, we bought a competitive quote unquote $3,000 Rose Bowl table. We bought two of them, actually. So I became the picture of foosball tables. But at the end of the day, we got it in. And the teams are very appreciative, and it built a more collaborative environment. And what happened there was I know that people are probably like, rolling their eyeballs in the back of their head, but a lot of great conversations on engineering and a lot of some decisions were made at that time around the foosball tables. And I think it was definitely that gnarly problem that we solved, helped the team out dramatically. So again, lesson as a software engineer, if you're going into a new job, is certainly take that first gnarly problem and take it to heart and run with it as fast as you can to help the team out. So I spent about a year or two with that those teams at dealer track We were building out scaled API's, if you will. In AWS, we also had a legacy system that was standing for quite a while we were making modifications to it. That was basically an API gateway that's been standing for a while. And there was definitely a lot of lessons learned in that role. I was not as hands on or technical, but what I had learned was that shaping rituals, helping show the way, if you will, and starting to reflect on some of the blog posts that I've posted on whether it be TDD whether it be reflecting on kotlin, whether it be team dynamics, I started writing these blog posts, and the engineers, you know, I as an engineer, manager, I'm not going to share that with them, right. Unless they say hey, Doug, I saw you wrote this and then a conversation starts. I found a lot of a lot of you influence a lot of help and support by writing, in communicating through the blog post the team in some way. But what happened, I think the most incredible thing that happened, I think, at dealer truck, apart from launching some products and other things was that as an engineer, manager, you have to find talent, you have to find great engineers. And, you know, at the time, I went to different job fairs, job careers, and I met an engineer and again, at a job fair, you are literally talking to hundreds of engineers and within two to three hours, it's like 32nd clips, and you're trying to find cultural fit. You're trying to find passion, commitment, and opportunity. And I remember one of the things that happened there was that I would kind of do this litmus test of, Hey, tell me about a project you worked on and do you read Hacker News and there was one engineer who went Really like completely deep into that conversation about what he read on Hacker News that day. So Hacker News for those who don't know, it is basically a place of procurements of all these great resources. It's also sought after. It was set up by Paul Graham. So from Y Combinator, and it's definitely a place where there's a lot of debates, a lot of controversy, but also a lot of great updates. So him and I started talking about this long story short, this associate engineer came on board, I had a lot of a lot of good intention with him like he showed a lot of passion, but completely out of university, right, so not having any experience whatsoever and work. Maybe he did one small internship but I took a chance on him, and he grew exponentially. And I was working with him telling him about the engineering disciplines. Again, I'm a big reader, so I spoke to him a lot about the prime program IQ programmer, that's a great book, they just launched a 20th anniversary. It's 100 tips. As a software engineer. If you take these tips to heart, you're going to write awesome software. And him and I, we would do a lot of one on ones, we would go back and forth and try to motivate coach him and show him and give him all the opportunities and kind of reflect on some of the things I learned as a software engineer, about unit testing about the DRI principle principle, which is don't repeat yourself about the AHA principle. Avoid hasty abstractions. And we were talking through all these engineering disciplines, and I would give him all that information and he would apply it and he did great. And then the other thing I also learned too, was that apart from taking chances on folks, is that praise is a really big thing as well. Understanding the small bits recognizing the small bits that that people do every day is a big part of it. Whether it be that person took the extra Time to review that pull request or that person took the extra chance of let me do a quick kt session with you or catching them doing some collaboration, whatever it is, I was doing that and I understood that praise goes a very long way. And it's, you know, it's intentful right? It is, it's coming from the right place. Because ultimately, what I have seen over the course of my career of not only building software and getting those accolades of launching product, and also seeing other people, you know, grow and see them see their full potential. And that's, I think, what inspires me most as a software engineer, and engineer manager at this point is seeing their, their their growth and I left the old track about a month or two ago and now I'm moving along towards IBM. You know, IBM is obviously a great technical company 100 plus years experience And I'll be working in an internal engineering unit called w three digital workspace engineering. And I'll be heading up the blue pages project, which is basically an internal LinkedIn because we have 350,000 folks in the company. And yeah, I'm super excited, super stoked about it. But it all goes back to just, I think a lot of things it comes back to, you know, just going to just being grateful, right? So as a software engineer and software engineer, manager, we work in a great industry, lots of opportunity. And, you know, you need to learn as much as possible, right? So all these stories I've been telling, there's a lot of learnings, a lot of curiosity and a lot of things happen behind the scenes be be curious about things. Right take on that new SDK, take on that new items. Don't be afraid to fail at some of the things because failing ultimately leads to that learning and I'm unbelieving more and more as I go through my career that is definitely the ultimate way and finish things, right. You need to finish things, you know, you're going to start a lot of things, but you also have to see things through and finishing your software engineering projects, launching those projects will give you a lot of satisfaction, but also give you a lot of learnings. But finishing things is really important as well.
Tim Bourguignon 47:30 Awesome. Yeah. This is a very nice story that you have there. Um, if you could leave the listeners with one thing that they should do today. What would that be?
Douglas Arcuri 47:39 Oh, great question. I think, ask for more feedback. I think going back to what I was talking about before, feedback is a gift. Is that be open, be open minded to if you let's say for instance, you're going through a crazy pull request right now. You know, if you're going through that pull request, and there's a lot of comments, be open minded about those comments. I think a lot of ways are coming from a good place and a lot of good intentions. Be curious about it, be open to that feedback, ask for feedback as well, right. I think at first, as a software engineer, something I had learned is that, you know, I was closed for that feedback. I wasn't open minded, in my ways, the right way, if you will. But I ultimately learned that that is not the correct way. And you're not going to go as far as your potential could be. So be open to that feedback and open to what other say.
Tim Bourguignon 48:38 Awesome. Thank you very much, Doug. If the listeners wanted to dig deeper in some of the experiences you mentioned, with you, where would be the appropriate place to contact you?
Douglas Arcuri 48:48 Sure. It would be Twitter. So my handle is Doug Curie. I have two blogs. one eyed dev to my handle is solidity. S o L. idi. My medium account which is also solidity,
Tim Bourguignon 49:03 s o l idi. All the links will be in the show notes, anything on your plate coming up in the next month that you want to plug in,
Douglas Arcuri 49:11 I think just look forward to more blog posts, I'm sure I'm going to be reflecting a bit on probably more of the, the challenges and opportunities. I'm onboarding as another engineer manager. And I'm bringing a lot of those lessons learned that I've, you know, had in the past, you know, five years being an engineering manager,
Tim Bourguignon 49:36 if I could formulate their request, I would be very interested in your take on hiring into a giant company like IBM after 20 years in the industry and startups and smaller companies and evil buddies, and finally, coming up to a behemoth and what you what's your experience on the day to day basis looks like oh, that that thing. I think it would be in
Douglas Arcuri 50:00 Yes, totally, I think that's definitely a big reason why I chose IBM as well is that I've never worked for a large technical company. And I want to get those lessons I want to grow. I want to see how they do it as well. And I think that's a big reason why I'm at IBM now.
Tim Bourguignon 50:18 Looking forward to it. Well, thank you very much. Thanks, Tim. And this has been another episode of devjourney. And we'll see each other next week. Bye bye. This is Tim from a different time and space with a few comments to make. First, get the most of those developers journeys by subscribing to the podcast with the app of your choice, and get the new episodes out to magically right when they air. The podcast is available on all major platforms. Then, visit our website to find the show notes with the old links mentioned by our guests, the advices they gave us, their book references and so on. And while you're there, use the comments to continue the discussion with our guests and with me or reach out on Twitter or LinkedIn. And a big big thanks to the Patreon donors that helps me pay the hosting bills. If you can spare a few coins, please consider a small monthly donation. Every pledge, however small helps. Finally, please do someone you love a favor, tell them about the show today and help them on their journey.