Reverse Interview - Michael Gallipo

February 21, 2019

Michael Gallipo turns the tables on Joshua and Kellen in our first of a series of reverse interviews, where we ask newer developers from #100DaysOfCode to ask us any questions they like!

• 00:02 Joshua

  Welcome to Getting Apps Done, a mostly non technical podcast with the goal of helping you deliver software. Because if you didn't ship it, it didn't happen.

• 00:16 Joshua

  Alright, well I'll start by introducing us. I'm Joshua and this is Kellen. He's my cohost. Um, we've both been in tech for quite a while. We've been developing software each for over 20 years and actually we were inspired by moms can code and the hundred days of code and we wanted to do something to help new developers in a way that was going to be actually beneficial to them. And neither of us had been new developers for quite a while. So we wanted to, I actually, I thought it would kind of be a neat idea because usually when you have people on a podcast, it's to interview them. I thought it'd be kind of neat to reverse the roles a little bit, bring people on this podcast to interview us to so that you can actually ask questions that are relevant to you, not just what we think is relevant to you, if that makes sense.

• 01:04 Michael

  That sounds great.

• 01:06 Kellen

  Alright.

• 01:08 Joshua

  Um, so you said you had a, in fact, actually, why don't we start with who you are and what you do. We did do a little bit of a for perusing on Twitter and linkedin prior to this and from what I saw it looked like you were in banking before you decided to do software development. Is that true?

• 01:26 Michael

  Yes. I spent some... Uh, most of my career in finance and investing, um, split roughly 50/50, between the mutual fund world and an analyst and portfolio manager. Uh, and then as bank high net worth portfolio management.

• 01:42 Joshua

  Okay. That's quite a shift from that to software development. Then what caused you to start to look at software development? Is that a recent thing or has that been kind of on the backburner for a long time for you?

• 01:54 Michael

  I would say in a sense both. Um, I took some time off recently to spend some extra time with my kids while I, while I still have the opportunity and that gave me the chance to sort of ask the usual question what do you want to be when you grow up?

• 02:07 Joshua

  And My, my experience with tech actually goes... I took my first programming class back in junior high school programming BASIC on a TRS 80.

• 02:16 Kellen

  Oh, that sounds familiar.

• 02:19 Michael

  And you know, my career has, has touched on technology. I actually ran a telecommunications fund during the original Nasdaq bubble. Interesting.

• 02:28 Kellen

  Exciting?

• 02:29 Michael

  Yeah, very exciting. Uh, learned a lot of great lessons and then obviously, you know, paid attention to technology for years through my investing work. But you know, I joked for a long time that if I had college to do all over again, I'd be a computer science major and I said, having taken this time off. I finally decided, you know, why not do it. Minus going back and spending four years doing it.

• 02:51 Joshua

  Yes. And that's actually something that has changed quite a bit over the years is you don't have to go get a four year degree to get involved. There are so many different bootcamps and other ways to get into development now that it, it's a very different environment than it used to be.

• 03:06 Michael

  Absolutely. And that's the route that I took. Uh, I signed up with Actualize which is a firm out of Chicago and did it as an online course, but it was online via a Zoom classroom. Um, so it was video classroom. So it really, to me, combined the best of both worlds. It was online and I could do it from my living room, but it felt like being in a classroom. But for me personally, that was perfect because I didn't, you know, the traditional after work time, the stuff that I still did in my life, whether it was my nonprofit involvement, my kid's sporting events, all of that stuff happened in the traditional after work east coast envelopes. So that the 9, 4-9 window here was awful for me.

• 03:48 Joshua

  Yeah.

• 03:49 Michael

  Um, so being able to do it and I think I'm half vampire anyway, so doing it late at night was great.

• 03:55 Kellen

  That's really cool.

• 03:57 Michael

  So, um, alright, well I will, I will kick this off. Um, and you alluded to it earlier, I think there are more and more people entering technology now as what I'll call nontraditional, unconventional backgrounds like myself. Um, so when you guys are looking to assemble a team or something, what non-coding trait or skill are you most interested in? Then I realize that may depend a little bit on, on the role, but would it be the communication would be having met a sales goal? Uh, speaking in terms of a lot of us trying to pitch our own backgrounds to a prospective employer,

• 04:35 Kellen

  so that's actually, so it's kind of an interesting thing when, when for me, for example, when I'm looking to fill roles on the team, I'm usually looking at my own team's weaknesses and trying to find folks that can kind of prop those things up. So if I have a team that's really heavy, heavy in like cs majors, that that was their thing. They're, they're deep and algorithms, but they, you know, they haven't talked to anybody outside of their house and a couple of months, uh, then obviously I'm gonna be looking for people that are better at communicating. Um, or maybe I'm looking for a project, you know, somebody who's can, can handle the project management or the, the, the general timing side of things. But I, I do, I tend to look towards the weaknesses rather than any specific skills. When building a team I want, I want them to be complimentary, but who's generally my goal.

• 05:19 Kellen

  And so just kind of as a recommendation on people that are, are trying to come into these roles, I would recommend just being... Kind of showing what you're best at a, it was kind of, uh, the, the easiest way to go about that is, you know, kind of a very genuine show your strengths, whatever those strengths are and try to fit those to whatever the role is. Um, I know obviously that's a bit of a challenge. In some cases some folks are looking for cookie cutter developers and that it's kind of difficult to fit into those things. But the best roles will be the ones that can, that can definitely adapt to you, to your own strengths.

• 05:53 Joshua

  Yup. They're going to be more rewarding for you and for the team in general if you fit in nicely. And in general, a lot of those things are not necessarily development skills because uh, particularly when you're looking at junior developers or early stage developers, a lot of them have come out of the same sort of boot camps and things like that. So they have very similar experience and development. But the things that will really make a junior developer stand out for me are going to be the extra things. If they did some time as a project manager before that, or if they happen to also be a design major, because quite often development and design come very close in hand. Those are things that I'll be looking at and I'll be recognizing those things as well. So don't just show up your development chops, but also look at the other things that you've done, particularly if this is a second career. For you, the banking is actually a huge benefit to you, particularly in sectors that can benefit from very similar things because you have inside knowledge of those businesses and that actually makes you better at talking to customers.

• 06:55 Kellen

  Yeah, if you're the, and just to kind of answer to the question a little bit more directly. If you're looking for just like the general all purpose skill that we wish every developer had, it would probably be like time management, project management, communication, basic skills, those sorts of things. I did want to mention, you know, the, the more specific answer is probably that, but really, uh, compared to like your, your investment experience, that's way more valuable than a project. Another project management skills like the, the uniqueness, uniqueness of, of folks is usually far more valuable than whatever the next most valuable basic skill is.

• 07:32 Michael

  Right. That makes a lot of sense. Um, another question, um, is evaluating... As a new developer, obviously time is a precious commodity and there's a gazillion things to learn and only so much time to do it, um, so I'm curious how you guys would evaluate the value of learning more of a legacy technology versus the shiny new thing. And what prompted this to some discussions I've had, um, at a couple of meet ups and networking event and it wound up in expression of Java versus Python on the back end and I sort of been leaning Java and every single person I've talked to, oh no, no, learn Python, learn Python. I can tell you as a job seeker the jobs that require or are looking for Java versus it's a 10 to one or more ratio in... Which makes sense cause that's the legacy install base. So I'm curious how you guys would evaluate that for you because I feel like that question was being answered by that person for them in their current position.

• 08:36 Joshua

  Yeah. And it also will depend on the sort of roles you're looking at. Uh, particularly if you're looking at startups, they quite often do go for the new hip and trendy.... Python or React or whatever it may be that's new and big for them. Whereas if you're looking for a traditional nine to five role in a corporation, it probably is going to be something more like Java. Like we were discussing this the other day that I probably have more projects come up that are AngularJS 1.5 1.7 then anything new, uh, even Angular 2 through 7 now is much less common than AngularJS because that's what's already in these businesses. So there's so many jobs out there for those even now. Whereas the new stuff, a couple of them will probably survive, but it's hard to tell which one. So you're taking a bit of a gamble where the older stuff, it's pretty guaranteed.

• 09:30 Joshua

  It's all over the place. There's going to be work for a long time, as long as it's not so old. I, I probably wouldn't recommend learning Cobol now, but certainly Java. Java is definitely still very strong and particularly in enterprises, but even outside of enterprises in any small to medium size company is going to be very common to find Java out there.

• 09:51 Kellen

  You'll see a lot of the, a lot of this discussion to also, uh, will differ depending on the person's motivations. Uh, so if someone's really into programming, like that's, that's kind of their art, that's the thing they love to do. They're going to, they're going to gravitate towards more interesting languages. Things that have more interesting problem sets. And I'll, you know, new is always interesting. There's always something kind of new on the horizon.

• 10:14 Joshua

  The other thing to keep in mind is while you're picking one at the beginning, because you really do need to focus on one that's not the end of the game. You're going to learn more languages as you go through your career. And if you get through Java, find that first job, then you may find, actually I'd like to go pick up some Python now and it's going to be easier once you've learned one, because a lot of the concepts are shared across various programming languages because concepts in general with programming are much more important than the syntax.

• 10:40 Kellen

  And just to kind of a comment on growing. My first programming language was BASIC as in BASIC basic, GOTO spaghetti language BASIC. So that's definitely not what I'm programming in nowadays. You got to grow with the industry unfortunately. And it's kind of like a language. It's, it's like a spoken language is just kind of evolves a whole lot more quickly.

• 11:03 Michael

  Yup. No that makes a lot of sense. Um, and I guess sort of in a similar vein, obviously cloud technologies and all of the stuff that goes around with that is, is super hot in technology now. Is there any aspect of that that you would highlight as a priority for new developers and how do you guys look at it? That sort of, and I'll be honest, I don't fully know, is there enough commonality for it? You know? Okay. So maybe you've done some work with AWS and a prospective job is using Google or IBM cloud, but is there enough commonality that you'll say, okay, yeah, he's learned one, he can learn the other pretty quickly.

• 11:45 Joshua

  I think there is a lot of commonality. The key thing I would say there is learning the basics of infrastructure in general. Uh, in fact, for a portion of my career I was building infrastructures for corporations and that knowledge has actually been much more important than learning specifically about AWS or Azure or any of these others. Because once you understand how servers work, how the networks work and how those pieces fit together, that actually gives you a better baseline to work with on any of them. I think that's a lot more important than just picking one and learning that one specific one.

• 12:21 Kellen

  Yeah. And infrastructure is, in the past has been pretty cyclical on what, where things reside and like, you know, at some point everything was locally on your PC and then it kind of went back to the cloud and you know, we had mainframes that were very cloud like... Though obviously simpler. Um, and just the, just like the languages and the frameworks, the infrastructure that we run on changes pretty dramatically over time. I mean serverless is kind of the, the current buzzword I think, unless something new has come up when I wasn't paying attention. Um, and that, that's...

• 12:53 Joshua

  I think we're still on that one...

• 12:53 Kellen

  Yeah. It's like that's a different infrastructure then saying spinning up multiple virtual machines and AWS to, to run a cloud. So it's, it, it's a bit of a moving target. Um, but, and then knowing like one and understanding the concepts behind hosting your own, your own apps in your own sites, at least at the basic level kind of gets you in the starting point. A lot of this stuff you have to learn Kinda as you go. Like Netflix level scalability is something that's really difficult to teach and teach without being able to experience it and experiencing that requires a huge amount of site and data. So it's like there's not really a good place where you can practice that sort of thing outside of someplace that's scaling like Netflix or Spotify or you know, anybody with huge infrastructure costs.

• 13:36 Joshua

  Yeah.

• 13:39 Kellen

  Does that answer your question? Sorry.

• 13:42 Michael

  Yeah. Um, so I'm curious whether if, if you guys are evaluating a potential new team member, do you actually go and look at their GitHub account and what do you look for there? And I asked that because to me coming technology new. That's one of the really kinda, to me, one of the really cool things about technology, but at least at this stage, almost everything that I've done is there publicly for someone to see if they want to, in contrast to many careers where you just start up, well, I tell you I'm good at something and you've kinda got to take my word for it.

• 14:19 Joshua

  Um... Short answer. Yes. I do look at to get hub also look at linkedin and Twitter and things like that. Um, but not always necessarily to see any sort of uhh quality of the code. I'm looking for personality and those things, usually. one of the biggest things that I'm looking for with a team member is that they're going to be able to fit with the team. There are lots and lots of people who are qualified to do the work or even if they're not qualified. Quite often I can teach them the work I want them to do, but if they're not a good fit for our team, that's a much bigger problem, particularly in our case because we all work from home.

• 14:52 Joshua

  So there's a very certain personality that we need to look for that is self motivated and can work from home without going stir crazy and all those other things. Um, so that's actually what I'm looking for. But certainly I will look through the code and I will get some idea of the types of projects that they've done. But I don't rely on that entirely because certainly I know a lot of my clients, I can't put things like that public. I have to keep that portfolio private and I assumed that that happens with a lot of other people. So I don't take too much of that for granted.

• 15:23 Kellen

  Yeah. For me it's definitely just another data point. Especially with the junior folks. You don't have a lot to go on in their career to, to kind of be able to measure their, did varying skillsets like kind of everybody comes out of the boot camps have similar skills.

• 15:35 Kellen

  Um, but they're there. GitHub account can give you a lot more details on what they've explored on their own and what, what kinds of things they're interested in. Um, it's, it's Kinda like a writing portfolio. You know, if I was hiring a writer, I would want to see things they'd read before. Um, but like Joshua said with the experience, it gets a little bit rougher because like most of the work I've done over the years is closed source and proprietary and owned by the company that I worked for. So I my GitHubs filled with silly things. It's probably not the best thing to judge me off of my goofy, goofy joke projects.

• 16:07 Joshua

  Actually. I will say some of those goofy, silly things are the things that I'm looking for. I'm actually looking for personal projects that you did for fun because that actually tells me a lot more about how you think and how you develop, when it comes down to it, based on the sorts of projects you chose, not necessarily just some cookie cutter ones that you got from the boot camp.

• 16:27 Joshua

  And I've seen several of them. They have certain things that they do on certain days and they push that all up on to GitHub and it does give them a wealth of stuff on there. And Yeah, sometimes I am just looking for some stuff to give me some confidence that they can do it, but actually I want some shiny stuff when it comes down to it. I want things that I'm going to think, oh that's actually really nifty.

• 16:47 Kellen

  Yeah. It's kind of interesting cause uh, that, that individuality that like seeing the thing that they're trying to create is a good example of, um, like their experience. Like as you get more experienced and you can kind of focus that experience on different topics. So it'll show you both their interests and what they're good at. Uh, based off of the things they chose to build.

• 17:08 Kellen

  Um, and so that's really helpful sometimes for like junior folks. I will read the code and kind of try to look for individuality within the code, like the way it's structured or the way the functions are laid out. But with... Junior folks haven't really formed opinions on a lot of code... A lot of those things yet. So it's kind of limited. You know, I like people who write clean code, that means we have to clean up less of it later. But even a messy programmer can be extremely useful in a team if you have somebody else who just loves the refactoring and renaming and fixing white space, which I happened to be that person. So.

• 17:41 Michael

  Okay. I'm curious, obviously, you know, as new developers as we finally in that first for a second job. Um, we're spending a lot of our time working on algorithms and code challenges and whatnot, to pass, the dreaded technical interview. But I'm curious, how often do those methods actually get used in the real world? Is that something you're going to use on a regular basis or is this something you just got to sort of view kind of like the LSAT or the MCAT? Is it's just the price of admission. The key to the kingdom.

• 18:14 Joshua

  Umm..

• 18:16 Kellen

  Yes!

• 18:19 Joshua

  Yes and no... Personally I would never use those because I don't think they work and I'm seeing more and more companies getting rid of the whiteboard tests and replacing them with things that make a little bit more sense. But to be honest with you, a lot of companies still do have tests like that. They will put you up on a whiteboard and ask you how many fire hydrants there are in New York City or whatever it may be that's the standard question that they ask. And I don't think it works to be honest. I think people then prepare for that sort of test and it doesn't prove to me that you're actually really good developer or a good fit for the team. I think it just kinda makes developers a commodity more than people and I don't like that

• 19:01 Kellen

  The opposite. The kind of opposite side of that thing is the, the part of this stuff they're testing for is the patterns of programming. So like the concept of a queue is, is pretty universal or the concept of a buffer, which is kind of like a queue and like that, that's sort of what a lot of those are aimed at. And that's really useful stuff to know, um, is the kind of patterns and languages and programming that, you know, you could apply to the real world even. Um, but the test themselves tend to be really, really, really bad at actually testing on those things. They tend to end up picking a really specific subsections, like 'how do bubble sorts work'... At best. Um, and, and so you see a lot of them, you almost have to learn them to get through a lot of interviews because a lot of companies that just kind of what they picked as their bare minimum in general, you won't use specific things. You tend not to use the ones that they teach you for the interviews, but you will use a lot of patterns in your day to day life. Um, they just might not be the ones you guessed.

• 19:58 Joshua

  Yeah. Now I have seen, uh, one of the best things that I've seen is take home tests where you're given a lot of latitude to Google things as much as you want, come up with creative solutions for things, but they have a very specific specification, which is much more like the real world. You're going to get a specification from a client or from the business and then you have to find a way to build that and budget the time for it and everything else. And I have seen some of those popping up lately and I do, I like those. I think those are good things to prepare for it because that is very realistic. That is what you're going to get in the real world.

• 20:29 Kellen

  That's a better way to approach uhh like individual measurements too. If you give somebody a set of constraints that are problem that needs to be solved, but let... You know however you can solve it is fine. Um, then folks will kind of naturally use their strengths to, to augment their weaknesses to, to find kind of creative solutions to problems. That's a much, definitely my preferred method of interviewing as opposed to trying to test on very, very specific topics that may or may not be used in whatever job you're applying for.

• 20:57 Michael

  Cool. Yeah, that's uhh. That's definitely helpful. Um, I'm curious to see, because obviously it as a, as a new developer, we're often working by ourselves, but obviously in the role as you've emphasized numerous times in the course of this discussion, the importance of that team and the cultural and the fit. Um, so I'm curious to see if you guys have any thoughts. Are there any ways to sort of stimulate those team group dynamics while working solo?

• 21:30 Joshua

  Um, certainly there are... In fact, because I worked from home, I also go into coworking center. Kellen does as well. We, both our jobs are fully remote, but we do go into coworking centers so we can work with other professionals, get feedback and input from other people. Um, there are also a lot of developer communities on Twitter and other places on the Internet where people do work together to do that sort of thing. Exactly. To work together on their various projects and get that sort of feedback and somebody to bounce ideas off of and kind of simulates being in an office and doing all those things even if you are working solo.

• 22:07 Kellen

  Yeah. The the biggest by far, the biggest important part there is feedback. Uh, when you work on your own, you're kind of the only person you have to check everything is yourself, which is kind of self reinforcing.

• 22:17 Kellen

  Um, and just having people to bounce ideas off of or to check your work and you know, as much as you can do that as possible. So you're getting fast feedback... You'll hear that as a concept in programming for Agile. Uh, but like fast feedback on one or you did something well or you did something poorly, like any way you can get that as a, as a great improvement and it'll also help you grow faster. Uh, just because you'll be like, oh no, that's terrible in, you'll be like, what it is. Oh, that it, you're right. That is terrible. I should be doing that totally differently. And so you'll learn faster. Um, in general, I mean, you can't, you can't really learn those skills totally in isolation, but there are a lot of ways to kind of encounter folks without having to join to get hired on at places like Josh said, coworking or meet ups or you can, you know, start working on open source projects.

• 23:01 Joshua

  I was going to say exactly that.

• 23:01 Kellen

  Even if you're just fixing typos, you at least have to, you know, communicate that, hey, I fixed this typo and finished this silly... you know, you're this extremely, not necessarily silly but long process to get this submitted to an open source project. I mean, although it might be things you have to sign or whatever. So.

• 23:18 Michael

  All right, great. Um, I think sort of following on the structure of this discussion, I'm curious to see if there is a question that either of you wish you had been able to ask a senior developer earlier in your career or advice that you wish you had gotten earlier in your career.

• 23:40 Joshua

  Uh, oh, so many.

• 23:43 Kellen

  I was just like, I can I, can I get this down to one or two? I'm not sure.

• 23:50 Joshua

  Um, certainly there are some things that would have made life a lot easier if I had known them in the first place. Uh, I certainly wish I had had a crystal ball to ask what languages and frameworks I should have learned because I've learned a lot of them that just never went anywhere.

• 24:04 Joshua

  Um, but I think actually if somebody who could have helped me learn how to progress my career had told me that actually early on learning other things would be one of the quickest ways to progress my career. Learning project management, learning how to deal with infrastructure, learning how to communicate with customers. Those were the things that actually made me stand out as a developer and moved me from junior to regular developer and then on to senior and then into higher positions more than anything else I did. I, I did dedicate a lot of time to learning languages and syntax and all these things. But when it comes down to it, it's those other things that actually were what really drove my career. And I wish I had learned that many, many years ago.

• 24:49 Kellen

  Yeah and I wish I had learned it, not necessarily like individual questions, but lots of questions. So like we were kind of mentioned, you know, just getting feedback is such an important thing and that's something I didn't learn till I was basically his senior developer. That how useful that feedback is. It was by far the most helpful thing on everything. It just, you know, anything that I did as part of my business on whether, how is communicating, uh, the, the, the technologies and things I was learning. Just having somebody kind of like, Hey, what do you think of this idea? Um, that experienced more of that was, would have been ridiculously useful. I'm not sure if I have any specific examples of any of these things that I can actually think of, but..

• 25:29 Michael

  No, both of those are really good answers. I guess sort of kind of along the same lines, I'm curious if you're willing to share, um, you know, sort of a, a mistake you made along the way and the lesson that you learned from it.

• 25:52 Kellen

  Oof. Oh, um, let's see here. So I'm a big, I'm a, I'm a big proponent of learning through failure. Actually, that's kind of an important thing is to not be terribly afraid of failure. The idea is you shouldn't plan for a worst case scenario to kind of like limit the repercussions of everything going wrong. You know, have a, have a back out plan when you push to production. Don't assume it's going to go well and don't try to plan for every contingency. Simply be prepared that if it does go south, be prepared to take responsibility for it and get it back to something that at least functions as well as it was before you showed up. Um, and that, that that's a great example of something I learned through trial and error. You know, first time you push something to production and production goes down and you have no plan for that. Well that, that's a lesson in itself. Um, I might have to try to think of something more specific than that though

• 26:49 Joshua

  To be honest, much the same. Kellen and I actually worked together early on in our careers and we developed some very similar habits. He probably got them from me because I tend to be, I'd like to say I'm intuitive more than a planner, so I assume things are going to go wrong. And in general, the things that I do work pretty well, but I know because I'm not one of those people who will go through and check every I and cross every T

• 27:16 Joshua

  that I need to plan for contingencies and have a plan of action if things do go wrong. So while I'm sure I've made a lot of mistakes, it's been very infrequent that they amounted to any real damage because I had a lot of plans to take care of that when things did go wrong. And realistically it doesn't matter how.... Kellen, as he said earlier, is very good at the refactoring side of things and he is very thorough. But even if you are very thorough and at some stage you're going to get something wrong, things are going to go wrong. And having that contingency plan, having a course of action and being able to own up to your mistakes early on are all really critical things and they are the things that will stop those mistakes from becoming a huge mistake.

• 27:58 Kellen

  That's an example of where like individual skills and like all those extra skills you have can come really help.. Can be really useful. Uh, for when you accidentally took down a customer and now you're on the phone explaining to them why you broke everything and how you're going to fix it and make it better. Um, you know, people skills uhh help a lot for that and that and being able to handle those things make you much, much more valuable as an employee of that. You didn't have to bring in a manager or a product manager to, to calm the customer and explain to them what you were going to do to fix it. You fixed it yourself. So you know, being prepared and capable and confident of fixing your failures, is probably the most important thing. Um, and you, you gain that confidence by failing and fixing it the hard way. That's kind of a also another nice place for another senior or mentor type person to help catch you when you fall a little too far.

• 28:49 Joshua

  Yeah. To give you a very specific example, I did have a client, we were building a case management system for them. Basically it took orders in and allowed them to get prices, print out, invoices and summaries all the rest of that. And we pushed up a fix. It was actually a relatively minor fix, but it wasn't tested thoroughly enough and it went out into production. And the next thing I know, I get a very angry call. 'Joshua, why are we getting all these bills going out for £1 million?' I don't know. Did you raise your rates or, it turns out we've made a fairly minor math mistake, but it changed everything from a couple of hundred pounds to a million pounds, 2 million pounds and it was a little bit embarrassing for them. And actually in that case, I didn't have anything to fall back on.... we fixed it quickly for them because we were trying to be very responsive as it was our fault. But, um, sometimes you can't have a contingency plan, if you don't know what's going on. But in that case, the way we dealt with that was we put in an extra unit tests in for him to verify that before we did it, push anything new out, all the math was verified and checked before we charged anybody £1 million for something.

• 29:54 Kellen

  Yeah. And I've, I mean, I've done installs and pushed patches and done a lot of fixes that have broken something unintentionally. Um, and sometimes you can fix that. Uh, sometimes it's, 'oh no, I just broke the database'. All right. Time to walk through restore procedures. Or maybe I can fix it maybe. Okay, what's the timeframe that I think I could possibly fix the solution in, you know, through acquiring and testing and then, okay, is that acceptable to the customer? And then, and so like a lot of that is, you know, just taking responsibility for the failure and doing the best you can without really, again, worrying too much about what you can't.

• 30:28 Joshua

  No agreed, as long as you're not being lazy about it or not giving it due diligence, mistakes are gonna happen. You just have to assume it's going to happen at some stage and be prepared for that

• 30:43 Michael

  Right no that... It's even, I mean, obviously on a very minor scale, but at least for me, um starting this journey. Well was one of the things actually took a little while, was getting used to, okay, error messages are okay.

• 30:56 Joshua

  Yeah!

• 30:57 Michael

  you learn from that. But it's, you know, you get stuff big red banner. Oh my God, I broke something!

• 31:04 Joshua

  That is something. I will say that the reality is your development career is going to take time to build up. And I've seen a lot of developers move very quickly into senior positions... Within a couple of years, but I think the reality is to become a good developer to avoid those things. It takes a lot of years and that's one of the reasons why I don't have any really great examples because I started developing over 20 years ago when I was not really making any money off of it. So it really didn't matter at the time anyway and slowly built up to it. And by the time I was doing things that did cost people millions of pounds, I had a lot of experience behind me to help me avoid things like that. And that is something worth paying attention to. Don't try to rush it, make sure that you're comfortable with what you're getting into. That doesn't mean you should be lazy about it. You should push your boundaries, but do so safely for you and your company and your career.

• 31:54 Kellen

  Yeah, you'll hear the advice over and over again. Don't, you know, don't be afraid of failure. Just be prepared for failure because it's still going to happen. Whether you're afraid of it or not.

• 32:05 Joshua

  Yeah

• 32:06 Michael

  That is very true. So... I think that really, that was my list of questions for today.

• 32:17 Joshua

  Well that was fairly pain free

• 32:21 Kellen

  Yeah we never know what we're getting into by, you know, welp, let's have somebody we met on Twitter ask us a bunch of questions for 30 minutes. It's going to be great.

• 32:29 Michael

  What could go wrong, right!?

• 32:30 Joshua

  What that go wrong!?

• 32:32 Kellen

  Yeah. But we do really appreciate, like, like we said, we were trying to guess what folks who were coming into the industry might ask us and it's difficult for us to kind of envision that viewpoint at this point. You know, it's always kind of the problem of the teacher of guessing what questions someone might want to ask us. It's much better just to have somebody ask us directly.

• 32:50 Joshua

  Alright, well, we really appreciate you taking the time to come on and ask us these questions.

• 32:57 Michael

  Absolutely. No, I, I, I appreciate your time very much.

• 33:01 Joshua

  Alright. Thank you again for joining us, Michael.

• 33:04 Joshua

  Uh, we will put some transcripts, upat gettingappsdone.com. Please be sure to check out my website at joshuagraham.info and Kellen's website at piffner.com also check out Michael's Twitter account @hippo_web. I'll toss some links up for those in the transcripts so that a lot easier to find. Also, please don't forget to subscribe to the podcast. We come back every week on Thursdays. Until next time. Thanks for listening.