#98 Doug Arcuri is curious & learning, always!
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
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.
Douglas Arcuri 5:08
And yeah, I met a lot of friends made a lot of friends everywhere from Germany around the world. And I had a few modification engineers come join. I had a mapper. I had a matar, I had a person who is good at 3d max making certain models in that. And then I think from there on out, that's basically where it kicked off my, my journey as a software engineer. You know, after that, that mod was launched. I worked on a few other mods at that point, wasteland HL, which was a combination of wasteland and Fallout. And it was again, a modification to deathmatch, and we created all these models against that theme.
And, you know, I learned a lot
I was able to basically package up software and deliver, deliver it to a community. And then the Curiosity just continued to to move forward. I think, when I after, after I went through a lot of that, and I went into university, I was basically working with my professors showing them, hey, here's some things I learned about c++ and showing them how to how to how to do really advanced, you know, using templating and these things in c++ at that point.
Yeah, so after that, you know, I
I went through university, and I got my first job as a software consulting. So I was hired as a software consultant. And again, it was a small business. It was a small family run business. And at the time, I was hired as a software engineer building websites. So things like For our consultants, payroll, we had radiology clients in these things. And I was building basically small CMS systems and an intranet website or websites that we had at that time. Things like using PHP, of course, CS, CSS, HTML, the days before trans compilation, if you will. And at that time we were in I was building and learning more about website design. I picked up a few books at that point, and this is basically when web 2.0 happened. I picked up some books related to I think the book was called bulletproof web design by Dan cedar home, and he talked a lot about how you should use divs not tables, because tables are more about semantic information, structured information and debt Dibs. were more about the structure of the website and you had all a bunch of tips of using unordered lists, order lists and these things and I applied a lot of those learnings and lessons to these internet websites that I was building at that time. Apart from that, it was my my first sort of dive into PHP. So as building basic custom crud applications in these internet websites, so some of these clients had to post certain network information and other material, if you will. So I built a small you know, sort of CMS system, if you will, using PHP, my SQL in doing all those things. And then, you know, I from there, we picked up a few other clients. And I continued to expand upon that custom built CMS system and learn a few lessons there. But I think what was most interesting about that consulting job was that we had, as I said before, a few radiology clients and this was my first experience in building Doing custom sort of physical systems. So one of the systems that we built and I led was a CD DVD duplicator for referring physicians. So, I'm not too sure if the listeners are familiar but if you go into a radiologists office and you get a CT PET scan or whatever it may be, usually the the cases if you will, or the studies are sent over to your referring physician or your primary doctor. And at the time, I didn't know much about how the healthcare data and systems work but I kind of picked it up quickly. We had to build this CD DVD duplicator to to get these these cases over. I learned a bit about die calm, which is a certain format certain data structure, if you will, which packages and formats the data for radiologists He's what was most interesting was that I had to build the system it was physical, right. So, you know the, the patient would come in, they would do the scan, the scan would then be sent over to this, the CD DVD duplicator. And what was really interesting about it was that it was a physical manifestation of the work and I was there many times you know, developing it and proving it. And I had a lot of satisfaction from that because some of the work that I was doing the software building the the windows services at that time and the the HTML front end and doing basically polling, if you will, not only it was soft, but it was hard. So a lot of the when the study would come over on over and the CD DVD duplicator would burn the CD. It was pretty exciting seeing that actually happened and that was a feeling that I always remember of my work had went right into a physical machine and actually seeing it happen, which is amazing. So I think from there, you know, this is during now, probably around the time of the great recession in 2008. The company, you know, we weren't really doing that great. Funds are starting to run out, the clients are starting to pull away. And my boss came to me and he's like, Hey, you know, we need to figure out different ways in which we can monetize. And one of the thoughts were, you know, we saw this thing called the iPhone, iPhone came out in 2007.
And this is 2008. The SDK is just coming out. He's like, Doug, you know, let's, let's start taking a look at this. Is there a way in which we can monetize and we can figure out how we can, you know, forward with some type of project that can make us some money. So long story short, was I picked up the SDK. And at the time, we thought, Hey, why don't we build some small Games. And you know, I didn't know anything about iOS at the time. But, you know, it was something very interesting to me learn the SDK really quick. And then I had to find a way in which I can draw sprites to the screen. And there was, I think, at the at the time, Sprite kit, or it was coming out, but there was a third party SDK called Coco's 2d. And I learned a lot about you know, that SDK and being able to develop some some games on it. So the focus was mostly on children education, believe it or not, our first idea was, hey, let's create an app called eye brush. And let's essentially show children how to brush teeth. And it was a short game built built in cocoa studio built it from start to finish different scenes and the main scene was basically brushing your teeth for two minutes, and it was interaction on the screen as well basically brushing the sprite Or the toothbrush against teeth that were dirty? And you would have to clean those, the teeth, if you will. And I think the thinking was we, I think the president of the company had some relations with Colgate at that time. And this is where that idea kind of came from. We were relatively successful at launching that app. And I learned a lot from just building the application. Unfortunately, it didn't really follow through. But the the learnings was that as an engineer, I learned that I wasn't afraid of new technology. I was curious, I was picking things up. And of course, you know, the, the manager at the time was saying, Hey, we need to get this out the door but at the same time, it was, you know, just going in there, learning about it and building something really cool. So after that, I think one of the things that I move forward with was that you know, the company, we launched a few other iOS apps at the time, mostly related to other games. Small games, like let's say, for instance, tracing through a maze, if you will, we called it amazement. And if you're there small as we were trying to sell for 99 cents, unfortunately, we were unsuccessful. But again, the learnings were, how to actually market the apps, how to build the apps, how to distribute the apps, these things that I kind of took along with me. From there, again, the company didn't do that successful and I moved on. I moved to a larger company called HBO. And at that time, at HBO, they were just launching the iOS app for HBO Go. So this is a streaming media app, if you will. And at the time, time, there were a few consultants who were building this. And I came on board as another senior software engineer, and taking my expertise from my last job bringing it forward. And, you know, the app obviously was very successful. But they had a gap in Android. So while they had iOS expertise, they didn't necessarily have Android engineers. And this is about like, 2011 2012. So the expertise was relatively hard to find. And they said to me, hey, Doug, you know, again, you know, what, you seem pretty, pretty smart. Go ahead, and, you know, take a look at the Android SDK and let's let's try to build HBO Go using that. That technology, so you know, I did I, I think my the way in which I learned a bit was, of course building things, right. So learning by doing is something that I value quite significantly. So being not afraid, being curious taking up that SDK. And at the time, they had another app that was built on Android. So investigating what they had built by a third party.
And we built the
HBO Go
Android app.
And this was sort of my first experience, basically leading a team. So as this thing was starting to be built by my by me, but it was also my engineering director at the time, he wanted me also to start hiring other engineers. So this is the first sort of, you know, hey, you know, let's start setting up some hiring loops in these things. So at the time, I didn't know what I was doing at all, but all I knew was that we needed some time. Some great engineers. So I hired two engineers. And they helped significantly in the not only building the, the phone version of each bill go, but also the tablet version. And they kind of stepped in and helped with that. And what I realized going through that process, as an engineer, and engineer lead, if you want to call me that was that we needed some development processes in place, we needed some rituals. And we, at the time didn't have any code reviews. So we set up some code reviews, we didn't have any test mantra. So we set up a test philosophy of writing unit tests. And it helped significantly improve some of the quality as we were going through some of these projects, past that tablet. In launching that tablet. I had to work with another team and HBO to build out the Chromecast functionality and Chromecast was pretty Interesting at that time, this is about 2012 2013. And what I learned there is building software with other teams. Because the other team was building the VC the I forget what it was called. But basically it was the receiver ends, if you will the JavaScript and UI on the web end that would be used to broadcast on the Chromecast device itself, because it was a client server setup. And we were relatively successful at integrating that. But I guess what I learned through that process was that sometimes even Google is working through bugs they're working through through issues and the SDK was based. It was still beta. At that point, we had a an SME An engineer at Google engineer on site helping us great person. Very, very informative, and he helped us move it through. But you know, kind of taking a step back and thinking through what I learned there was certainly that experience of knowing that even a great company like Google is building things is is is going through through, you know, those those changes and challenges of building that software. But we were we were relatively successful at it. And we were able to launch that app. So I move forward from there. At the time, some things are changing at HBO and I was there for some years. At that point, I figured, hey, let me go ahead and take a look at some other things that are going on in the industry. So I follow that engineer who left that company. And he basically wanted me to come along to help with a project that was web RTC. RTC based. So basically web chat, video chat, that type of thing. And it was my first real startup experience. And it was very long hours. But as an engineer, what I was learning a lot about was that just sort of the grit, the drive the motivation of developing an MVP, minimum viable product for a small company that was competing against WhatsApp at that point in time. And this was about 2014 2015. I learned a lot about Android at that point building custom UI eyes, the WebRTC app that we were building, we had another team building out the SDK portion around the the rich communication services layer. Also the video. So we were consumers of that. But there was a lot of customization in the app, there was a lot of menu driven elements of it. And working, you know, long hours, if you will, and learning to work with other engineers, iOS and kind of figuring out how we can build and launch this app called fuse me at that time.
We were able to launch that product successfully. MVP at Barcelona, so m WC. So we were on the floor there demoing it and these things. Unfortunately, though, after that happened, you know, we kind of ran out of money and the company shifted in a different direction. But again, what I learned there, again, was that you take the learnings as a software engineer, right? So even though the product was unsuccessful, those learnings that you have as an engineer, whether you're building the SDK, whether working with People whether working with, you know, product owners, whatever it may be, you're taking those learnings and you're moving it forward. And what I learned through that process apart from building the app was basically building a CI CD pipeline. So a lot of my specialty in that project was not only building the Android app, because we had had their engineers working on iOS app, the web app and others. I learned a lot about Jenkins, I learned about pipelines and gates, I learned a lot about setting up linters and setting up test runners for the unit tests and integration tests at the time, which we had espresso, I believe, at that point, with hundreds of espresso tests running to check the UI at that point in time. So the lessons learned is something that I captured. So again, even though we were unsuccessful, as a software engineer, one of the things that I treasure most is you take the learnings with you, hmm. So past that, I think, you know, I was in contact with a another software engineer VP at that time again, I'm working in New York City or so this is all based out in New York City. And, you know, you meet people over the course of your career, which is another definitely learning and lesson is that networking is really important and take every opportunity, if you can to learn about what others are building, go to those meetups go to talk to people understand what others are working on. And I met a VP of Engineering at Viacom some years prior. That's probably when I was working at HBO. I think we've been met up at a Google event, if you will. And he he and I were talking at the time while I was going through the startup experience, and he was heading up a larger team
at Viacom and he wanted to bring in
mobile x spurts, if you will, on Android, and iOS for a brand called Nickelodeon. So again, my, my, my, my career trajectory is going from basically, media experience, if you will, from HBO to Viacom. And I think that's, that's a big part of what happened in New York City. For the past 10 to 15 years, we had these companies going through these digital transformations, and they needed software talent, so I would come in there and help. And he hired me as a software engineering director at that point in time. And he had this vision of building all the Nickelodeon streaming media apps on Google Play natively. So this was really my first management job. And first real, okay, we're gonna not only build great product, but we're also gonna build great software engineers. So I was hired, I came in, I worked to build a process. called noggin working with great product owner great Scrum Master great team, great designers, they really knew their stuff, if you will. And I was coming in as a green horn not really knowing much about the brand. So I had to kind of learn on the domain side again. Another big learning too is don't neglect the product domain side, get in there, get an understanding what's happening with what the product is thinking, what are those KPIs? What are those things that we're trying to hit and achieve? And one of the products that I worked on initially was noggin, which is a video streaming media app. And we wanted to launch it on Android. And again, you know, we went through there's some growing pains there took about six months. And at the time, I think what I learned apart from setting up the I think the engineering pipelines and disciplines, if you will, is the hiring pipeline. So I'm definitely going through those those challenges. If I engineering talent, working with recruiters working to understand what type of culture I wanted to set up and definitely engineer focus for sure. But also collaboration was definitely Paramount as well, making sure that we're working very closely with product. And, you know, we set that up. And it was a big part of those hiring loops. And it was a lot It was a lot of stress on me because I didn't know what I was doing. But I was learning as I was going along. And I think what I started to realize is I needed to supplement that learnings, right? So I started to pick up some books about how to build engineering teams. And one of the books that I picked up initially, just generally to build teams was a book called The Five Dysfunctions of a team. And that book is from I think, Patrick Likoni, if I'm not mistaken. And he talks a lot about how to build trust in a team how to build collaboration, and I applied some of those ahead of supplement essentially Again, I was doing my one on ones with my manager. And he was giving me some feedback on these things. But I was basically on my own and learning. And I think, in some ways, maybe the manager wanted that way because they think he probably saw potential in me. So we were, again, successful as a software engineering team. We launched it. And I think the biggest lesson and takeaway, I think, from that project, was that towards the end of the project, there's a point in the project where you, you know whether or not you're going to succeed or not. And what we found out was because our team was distributed, we had an engineer from from Stuttgart, we had an engineer,
West Coast, we had an engineer from Canada, and we were marching along towards MVP, but we started to realize that we may not hit what is viable or what was minimum, right. So we made this decision to bring the team together and it was probably the 30 days working together as a team was probably the most exciting, invigorating. We were really just like working at full steam getting this this noggin out this video application out for bc small kids, they love Nickelodeon. And we were rallying every day we would go we would we would look at the the the JIRA board, we would make sure the pull requests are getting through making sure we have those collaborative reviews. And we were working into the night day in and day out. But we saw the curve, the velocity curve, whatever you want to call it go up. Product Owner was feeling really great. The team was feeling amazing. And we launched we were successful at it. And I think that again, the lesson learned there was bring the team together at the end, you know, bring the team together. And you're going to see some amazing things happen because we all have the same vision of getting this product out there. And it was successful. Lots of people use that, but and believe is still on the Google Play store some years later. And, yeah, that was probably a highlight of my career bringing these engineers together the product owners and designers all in one room, Scrum Master and just just going at it and making sure everyone had each other's backs, and making sure that we all had the same vision of getting it out the door. It was really an amazing moment in my career. Yeah, I think past that. Again, probably like, I don't know, for 10 years in my career was all about iOS and Android. And again, getting back to, you know, mobile, I think, you know, a pass that noggin experience. We had to continue to work through other products and we rebuilt the Nickelodeon app that's on the Google Play Store. We had to build out the Nick Jr. App at that time on Android. And another big lesson that I learned as I was going through it as a software engineering manager was that you need to bring the engineers together on, on vision on the mission, if you will, on where we're going shaping the context, if you will. And I would set up staff meetings, the engineers would get gather around and we would talk about where we're going as a technology. And there was a lot of debates at that time, because we were mostly based in Java, to go over to kotlin. And at the time, Google didn't make an announcement yet that they were, you know, supporting it 100% we were all kind of waiting for that, if you will. But prior to that, it was very difficult to make that decision to go to kotlin because you know, from an engineer's point of view, this is the bee's knees, right? This is the the creme de la creme, this is the syntactic sugar we're all waiting for. It's it's It's concise. It's beautiful, way less boilerplate than Java. But at the same time, as an engineering manager, what I was thinking was, well, where are the experts? How can we hire? What will? How can we create a, a culture in which we can show and learn about kotlin and deliver at the same time? So we were going back and forth on it. And we kind of came to the conclusion that yeah, this is definitely the way we built out a few libraries to kind of experiment and understand, right, so again, experimenting is a really big part software engineering as well. So creating that environment. In the engineers were collaborating, they were, you know, experimenting, if you will, and they brought the lessons forward. We did a lot of kt sessions in the staff engineering meetings. We were holding each other up on it. And we eventually made that transition. It was painful. I think it was painful because there was a lot of disagreement at first. But ultimately, we saw the light, we saw that this is definitely the way and of course, when Google came in, to make that determination that they're going to back at 100%. We were behind it on 2% as well. And, you know, I think, again, from there, we built out a few other apps there. We were relatively successful. But the next lesson learned, I think, is is a very crucial one for me.
And is really learning from others. At the time, when I was hiring for engineers at Viacom, I learned that you can learn a lot by a lot of people, right. And one of the engineers that I hired was a, an engineer, his name is Hazem, and he was probably the first engineer that had challenged me significantly. As a engineering manager, he said, Doug, you know, you know, you have all these great skills and communication, you're you can do a software engineering. Doc, why don't you go ahead and start writing to the community? Why can't you just, you know, just start doing these things. And I was seeing him, you know, go across the world do public speaking and these things, and he really inspired me in some way to get my story across to start sharing my my learnings, my lessons, if you will. And I think, you know, Tim, you and I are having this conversation today, because of him in a lot of ways. And I want to continue this. And this is really my first podcast. So I've, who knows what I'm doing here.
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.