Logo

Software Developers Journey Podcast

#97 Joe Drumgoole's life as a great software developer NPC

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Joe Drumgoole 0:00
You want to start a software company? Do this for me. Go to the ATM, take out all your cards, maxed them all out, like take out all the money you can for most people in our industry, that's going to be probably a couple of thousand dollars, a couple of thousand euros, put it all on the ground and set light to it right. Burn it all up. And if you feel that causes you tremendous pain, under no circumstances should you start a software company.

Tim Bourguignon 0:40
Hello, and welcome to developers journey. This podcast brings 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 Joe Drumgoole. Joe has worked in our industry for over 30 years and even though nowadays takes over director roles currently at MongoDB. He still writes Python code most days. Joe, welcome to devjourney.

Joe Drumgoole 1:09
Hi, Tim. It's great to be here on this beautiful sunny day. Am I yeah, I am not sure software developer. I feel a little ashamed of that title. And I consider myself more of an amateur software developer these days. I do have some public packages. But yeah, my I was always a journeyman software developer. You know, I wasn't gonna write the storage engine for MongoDB, or Wolfram Mathematica. And I was definitely the middle of the bell curve in terms of talent, but I've always enjoyed it. And I love the technology. So that's what's always drawn me to this sector in this industry.

Tim Bourguignon 1:51
And this is what we want to hear today. So this show exists to help listeners understand what your story look like and how they can imagine The future and shape it. So let's get back to your beginnings and where maybe you were more of a software developer than you are today. Where would you place the start of your journey?

Joe Drumgoole 2:10
I suppose it would probably sell. I mean, if you go right back to the start, what got me interested in computers is we had an amazing math teacher in my high school who managed to purloined PDP 11, which not many of your listeners will have heard of, but was the hot mini computer of the day. And we used to play around on it. He taught us basic programming. And that led me to taking a degree in Computer Science at Trinity, which I was terrible at. I mean, I was a terrible student in college, and I had a lot of fun in college, but I failed pretty much all my exams up until the final year when I managed to scrape a reasonable middle of the road to 2am. But I did teach myself and I do as you know, stress is taught myself to program the classes in programming were at best high level introductions to the syntax of the language and the basic principles of Boolean logic. So I actually sat down in the summer of third year when I'd failed by software exams, and said, I'm gonna have to learn this stuff. I'm gonna pass the exams and over the summertime, I taught myself the problem in a really weird programming language. It's probably very few people have heard of they called ADA, which was the hot new programming language emerging in sort of 8283. I went to college in 82 to 86. And I, for some reason, it caught my eye as an interesting language. The syntax seemed very consistent. It was getting a lot of buzz in, in the industry. And so I taught myself the problem is language we learned in college in second year. And as a result of that, although I got a possible degree, they were doing Research in Trinity using the ADA programming language. So I got a job as a research assistant. And I worked there for about six months. And then the company we were working with called generic software offered me a job as a software engineer. And so I moved from research assistant software engineer and I worked in generics for about a year and a half, I'll get the numbers wrong, but it's the LinkedIn numbers are accurate. And and generics was like the craziest software company I've ever worked for before since it was started by a a German guy and an Irish guy. They they had very strong background in software engineering, and they believed in the in the process of software engineering, they really knew nothing about building products. And so we built a ton of amazing software that was absolutely useless as the product. Also when for profit Have offerings in parallel. I mean, you'll know if you've read any kind of startup blog read any kind of startup advice, like pick one good idea and invest in that make that successful. We were building as a CAD CAM system, an ID and an AI system in parallel with a team of about 15 people. I mean, it was utterly bonkers. No source code control. And basically, it was the wild wild west of software. We had an incredible time. I mean, I love that period of creativity. We were just building stuff for ourselves rather than for customers. I remember being at a show and a spree show on an EU show in Brussels. And and, and the one of the people who came to our stand asking us, are you a market driven company or an engineering driven company? And I couldn't even pass that question. I was like, What are you talking about? We're just right

Tim Bourguignon 5:58
off where I was.

Joe Drumgoole 6:00
Halley's Comet I that but it did pique something in me, which is like he could be on something there. I wonder what those people downstairs in the marketing department do now, genetics went from funding crisis to funding crisis like most startups in Ireland and eventually I applied for a job in a big company in the UK Digital Equipment Corporation at the time, although nobody's heard of its day again, it was the second largest computer company in the world, second only to IBM. And so it was like, Okay, I work for that tiny little company. I'll go and learn how to do this job properly in a big software engineering company. So I moved to dec dec was at the peak of its heyday. I mean, it was the second largest company in the world. It was about to launch a mainframe computer to compete with IBM. It was in every segment PCs, mainframes, workstations, and it ruled the roost and it did it With this very funky combination of the Vax processing chip and the VMAs operating system, so you will hear Dec talking about Vax BMS, wholly proprietary, completely insular, built completely internally in Dec by a bunch of very smart people. Dec spawned a generation of engineering talent that went on to form companies all over the world. Windows NT was built by a disgruntled engineer a deck called Dave Cutler, who got pissed off with the direction Dec was taking and went and took all of his toys and went off to IBM. I like Excel as an NPC in the computer industry, right. All these characters asked around me and near me, but I was never actually an actor in their actual gameplay. You know, I was like the man sitting at the back of the tavern watching the real players walk through and Dec absolutely blew itself up. single handedly. It's one of those great examples of a company that destroyed itself from within. And so I joined Dec and they just spun up a thing called the new software group. Yes, that was the actual name internally the new software group. And and and, and David stone, who was the head of the new software group came to me and said, or not me, but to a group of us in the canteen said, we've lost money this year, we could lose money like that for 10 years and still be a successful business. And I was like, Oh, that's funny, that would never happen. Nick did exactly that. It lost that and 10 times as much for the next 10 years. And it lost that money, because it was trying to do the exact same thing as generics had done. All the things all the time everywhere, and there's very few companies in the world can be successful at that. Truth be told, only IBM has really got good at that. And even IBM has dubbed bested itself of whole businesses like its PC business. So I worked in the ultrix engineering group in deck building or helping to build their what they call the digital deck digital software licensing architecture deck was one of the first companies that had built a licensed management facility where you had to get a sheet of paper with a strange hex number and type it in turn on your software. And, and we had ported this to ultrix. And then we would, we were submitting the DEC DD SLA to a thing called the open Software Foundation. Because in those days, there was a big battle going on between deck and a and son, who had the other big company at the time for control of the workstation marketplace son was touting a new workstation and a new operating system called Unix Dec was Promoting backs and vmfs. And they basically had a clash of the titans and Dec lost and Dec continue to lose until it eventually sold its chip fab business to IBM and or and then collapsed into a heap and got sold Compaq who then got sold on to hp. So all the patents we created in the licensing field are all HPL. Now, I my work in Dec was effectively around building initially building software and helping people build software for the new ultrix platform we we've done, but also teaching and one of the things I'd never done before I left college was stood up and talk to a group of people about how to do something. So I arrived in at Dec. And my boss said, learn this new workstation and its operating system and go and teach it to all the German pre sales staff in Munich in two weeks time and I Be on college about a year, never done any public speaking. And I sat down and I was like, I gotta learn this thing. That's okay. And then I got to put together a training course. That's not great. I haven't done that before. But like, I was so dumb, I was like, I can do anything. I was that classic young engineer, nothing is impossible, I can achieve anything just by putting my mind to it. And so I got all the work done. And I got most of the training materials put together, didn't really do a trial run, flew over to Germany, and sat down, started training the class and it went fine. And it was a two day course first day was on the architecture of this workstation, a deck station 2100 as I recall, and the second day was the new compiler. This was the first RISC machine that they shipped. And so the compiler was pretty funky and you could do lots of optimizations with it. And to really understand it required a day of training. So the first day I sit down and I start training, and I get to two o'clock, and it's supposed to be full a course and I'm done, I have literally delivered all of my material. I'm like, Well, what am I gonna do now? So I stood up in front of the class, and mainly German, but some people from further afield Scandinavia. And they said, and good news, everybody, this is the first version of this course. And, and I will be, you know, taking, you know, during the rest of the course, tomorrow, please come in at nine o'clock, you've got a half day and if this was an Irish class, it would have been like, Hey, everybody takes off. But this class was very focused. And a woman at the back stood up and said to me in front of the whole class, I am extremely disappointed in this training course. And it will be reflected in my training review at the end of the course. And I was utterly crushed, right? I was like, Oh my God, my career is over. So I went home that night and I literally cranked out a ton more material. So I absolutely definitely wouldn't run out of material. Sit down in front of the class next day and I This was my first insight into how to run training. And it still works to this very day. piling a ton of exercises, if you want to sell time, and you're not sure if you have enough training material, have five prepared exercises that class go away and do. So that was my learning. And the next day we filled up the full four hours of five hours of training. And everybody went home moderately happy. I still got a scorching review off everybody for the left for the previous day. And you had to fill in training, rare training, feedback forms at a time which is had to bring back to my boss and he was like, This isn't so great job. And I was like now I kind of blew up the first day, but I think I salvaged on the second day. So, you know, my first great learning in doing that kind of engagement is prepare the course with lots of exercises. I also got absolutely blown up by the fact that I arrived at the training center. And instead of having 12, perfectly configured deck workstations, what I had was 12 boxes with 12 monitors and 12 CPUs and 12 blocks. And I had to assemble all of these and I before as well before I started the whole course. So that was like, okay, maybe we'll do some preparation work about the preparation and make sure all the gear is there. The rest of my time in deck was basically me playing at software. I mean, in all the time I worked at deck and this is one of the things that I think may have been its downfall. Nobody ever asked me the question. When will that be ready? So we would basically accumulate tons of hardware in our team. And we would just write software all day fun software, good software, bad software production software. Nobody ever asked, When will that be ready for shipping. And that's because the shipping cycles in debt were basically two years as they were for most computer companies in those days. And by the time you got to ship your software, the world has changed, and you had to patch it, and it went on again. So we had a very happy time in Dec. I met a bunch of people who are not, I don't really meet them much these days, but we formed some very strong bonds, and everything was fine. And then I was about to add, I'd started work on a new project around Kerberos, which is still a thing people use today. But in those days, it was brand new, and we were building Kerberos integration for Macintosh computers and I had started to build this Kerberos integration Stanford University was really interested in doing work with this. And we were working with Stanford, it was a customer of dex at the time and at the time, Stanford had the largest network of Macintosh computers outside of Apple itself. So, I am talking to my boss and he's saying, what about going over there? And I rang up Stanford and they said, Yeah, that'd be great. Come for six months, work in Stanford, learn the Macintosh technology and help us build this stuff. And I was like, Oh my god, I'm going to Stanford for six months. Super excited. This is going to be a game changer. I'm going to be working in Silicon Valley. It's going to be amazing. And then my boss sticks his head over the side of the cube. We lived in cube land and I still to this day, love the idea of working in a cube it always gave me great comfort to have a war completely surrounding me. That was up at NEC eyes. And I that's the what if I was designing my product. office that's what would it be full of and it literally that was you could stand at one end of the r&d floor. And it was cubes for as far as the eye could see over 150 yards. And but and you'd have all these heads popping up and down and my boss stuck his head over the edge of the of the cubicle wall and said emergency meeting for everybody in our division. And nobody ever had an emergency meeting in Dec so I knew some really bad shit was going down. So we get all the engineering team room and and we this is been happening all over deck. But we had thought that core engineering was sacrosanct. And guess what, kids nothing is sacrosanct. Nobody is safe when things are going really bad even in a big company. And, and he says all our funding has been removed. We have three months to find new jobs in Dec are all getting made redundant and we'd watched the lockdown happen. Like First of all, there was no internal traffic. For a second of all, nobody had headcount. So you couldn't even if you found somebody who wants to give you a job, they couldn't offer you a headcount. So we ended up sitting on our asses for three months. And, and a lot of people just decided, let's just wholesale lift as much of this hardware as we can out of the company. Remember, in those days, a block of vac station memory retailed for about $20,000. So a lot of people were going into the machine rooms and just stripping out one Diem out of every machine they could get their hands on. Remember, we had a datacenter that ran for 150 yards long with all of our big computers. And there was none of these were locked up. So eventually, Dec realized what was happening and said, You're all on home leave to lay till your leave goes out, we'll pay you but don't come into the office. I got paid a year salary and redundancy, as everybody did in those days at Dec, which was very pleasant. Did I'd still be in Dec, I should say, it was such a pure, let's just do great engineering. And I was so dumb still, I just thought software engineering was the be all end all. If you did great engineering, things would happen. And and that was king, Olsen's ethic, the founder of Dec, we build great things and that the companies will with the company will succeed, and we'll just sell stuff. Because of course, when Dec started it had no competition. As HP started to ramp up, as sun started ramp up. They started to see that like, they couldn't just build great stuff. They had to market it and to sell it. And they were never any good at that.

Tim Bourguignon 19:38
When did you learn that lesson of switching away from perfect engineering and to actually creating customer value and delighting customers?

Joe Drumgoole 19:46
It happened in Well, I mean, it was starting to, you know, the the, the the moment where you like go something's fundamentally wrong here, right. This there was there was a That was a very significant moment. I'm glad you asked that question. We were sitting in, in in the ultrix engineering team at alteryx was dex versions of Unix. Think of the precursor of Linux. Before Linus went and built Linux, everybody had different versions of Unix, all basically sourced from the original at&t source code. And we decided that instead of continuing to develop our own version of Unix, that we would buy a Unix off one of the other vendors. And at this time, it was a tiny vendor called skull, who had been building Unix for PC style laptops. And somebody said, What's the marketing and business justification for this as somebody written a plan? And the head of our division said, yeah, we realized we weren't very good at doing marketing and business plans. So we didn't do what I was like. That was insane, right? That's like saying I'm not really good at writing software as this is half danger, so just won't write any software. No, we do them to get better. And that was a moment of truth to me were like, this company is truly, truly going to go down in flames. So I was happy to move on. And the next job I went to, I joined a little tiny software house in London, which was down the road from where I lived, and called a silver platter. They they built the precursor of the World Wide Web member. This is early 90s. The World Wide Web doesn't exist. There's no HTTP, there's no HTML. And DNS only came out when I was in college. And so there were all these wacky services like Wide Area Information Service, and SFTP and Archie for like using the fledgling internet to find crap on the internet. And it was a mess, all textual and very hard to find stuff. So, if you wanted to join a library and and look at, like look up reference material, what you did was you bought the things that we sold to replace this old reference library and software on a CD. And you'd have a stack of these CDs. And you could do reference searches on a range of topics with Boolean searches. So the big seller for us was a database called Medline, which I'm sure is being used all over the world today to effectively search for COVID cures and whatever. Medline is the the National Institute of Health's reference of all the medical papers ever published, by topic and abstract and author and with keyword searching, so you could find all papers published between 64 and 72. mentioning the word aspirin with country indications related to heart disease and You get a ton of papers, you print them out, and you bring them to your library and say I need these six papers and he would go off and do an interlibrary and search, find those papers and get copies and send them to you. This is what the World Wide Web was in library times before we had the World Wide Web. And while it was it, silver platter, and the World Wide Web launched, and I remember going and seeing Tim berners Lee at Imperial College explaining how it worked and going, Wow, this stuff is going to change the world. I know that sounds wonderfully prescient. Now what I used to say that about at least every a piece of technology every week, so don't start thinking of me as this incredibly omniscient, omnipresent being, every piece of technology I looked at was going to change the world. So you know, I don't think this is any different. And I just happened to get this one right. You know, if we make 1000 guesses, one of them's gonna be right. So this is not Joe. The CEO of the internet, this is Joe just always predicting something would change. And we built our first web page that published Medline. And I went to our founder and I said, this is all dead. This whole business. This was prescient, and I'll own this one. I said, Our business is dead, this whole thing is going to be replaced by the internet. And you'll be able to get this data for free online. And he made some specious argument about information architecture being so important in the way we organized and structured data. And sure enough, that whole business has gone up in smoke. You can get every piece of Medline information doing an internet search today. And even if you couldn't, Google would have bought it and then kind of capsulated into Google. But I was like, This business is dead. And I started looking for another job. I was like, this is not going anywhere. There's no future to this. And, and I turned up I got a job in Nomura in In the in London in the investment bank in London, and I joined the euro and I had started doing c++ programming in silver platter. And kids don't do c++ programming. That's important advice. Right? Stay away from it. It's a horrible programming language. It'll wrack your brain. Right? It took me two years to recover from c++. You know? And And, interestingly enough, I learned Python before I learned c++, but somehow I missed the essence of Python on my first iteration. Anyway, I ended up in in the in in the Miura building. And at this point, now, I was still coding, but really, I knew I was not going to be the world's greatest coder. I can write software like knockout packages, but one of the things that struck me and still strikes me about the really great programmers is I don't know how they do it. But they don't know how they do it either. You can find a really great program and ask him why he's 10 times more productive than me. He doesn't know. He and because he doesn't know he can't teach it. This is why teaching programming at some level is kind of a waste of time. I truly believe programmers are great programmers, that is the guys who absolutely fundamentally we write transformational software, the people in MongoDB, who write the wired Tiger database engine, who've been writing database engines for 30 years. I look at their code I go I'm not worthy, right. And Stephen Wolfram who built Wolfram Mathematica in his summer like I it takes me all year to write a Python package. Never mind, a complete mathematical analysis tool. So at some level icon, nobody can teach you to be Stephen Wolfram. That's, that's something In a in your makeup, whether it's genetics or background or whatever, I don't know, I'm not skilled in that area. But I think the real challenge is to discover great programmers. And so it's not a teaching exercise. It's a search exercise. And I think the biggest challenge for anybody hiring great programmers, is people say, Oh, well, we'll make our own. Yeah, you'll make tons of journeymen programmers like me. And we get stamped out all the time by colleges and by industry and trust me, you do not need to go to college to learn to program. I did not nothing I learned to program. I learned in college. What I learned in college was how to search for information, and also how to teach myself but you can teach yourself to teach yourself, especially with the excellent online resources you have today. So the most important thing I think I can say about colleges, go if you can afford it, but don't feel you can't have a career. in this industry without it, we do have a terrible conceit, about looking for, you know, at third level education. in our, in our search me, if you've got the chops, and you've you've shown me you can build software, there's a career for you in any company I work for. And the biggest challenge is experience. And of course, you know, experience needs experience. And that's a circular argument. We do run a very, very large intern program in MongoDB, as do many companies, and internships are a great way to get that preliminary experience. We hire a ton of people each year from our intern program. And so that's definitely an option for people. We pay our interns, some people don't, you got to make some choices there. But you don't need to go and do a college degree to learn to program. So I joined I joined them euro and I kind of aspired to like icon I really expect to be a programmer all my life because I it's not a it's not satisfying, especially in the mirror, when I was working with probably some of the smartest people I've worked with today. And it was clear that like I was never going to reach their level. And I was working on this system called a me Application Management environment. Think of it like, like a mixture of puppet for Process Management, a database for centralization, and a little bit of chef and a centralized logging system. The idea was, this would manage all of the internal systems inside Nomura. And they were running a huge project to transform their internal systems from a mainframe system to a network of sun workstations. Sun was really kicking ass in the 90s. And, and so we were building it all in c++ and this speaks to the fashion essence of the industry and why we should not pay attention to the language choices of this generation for what will come in the next generation. I sat down to interview with one of the architects at Nomura. And he explained what they were trying to do in c++. And they wanted this highly dynamic system where code could be loaded into live systems, and they could dynamically update systems on the fly. And I was like, well, I there's a system that already does this. And I know it's being used in investment banking, because a friend of mine was building these systems in a in JP Morgan. And when I say friend of mine, that friend eventually became my wife. And at the time, she was, you know, my friend, and she was building a system in JP Morgan to do exotic exotic derivative pricing using small talk. And so I said to this guy, you could do this all in small talk. It has all that dynamic stuff, and he was like, we can't use small talk. It's too slow. And I was like, well, fair enough, c++ is faster. I'll grant you that it's a pig. And trust me that I loved working in the mirror. I hated c++ and I hate that language with a vengeance. It's just a terrible programming language, a terrible time Eric monster of C m. And when I was learning ADA, everybody would say ADA, the production rules are too big c++ is much simpler. The the ADA reference manual is still readable, the c++ reference manual, literally you could kill somebody if you dropped on their head. And so yeah, I've got a big thing about c++ and C, good, honest language. Everybody should program in C and learn it c++ no good. And we build a massive system in in in the Miura called ama. And when I say we build it two or three genius guys and built the initial system One of them is still working today in Atlassian. In a in Sydney, a guy called Matt Watson truly genius programmer. Matt, you're just still one of the iconic figures of my programming life for what you achieved with ama. And we built this massive system it worked. We rolled it out, I had to cancel a holiday because they brought forward the Crick crest roll out in the straightening offices in London. So we had to advance the rollout. And Amy worked right and ama worked for a couple of reasons. One, it was incredibly ambitious system which was used for a tiny thing. Like basically 90% of the utility of Amy was never turned on. And and in fact, there's a ton of stuff in there that still isn't turned on. It's being used by the way. This is the the testament to a great piece of software. Am is still being used in the mural today to run its middle office systems start and stop the process. is log all the errors, keep track of what's running and what isn't and do hierarchical starts and stop. So if I need Sybase then it starts Sybase before it starts my middle office software. And but the the, the thing about me and was it was transformational in that area. And when we turned it on, it just worked one because there was great software engineers building it, and they really knew what they were doing. But to that, and this is my one claim to fame and am I prepared to roll out this system, and I did something that they never did in any other piece of software in and in the mirror while I was there, I built a proper installer, like an installer that worked with the installation system on the sun workstations. So you could run an audit and see what version of me was running on every system. You could stop and start a me remotely in any system and you could easily store a me remotely in any system. And that was probably my major contribution to the AMA system. And it's honestly installers are not hard. This one wasn't hard. It took me a while because everything takes me a while because I'm only a journeyman. But that's the reason AMD was successful, because they could turn it on and off, they could manage it remotely. And when they had problems, we could roll out new releases automatically. And because everything else depended on it, it was critical that worked. And that got me a whopping bonus in my first year in the mirror, which I then took along with my then girlfriend, Anne, who had been in JPMorgan, she moved back to London, and we took off around the world and basically spent that money on around the world trip. And yet, never mind the advice on being a software engineer. Everybody should go around the world at least once in their life. It's super cool. You will give you a different perspective on the world and you'll come back with a different view. What you should do in life. And so when we came back we moved back to Ireland. And I joined a small software house called CR two and which is still running to this day car to calm. And we built one of the world's first internet banking systems. I was running teams now. So I ran the team. I did not write the code for this. And, and and one of the things that I learned in this team was just how to manage people because I was terrible at it, right? I was hectoring. I used to shout at people. I was a bully. It was a nightmare. And I god bless that team. They were incredibly patient with me. And we managed to ship that piece of software. And what I learned in in in CR two is how to nurture a young development team and and what you need and I did not have it till the very end is incredible patience. People take Time to learn new things and people take time to, to learn to change when things change. And in a startup, things are changing all the time. And one of the things that I learned in CRM is one incredible patience with your staff. You know, they're working as hard as they can. I've never worked with a team where I've had somebody who's lazy just won't do their job well, once or twice, but we, you know, we manage those people out. And almost all of the software engineering teams I've worked with have been committed, want to do well want to do a good job, want to be able to succeed and want if they really understand what they want, they want their software to be used. And so the first thing that I that I loved about co2 was we were building us a piece of software that was trying to change the world of banking, doing internet banking was the future. Unfortunately, in 1999, which is the year I moved back to Ireland, nobody had the Internet. The Internet was being talked about. And there was tons of websites, but nobody actually had the internet. And so of course, when you're building stuff for a market that doesn't exist, it's a huge challenge show. So co2 suffered its own little internet boom and bust where we built a ton of really funky internet software bank world, in 1999 was the first system that had what was later to be called Ajax built by another fantastic engineer Bethany Murdock who's still kicking his heels around the Dublin software scene. He built dynamically updatable pages using at the time and Java applets, where we could have a continuous history of all of your banking transactions. Anybody who used internet banking in the 90s will know and, and and well, rather in the naughties, we'll know how crappy internet banking was and how you could only go back couple of months Well, we had an infinitely scrolling bank history. So you go back as far as the bank history would allow you to. And, but nobody wanted it. Nobody wanted that technology. The people that did want it typically wanted it for. Let's just say, they weren't the most honest banks in the world won't name them. But one of them that we sold it to said, yeah, we need sub accounts and sub accounts were like, you can hold two denominations in the same account. And let's just say one of the sub accounts was dollars and the other sub account was roubles, you know, and, and and also they said, and turn off all the audit features. And I was like, Okay, I'm gonna go with this is not the most honest day's work we've done but customers are customers and see our two. Again, another moment or like Tiny moment of prescients I was like, SAS is the future Salesforce had just launched. And I said, rather than building installable banking software, why don't we build SAS banking software? And my bosses said, You're crazy Joe. And they were right, because it was too early for anything. Never mind SAS. My probably my biggest failing in life is is when I think of an idea that's literally 10 years too soon for its execution. So I left CR two because they were the the internet banking business wasn't there. It was there five, six years later, but at the time, it's very hard to do internet banking when nobody has internet. I mean, this was the beep beep boop days of the internet when you had a voice box modem and you dialed in and, you know, it made all these weird clicking sounds and it reached the point where you could tell from the sounds in your modem whether it made a connection or not before the screen told you You'd made a connection. And I moved to a company called Kapler software. I got head hunted to run the engineering there. And cape clear, built the world's one of the world's first Web Services stacks. So Web Services roll a rage in sort of early noughties and basically building around and building, you know, XML based query interfaces using HTTP API's, but wrapping them in an RPC model. Web services were a bag of shoddy I mean it just terrible. And well, they were, they were not the thing they did set the stage for rest and Jason, which eventually became the default for how we interact with things on the internet. So we built this stack of software, and I was the first version of Cape Cod. year was called cape Connect. And and this was another moment of truth when I was realized that sales and marketing is so critical to being successful as a software business. We had a company, a product managers and engineers. And we built this piece of software. And we gave it to tandem to demo and tandem with demo it. And then they would sell a tandem system. And I remember going to the CEO at the time and saying, Go and ask them for a million dollars for the demonstrator. And they'll give you 100 grand, and it will be an amazing deal for us because we haven't sold a penny of software so far. And he was like, No, no, we'll get loads of press out of it, blah, blah, blah. They did one press release, we got no press out of it. And we ended up supporting probably $10 million of software. So our software and hardware sells for time no matter which we generated no revenue. And like, ask for the money. Ask for the money. It's like this fundamental skill, we teach. People in sales, you gotta ask for the money at some point. And so I realized I can't. I was getting frustrated I could build great software not me but I could run great teams cape Connect was amazing. And the cape clear business was sold to work day a couple of years later and ultimately became the integration and engineering on workday and workday now still have a double office with some of the people that work with me and work they still working there. I don't know it's a couple hundred people now. And, and Andre, who was the CEO of a have workdays just started a new startup with a couple of my peers called outmost. So, you know, these companies, even though they're not successful can generate a huge amount of creativity for the rest of the industry. And I nk, clear I learned how to ship a product to customers in a coherent way. In a largest team, the team I've had at co2 was like four or five people. I had about 10 engineers in Korea. And I kind of knew how to run the engineering team at that point. And for me, that the key thing to an engineering team is mostly to get out of their way. A lot of people want to put a lot of structure and a lot of processes in a lot of detail. We we had a basic Scrum model. And we did a lot of unit testing. But the thing that really helped us to get cape Connect, working and rocking and rolling was an ethos of everybody works, and everybody works to build the whole product. You're not working on a piece, you're working to deliver the whole product. And so we tested the whole product every week. And we did a show and tell every week, I had a number of leaders within the teams who led the individual components. And we we built an installer and I continue to say This To this day, doesn't matter what you're building. If you're building a SaaS product, if you're building a product, build an installer, yes, unzipping a pile of stuff is very easy. Building an installer helps you to understand what's going on. And we all have puppet scripts and whatever. And installer helps right installer helps you to understand what's going on, particularly remotely, what version of the software is running. And so we built a full installer for this software where most of our competitors were saying, download this tar Gz and unzip it and it'll all just work. Whereas the installer would do some preflight checks and make sure that everything runs through our software went out, and was really easy to install. It was also and I still have the boxes in my attic in there. Plastic, was the first company I'd actually built shrink wrap software, we call it shrink wrap software now. It's effectively a universal term for software that you deliver over the internet, but this was actually manuals and a CD in a box blade. packed and shrink wrapped. And it's a beautiful thing. I will dig it out of the attic. If I can, we'll get some photos. Because it's like when these arrived was like we knew we were a real software company. We had shrink wrap software that you could put on someone's shelf. And so I mean, I loved working at Cape clear, great team, great ethos fantastic company. Just a wonderful organization. And I made a terrible mistake. Oh my god. Terrible, terrible mistakes of my career of thinking that when you've seen a software company, close hand, you know enough to know how to run a software company. So I decided with a friend of mine that we would start our own software company as founders. Oh, let me let me I have an exercise and I do this I it's a thought exercise. If you want to Start a software company do this for me. Go to the ATM, take out all your cards, Max them all out like take out all the money you can for most people in our industry, that's going to be probably a couple of thousand dollars, couple of thousand euros, put it all on the ground and set light to it right? Burn it all up and and if you feel it causes you tremendous pain under no circumstances should you start a software company because you are going to burn 50 $100,000 in salary sacrifice in pain in whoa in grief. Just and remember at this stage I think I was 35 years old or 36. I was earning reasonable coin as a as a as a head of development. When you go to start a software company, all your benefits go to zero your healthcare, your pension, your salary goes to zero for sure. Sure, and I didn't find what found one software company founded three. It's like God Almighty, you have a serious addiction, Joe, you know, you need help. So we founded this company locator, again, a business that was 10 years ahead of its time, online billing, and SAS billing for online installed software. This is something that MongoDB does stay, although we don't have any licensing around it. But it would have been a perfect company for this way ahead of its time. Nobody wanted it. Nobody even understood what it was. If you're explaining what you're doing to your customers, you're losing. And, and so we we struggled along for a couple of years, and eventually, I decided I had enough of this startup, it wasn't working, and I was panelists and I needed to earn some money. So I got a contracting job in Bank of Ireland in in Dublin. I did that for a couple years and that was working for banking software. People it's just

Tim Bourguignon 48:01
not good. You can really yeah,

Joe Drumgoole 48:03
banking. bank bank, Nomura did an amazing job. But even they probably shouldn't have built the software they built. They should have bought a lot of that stuff. But definitely Bank of Ireland should be buying their own software not trying to build it.

Tim Bourguignon 48:18
We haven't come to MongoDB yet. And I would like to to to talk a little bit about it.

Joe Drumgoole 48:22
Yeah, sure. So I did three startups. They were terrible. Don't do startups. They're bad, right? I mean, do I mean startups are amazing. I learned more in startups than I ever learned. But they are just, yeah, it's it's expensive, and especially if you fail, and I'll, I'll sneak in at the end. My secret for getting rich for a mind beating but there is a there is a plan I'm currently executing, and so far it's working. So I worked for a bunch of stuff. I found a bunch of starts work for a bunch of things. It wasn't working For a not financially and not, you know, mentally I needed a break and I decided I would look for a company, a great company with a great product. That was number one and its market it had to be number one I wasn't going to be playing the old so ran I wasn't gonna be I done some time at Oracle was good being number one I'd worked at Oracle for a couple years in the ensuing time period. Wonderful. Number one is easy. You don't have to introduce yourself for a start. And so a friend of mine who had left the company I was working for join MongoDB and Jim called me and said, this is a great company. They're looking for a technical director you should apply and I applied. First thing that struck me was within about an hour of my CV landing. This amazing recruiter from MongoDB had rung me up and said we should talk. I then went on a whirlwind stop of 10 interviews 12 interviews crazy number of things. interviews and and landed a job in MongoDB, including an interview with the CEO, which I thought was a walk in the park tiller discovered after I'd done the interview, that he'd rejected the previous five candidates. So I run a bunch of things in MongoDB. And I ran pre sales initially in Europe. Then I moved into Developer Relations. I'm now running developer advocacy in and developer relations content within the Developer Relations team. MongoDB is the example of my my new algorithm for getting rich and getting rich is fine. But I think there's two things you want to do in your life. You want to change the world, I've always wanted to have an impact on the world around me. And obviously to do that. It's a lot easier to change the world if you've got, you know, financial success. So here's my model. Right. Join a great company. And by the way, finding great companies is hard, right? I think I was a little bit lucky with MongoDB. But they had the initial conditions for success. They were number one in the market. They had amazing technology. And everybody who joined it told me what an incredible company this was. And and it was, and it is, I mean, this is the longest job I've ever had in my career, six and a half years. And I wouldn't be here that long if this company wasn't doing incredible things, and working with an incredible bunch of people. But here's the kind of magic algorithm for success that I've been telling people in the last couple years. Find a great company. That's high growth. Right? And it has to be high growth. I mean, IBM is a great company, but it's ginormous work navigating greater IBM is a whole different challenge. And so it's it's got to be relatively small but high growth you know, hyper growth as a as they say in the startup land and You've got to bring integrity, intelligence and the willingness to hard work to this algorithm. Like, if you don't have that it's game over. And if you don't have that you're never going to be successful anywhere. Assuming you can bring those find a company's high growth. That's number one, maybe number two, but really, number one, and it's part of the segment, join that company, and stay there for 10 years. Right. And that's hard. Because this is a seductive industry, we get offers all the time of different jobs, staying in one company for 10 years. And also, in any company, there will be what I like to call a challenge. And if you stay there for 10 years that we more than one challenge, there'll be a period of your life in that company, where things are going terribly badly for you personally. And the temptation is, I'm going to bail, right I'm going to get out I'm going to get away from this bad experiences bad situation and go and do something else. And I've been doing that all my life, but I had a tough time in MongoDB. I'll admit it, and I knuckle down and and got through that. And as a result, you know, I consider myself to be moderately successful within MongoDB. But personally, it's been very successful for me. I've seen the company go public, which has been an enriching experience for anybody who is in MongoDB. Pre IPO. The stock price is in a reasonably healthy situation. But more importantly, organizationally, and structurally, this is a company that's set up for success and it always has been and that enabled me to do my job really well. And to see the impact of my success and being able to watch what you do have an impact on the overall success of the company is a critical thing that gives me job satisfaction. And that for me is is is like if you if you don't hear anything else, finding a great company and working there for 10 years is a great way to one enrich your life to do something really meaningful entry. If it's a great company, you should get reasonably stable financially in

Tim Bourguignon 54:06
that period, I would like to send you a less curveball. I love the analogy of the NPC games don't work without the NPC. So dues are really important. But how do you become a great NPC?

Joe Drumgoole 54:19
I think. So. The things I've learned is, you know, and I'm bad at these things and and I struggled to get better than one is at discipline, getting a structure to what you do. So you're doing it regularly, every day, every week, every month, every year, whatever that cadence is, you know, check your pension every year. do exercise every day. For me, I still love to program even though I'm crap at it. So I try every day for at least an hour to sit down and play with some code if you want to be a great software engineer. You're going to times 10 that right? And you've got to invest. People want to learn all the things because there's so much scope in what we do today. If you want to be a great MPC, you've got to learn to really work that sword and shield right and so find an area you love and get good at that area where we're always looking for experts. And what I'm looking for when I look for a great engineer is the ability to learn something in depth. I'm, I'm sick of seeing CVS where it's like got 25 technologies, and you ask them two questions on a technology even you only have a superficial knowledge of and it's clear they are you know more about that technology than they do. And I can be that guy because I'm 56 years old, I've had a long time to learn this. If you're, you know, 35 I've got a head start on you by 20 years or more. So and if you say You've got 25 lists of technology. I'd much rather see somebody come in and go, I don't know every programming language but I really know go or I really got into rust or I've really invested in blockchain. I've built some blockchain software. I mean, everybody says they know blockchain. And when you ask them the basic algorithms, they haven't a clue. You know, proof of work seems like a magical term for a lot of people who think they know blockchain. So getting in depth knowledge of what you're an expert in. And that's not because I want you to be expert in anything. Like we say, Come join MongoDB you're not expected no longer to be will teach you that. But can you learn it is the real question, can you learn it fast and in depth? And so come to me with examples of skills you have acquired, preferably on your own, but also in concert with other people or the trainings and show that you know them in depth. If I can see that skill. You've got a job In any company I work for.

Tim Bourguignon 57:01
Amen. That's a great advice. Thank you very much. Thanks, Tim. So, if listeners wanted to continue this discussion with you, where should they hit you?

Joe Drumgoole 57:11
I'll hit me up on Twitter at j drum, Google, that's JDRUMGW ll e am always willing to chat to people on Twitter. And you can email me if you want to learn about MongoDB at Joe drum, Google at MongoDB. And I usually try and answer all my emails. And, and I have a blog site, but I haven't updated it in a million years, Twitter is the best place.

Tim Bourguignon 57:39
You probably don't have any conference talks running right now with COVID. And so but I think you want to plug in.

Joe Drumgoole 57:45
And I think if you wanted to, if you want to learn about what we do in MongoDB, go to developer MongoDB.com. It's our new developer oriented website and join if you're interested in in MongoDB. Come and join our community at community.MongoDB.COM. And that's where you'll get the best information about what's happening with MongoDB what we're doing with our product, and it's run by people who work in developer relations with me. So I, you know, I'm pretty sure they are going to do a good job for you.

Tim Bourguignon 58:17
Hey, man, thank you, and the links will be in the show notes down under. Thank you very much. It's been a blast. And this has been another episode of developers journey. 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.