Where to Find Dan Forkosh

On the web: danielforkosh.com

On LinkedIn: https://www.linkedin.com/in/danielforkosh

Book Recommendations

This week’s audiobook recommendations are Why Motivating People Doesn’t Work and What Does by Susan Fowler and Brief, Make a Bigger Impact By Saying Less by Joseph McCormack.  Get your free audiobook by visiting ardentdev.com/audible. Thanks to Audible for supporting this podcast.

Music by Nazar Rybak and Alvaro Angeloro from HookSounds.com.

The post #013 – Test Automation Culture with Daniel Forkosh appeared first on Ardent Development Podcast.

Vaidehi is an engineer at Tilde, in Portland, Oregon, where she works on Skylight (a smart profiler for Ruby and Rails applications). She enjoys building and breaking code, but loves creating empathetic engineering teams a whole lot more. In her spare time, she runs basecs, a weekly writing series that explores the fundamentals of computer science, and is co-host of the Base.cs Podcast.

In this episode, Vaidehi shares about her background as a writer and educator, the origins of BaseCS, and how BaseCS is making computer science concepts accessible to a broader audience.

Where to Find Vaidehi Joshi

@vaidehijoshi on Twitter

BaseCS blog series on Medium

BaseCS podcast

BaseCS video series

TEDx talk

Book Recommendations

This week’s audiobook recommendations are The Five Dysfunctions of a Team and Silos, Politics, and Turf Wars by Patrick Lencioni. Get your free audiobook by visiting ardentdev.com/audible. Thanks to Audible for supporting this podcast.

Music by Nazar Rybak and Alvaro Angeloro from HookSounds.com.

The post #012 – Learning Compilers with Cartoons with Vaidehi Joshi appeared first on Ardent Development Podcast.

We were inspired to invite April on the podcast after reading her fantastic article Confessions of a Recovering Jerk Programmer.

Where to Find April Wensel

@aprilwensel and @compassioncode on Twitter.

On the web at https://compassionatecoding.com/.

Book Recommendation

This week’s audiobook recommendation is Awakening Compassion at Work: The Quiet Power that Elevates People and Organizations. Get your free audiobook by visiting ardentdev.com/audible. Thanks to Audible for supporting this podcast.

Music by Nazar Rybak and Alvaro Angeloro from HookSounds.com.

The post #011 – Jerk Programmer to Compassionate Coder with April Wensel appeared first on Ardent Development Podcast.

Where to Find Luke Ball

At lukeball.com

@holidomelarry on Twitter

Book Recommendation

This week’s audiobook recommendation is The Three Signs of a Miserable Job: A Fable for Managers (And Their Employees) by Patrick M. Lencioni. Get your free audiobook by visiting ardentdev.com/audible. Thanks to Audible for supporting this podcast.

Music by Nazar Rybak and Alvaro Angeloro from HookSounds.com.

The post #010 – Reimagining Your Product with Luke Ball appeared first on Ardent Development Podcast.

Where to Find Gerry O’Brien

@gerryob on Twitter

Book Recommendation

This week’s audiobook recommendation is Quiet: The Power of Introverts in a World That Can’t Stop Talking by Susan Cain. Get your free audiobook by visiting ardentdev.com/audible. Thanks to Audible for supporting this podcast.

Music by Nazar Rybak and Alvaro Angeloro from HookSounds.com.

The post #009 – Small Town to Tech Giant with Gerry O’Brien appeared first on Ardent Development Podcast.

Where to find Adam Englander

@adam_englander on Twitter

On the web at https://www.iovation.com/

Enjoy the show and be sure to follow Ardent Development on Twitter.

Book Recommendation

This week’s audiobook recommendation is The 17 Essential Qualities of a Team Player: Becoming the Kind of Person Every Team Wants by John C. Maxwell. Get your free audiobook by visiting ardentdev.com/audible. Thanks to Audible for supporting this podcast.

Music by Nazar Rybak and Alvaro Angeloro from HookSounds.com.

The post #008 – Fingerprints Are Forever: Biometric Factors for Authentication with Adam Englander appeared first on Ardent Development Podcast.

Where to find Mike Hrycyk

@qaisdoes on Twitter

On the web at qaisdoes.com

Enjoy the show and be sure to follow Ardent Development on Twitter.

Follow @ardentdev

Transcript

Ron: We are joined today with Mike Hrycyk who has been trapped in the world of quality since he first hit his user acceptance testing 19 years ago. He has survived all the different levels, and a wide spectrum of technologies and environments to become the quality dynamo that he is today. Mike believes in creating a culture of quality through software production and tries hard to create teams that hold this ideal and advocate it to the rest of their workmates. Mike’s currently the director of quality for PQA Testing but has previously worked in social media management, parking, manufacturing Web photo retail music delivery kiosks and railroad. So welcome to the show, Mike

Mike: Thank you. Glad to be here.

Derek: It’s good to have you Mike.

Ron: Glad to have you. Now you just finished up at a conference. We thought we’d have you on to talk a little bit about your first talk that you gave there are. Augmenting the gentle team, a testing success story. Could you give us started on that topic, Mike.

Mike: Well sure, for sure. So Agile for me is a bit of a passion, I think. I really believe in the power of Agile. But one of the things that I’ve learned in working with people who do Agile is that when when people self teach or when they have bad coaches people seem to believe that there’s a right way to do Agile, that there’s one way to do Agile and they go out and they find a how to guide for how to do Agile and it teaches you how to implement it. But the problem with that is that every situation is incredibly different and that Agile isn’t really set up to be a how to guide it’s set up. It has a manifesto, it’s a set of concepts and it’s something that everyone who adopts it has to figure out how to do it right. And so I had a project that we did with one of our clients so, we’re testing as a service company. And we got involved with one of our clients where we did an assessment and helped them figure out what they needed to to be successful and some of the work they were doing. And one of the things that that we were looking at with them was is what they’re doing, is it doing Agile wrong, is it doing it right? And I have this personal mission to make sure that no one believes that you’re doing Agile wrong as a term that you can hear. I’m not sure if you guys are familiar with the concept but when I hear that it just makes me angry because Agile is an iterative approach to everything and it’s the way that there’s no way that it needs to be done. You’re doing it right, if it’s working for you. And so this talk that I put together is sort of a case study from a project where we did take and went way off the standard realm of Agile and did it our own way. And I wanted I talk about how we did it what the problems were and what the success was to help people see that doing Agile your own way is probably the best path to success. That makes sense?

Ron: Absolutely. It’s an interesting topic because as you go from company to company and do different assignments there you see Agile implemented in different ways. And I think if you talk to the folks that are involved in projects they would actually give you a slightly different slant which I think is aspirates this topic of are we doing it right. Because I.T. is often, you know years ago, there’s a right and wrong way if you will, right there seems. But this seems somewhat fluid. I think people are having a hard time knowing you know are we doing well or are we doing it right?

Mike: Well and for someone who grew up in Waterfall who’s spent years having lists of things that you need to do to do things properly Agile so different from that. And I think that’s one of the reasons that some people and I hesitate to call people old timers but if that’s your mindset maybe that’s the right way to say it. You get stuck in that mindset and Agile has too much change, it’s just too fluid and it’s difficult for you to go into that new world where you might have to be able to shift every two weeks, you might have to be able to shift the way you’re doing things because you’re supposed to be iterating to make things better.

Mike: So the clients I won’t name names but the client is a Canadian client that produces a retail management solution or an RMS for mobile phone kiosks. So when you go into a mobile phone place in a mall or wherever you go and you buy a phone and probably not the ones that are actually branded Fido or Bell or whatever, probably one of the other ones although they sell to the carriers as well. But when you go into one of those and you buy a phone, one of the things that they need to do is they not only have to track the purchase of the phone. They also have to set up provisioning for the phone so that when you walk out of that kiosk that you have a phone that is connected to the carrier and that does what it needs to do. So they produce software that takes care of that, takes care of the selling and takes care of that. And they’ve also extended it and tried to make it an option that will sell and take care of all of the needs of that client. So it also takes care of employment stuff, it takes care of inventory, it takes care of reporting and tries to take care of all things. And really what end that ends up being is it ends up being a very very complex system so anyone who’s worked in an ERP knows that that it’s like an octopus only not eight arms, like a million arms that that thread through all different things. And so there’s a lot of integration points for that. And then. So they were having some problems with one of their end clients which is what I term one of our clients who is working with someone else down the line. We call that the end client sort of like end user and when they work with an end client that end client was a name of one of the major carriers in the U.S. and they did 40 percent of the business for my client. So what they did is they had a lot of clout in conversations about features and things and that end client had 15 other vendors delivering solutions that all built together into integrated system that made them successful.

Ron: So it’s an octopus of octopuses.

Mike: Yeah yeah every aka arm had other octopuses living off in this kind of mutated. What that meant though was that that the SIT testing,the integrated testing environment system integration environment was very necessary and complex because you couldn’t test on your own box you can’t test for what’s going to happen when you have 15 other vendors delivering pieces of not code necessarily but messaging and communication and interfaces and all of that into one integrated system that’s going to work. So we have this healthy integration system and then to make it even more complicated. The RMS system that the client was producing, they had 13 different feature teams feeding features to this and they had one consolidated product that went out to all customers. But the end client that owned 40 percent of the business they were also responsible for getting specific features that worked not necessarily just for that end client but there were things that only the end client wanted and they had enough sway to get them for them. So there were in one solid rollout that went everywhere there were feature flags for some things that only worked for that end client and then there were features that went both ways features that other feature groups were delivering that the end client had to use and things that the end client was asking for that would also go to work for all the other clients. So if I haven’t illustrated something that’s really complex too yet maybe I can add more?

Ron: Oh, there’s more?

Mike: Well the things other things that complicated it for us was they had the environments, were very let’s call it rich to be polite. There were 32 different environments between dev staging and tests and more could be done at a whim if necessary. So their monthly release cadence the end client took their versions one month after everyone else so everyone else would get the release say in January and then it would have a month to solidify and make sure it was okay and then the end client would get their stuff a month forward. So now we’re talking version control problems where well which version are we fixing in this? Which pieces that we fix here have to go there and the code that specific for the carrier, does it have to go into the version that’s going to production? Maybe that’s enough complexity?

Ron: You see this a lot, though. I mean that is that is very complex especially when you look at the additional teams behind the end client. But today, we’re seeing this so much with these environments that an octopus is a good way to describe it. But it doesn’t even do it justice because of when you’re multiplying out against the different environments and then managing what piece of code is in what environment versus database version versus the data that’s in in timing all of that. I agree with you, that in itself is as complicated let alone what you’re building for the software.

Mike: It was pretty positive on the part of of our client that they had enough gumption to make statements like no when we write features everyone gets the features. They had to compromise a little and say to this this person who produced 40 percent of their business and said “Okay okay so you need something special? ,we’ll add that on” But that’s an additional feature, any feature that went to everyone went to them as well. So I mean that was pretty positive. I’ve seen where that’s not been the case in the past and that makes a horrific.

Ron: Right, yeah that’s a good first step but

Derek: That makes for disaster down the road.It’s customized versions of the software.

Mike: And so when you when you take all of that complexity that’s talked about and then you say “Hey so how well that sprints and Agile work?” that’s that’s where we start running into the problem. So I mean my focus is always on “Hey how does testing work does it work?, does it work okay?” And the big problem that they rolled into, in the amount of complexity that we’re talking about both within the product itself and then the different integration touch points meant that there was a pretty big regression suite that needed to be gone through and there was automation and automation could do so much but it was trouble with the end client piece just in terms of time and I’ll get to that in a second. So what would happen is the feature team, there was one feature team that was dedicated to the end client making sure they had the features that they needed. They integrated properly with everything else and they would go through their sprints and they had to QA on their team and it was a pretty standard Agile team you know five or six devs and a product owner and a couple QA. And things worked pretty well. And you know they produced a feature and QA tested a feature and made sure it was okay until you got to the point of saying “hey let’s release”. Now remember they were releasing once a month. And when they get to that point they say “OK so now we have to run the regression suite and we also have these deadlines because we actually have a target date for each of these releases”. And what they would get is either Seven or eight hundred test cases and the regression suite and you have two guys who are set up to do that. And of course they have to break sprint with the feature sprint in order to do this because they have to dedicate wholely to that. And indeed, there’s not enough man hours in two people to make that happen either or not and meet dates. So what they would do is they’d go to the other 12 feature teams and they’d say “We’re going to die. And this is an important client. I need help”. And so they would get QA’s from other teams to help them so they would then break their sprints. So we’re breaking sprints all over the place. You’re not getting a continuity of knowledge because you aren’t going to be able to go to the same Agile team every time and say I need your QA. You’re going to get the one that that were there in a place or maybe they can spare someone and not cause disaster so you don’t even get a continuity of knowledge in the way that the end client specific stuff works so when they came to us and talked to us we are in a situation where sprints were being broken all over the place and the end result of that was that they were still shipping but they were getting more and more bugs into SIT that anyone was happy with, more bugs out of SIT into production than anyone was happy with. And because of the complexity of all the things we’re talking about when they found issues finding the right person to work on this issues and finding communication about how they’ll be worked on and when they’ll be delivered were was very slapshot and it was making the end client quite grumpy and you never want the client that’s producing 40 percent of your revenue, being very grumpy.

Derek: Indeed.

Mike: So that’s that’s where we came in. Right. So they just knew that something about quality was broken and they pulled us out and said “hey can you do an assessment”. So we did an assessment and made a bunch of different suggestions and recommendations, that they could do things better. And the big one that they jumped on and that we figured out was let’s talk about this augmenting testing team idea that you have. And so that’s where we looked at the problem and we looked at the idea and they said, well really the problem here is that you don’t have enough people doing testing. So we could just give you four or five or six testers. And what would you do with them? And we said well if we inject six testers into your Agile team, that’s going to break things in a different way, it’s not going to work. So should we spin up another Agile team which as you know I mean the next step that you’ll get to and I guess but what are we going to do with with the normal ratio of having a bunch of devs and a product owner on a team what will they do all the time? And we said, Do we really need them? Do we really have to be tied to this concept that the team needs to have devs on it? And we said Nope which is easy for testers to say. Maybe not so easy for you guys to agree to one for as testers to say. And so we spun up a parallel teams. That’s why we call it an augmenting team and that team was responsible for regression testing and integration testing for code that was going to go to the end carrier and we had a mixed team so there was a team lead and team lead for communication and a senior and that senior became an expert in all the complex systems. Then we added some juniors so that they could take care of the big giant set of regression tests and we also added an automator so that we could start claiming back some of the time that was being lost. The company, the client has a good solid automation practice. What they didn’t have with how often they were breaking the sprint for this end client, there was just no time to ever get automation done.

Ron: So basically you took that Agile team that was in place the first time in those testers that were coming they’re breaking off the Sprint because they they were getting over loaded when it came to releases and you said those first testers they stay with the sprint team and we’re going to form this other team kind of trailing in order to do the testing for for the releases and the integration. Is that right?

Mike: Yeah absolutely. So I mean we had full time work because it was a monthly cadence so we worked in parallel so we’re taking care of regression then we are taking care of SIT at the same time and parallel to that. The feature team was working on the features for the next release and so that feature team in the QA on that feature team they owned those features and they were functional tests those features and make sure that they were OK, and when they were ready to come out into staging they would hand it all over to us and demo the features and we would take over responsibility for regression testing those feature as well as the regular regression testing suite and move it into a set and then take care of the integration testing. And so we took a lot of that load off of everyone and we also took over the entire communications suite. So one of the other challenges that the client had was if you get an issue you find an issue and SIT that issue could have originated with that one feature team or any one of the other 12 feature teams, coordinating, doing triage on that getting someone to go in and debug it and fix it and find a solution and deliver a solution. And couple all of that with communication and delivery SLA that you have with your end client and things were getting lost and misplaced and you just never knew the status of things. And so we dedicated one person on our team who took ownership of communication and tracking, all of those things, and it made the end client very happy.

Ron: So did your approach deal with any changes of the environment set up as well or the number of environments because that sounds like a heavy load just the number of environments you describe coming in?

Mike: So they they haven’t really done anything to fix anything in that area prior to our coming. What we took on was some environment coordination tasks so we knew which things had to be and which environments for us. There were other environments that we said we don’t care about those if you need those for whatever reason. So payments might need their own environment to do some investigation into issues or whatever and they could just own that. And we took on responsibility of making sure that our needs were met with the different versions that we were we were working on because of course there were also hot fixes that would move to these environments and etc. So we just took on ownership of knowing where everything needed to be to make sure that the stuff that the end clients expectations were met that they were going to get a version that they could work with when they needed to work with. And that was so positive just our taking ownership of that and they saw the benefits of that, that they went out and hired a full time, I think they called the title QA coordinator, but really their job was to coordinate to make sure that the right things are in the right places and we understood.

Derek: It’s something that you see when you’re working in a small environment if you have one Agile team regardless of the flavour of Agile you know we have this. There’s definitely a prevailing notion that well hey they can just take care of everything. But as the number of teams grow there is coordination connective tissue things like you mentioned, Mike. The handoff from this team during regression and an issue but really the issue belongs to the other team. There’s so much that I get taken care of in order for the organization to be efficient. I am I’m super fascinated by the by this approach. One of the things and I don’t think Ron’s ever heard me say this but one of the things that I have said to other people in the past is that as you build features you are accumulating effectively extra work for yourself in the future. So you build a feature and you test it now but you want to always make sure that that feature is working, especially as you glue new things on your system. Eventually you will get to the point if you keep building features where it takes you longer to regression test then you actually have time in your release cycle and so you to get to this point where all you ever do is regression testing and you really have to do one or two things, you have to augment your aggression in some way, which is what you’re talking about or you have to be able to automate it which is basically another form of augmenting your team. Otherwise you just eventually have to stop regression testing things.

Mike: I think when you start talking about those kind of problems that you need to implement an integrated automation strategy which includes as full coverage of unit testing as you can and understanding that coming out of each sprint that you’ve automated and what you need to automate so that you don’t have to do these complicated regression passes. I don’t think that’s the full solution for the the case study I’m talking about because you can’t control the 15 other. You’re always going to do the SIT testing because of the 15 other vendors. So I think that the solution that we had like maybe we could have invested a whole bunch of money and done a whole bunch of automation and then said, Okay now we just have to maintain it, but that wouldn’t have been enough because there’s still that integration testing. Having the other people involved at that point. I mean you can’t mock them all out and expect that you’re going to get the research right results in the end because they’re not as clean as a mock is, right? So in this situation they’re always going to do some level of SIT testing but there are other situations without the 15 other vendors that if you have a good solid automation strategy where you’re thinking about what you need to automate at the same time as you’re thinking about what you have to code then then I think you can go a long way towards saving yourself having to have a parallel augmentation team.

Derek: And there’s no question that that’s testing in the presence of integrations to third party systems that are out of your control is just so it makes it so much more complicated. It’s so true, we can build really interesting software that way but man, it’s hard. Yeah. You make really a point there.

Ron: It’s really tricky too when you look at the spectrum of maturity of the different vendors because often you go with a vendor that has the right type of functionality base that you want for your solution and then you have to dig to find out where are they on the spectrum and how do I manage that differently because there’s a very mature method with vendor one and there’s a very immature method with vendor two.

Mike: Yeah know that’s true. And in some sometimes you just have to take it on faith. Faith and that that end edit vendor is going to be as hard assed with everyone else as they are with you making sure that you’re delivering quality. So as long as you trust them to deliver interfaces that match the specs, then you then you code to that. And then because I’m a tester you say well then you test for that and you know nine times out of 10 things should work out OK. And then you also have some bugs and you have to build in the buffer to test for it and make sure that you keep it fixed. But yeah at no point do I ever think that you can just say hey we’ll trust everyone and everything will work because just miscommunication can make that not true.

Ron: Yeah. Speaking of miscommunication I know that I was looking through your blog that you have and I know you do a little bit of writing about behaviour driven development and I’m wondering if you touch on that for a minute.

Mike: For sure. So one of the things that we’ve done here at PQA is so where we have one guy we hired in and he done a bunch of BDD’s, so that’s- Behavior During Development. And so he said we should we should this should be something that we advocate for our customers where it’s right and we said OK teach us. So he taught us about it, and we’ve done it. We’ve implemented it with a few customers where there was a need. So the big thing so BDD is an offshoot of TTD- Test Driven Development. And the way it changes the focus of behavior during development is the concept that a lot of the issues that you get post development, when you deliver the product, is you’re delivering a product that the client never actually asked for. So somewhere between the client saying I want a feature that does a b and c Someone interpreted it because we’re humans and every single thing we say has room for miscommunication and interpretation. So it goes through a product manager a B.A. and a dev and all of us have different brains and our brains work in different ways and we have different kinds of focuses and it’s totally understandable that all of that happens and you end up with a tester and the tester says I think this is what they asked for.? And I mean that’s that’s one of the specialties of the tester mindset and one of the reasons that we exist is that we specialize in going back and trying to reinterpret what was originally said to make sure that what was built really is that. And I don’t think any blame, where I think only moderate blame here goes back to the developers because it’s human nature to have these interpretations it’s human nature to write one thing that can be read in three different ways right and it’s a pretty specific skill set to write things that are useful in that way and maybe back in Waterfall days where we had specks that were thousands of pages long we feel that we got those requirements down to a level where no mistakes can be made but we know that’s not true either. But when you move to Agile which is supposed to be documentation light and you’re writing things in plain English it raises the problem up even further. So I forget the guy’s name but this guy came up with the idea well what if we shift all this stuff to the left? And we come up with this idea of having discussions about what we’re going to build before we build it. So we all get on the same page. And so BDD comes with this concept of the three amigos meeting and the three amigos meeting happens right after you start the sprint and you’re going to work on feature X so you take that feature tag for the work item and you say okay let’s have the three amigos meeting. So the product owner says someone who is advocating for the client and most likely to be able to parrot what the client says and in some cases you can actually have the client present for that and the developer and the tester they sit down and they have a meeting to discuss the feature and the we can be 15 minutes long it can be an hour and a half long it really depends on how complex it is that you’re working on. And you talk about the solution you talk about what it is that developers actually going to do because it’s actually what they want. And you walk out of that meeting with all three people on the same page. And this saves time and tests because the tester when they when they get it. They really understand what the acceptance criteria are. And the developer has the same understanding so theoretically they’re going to produce the same product that that is being expected. And it really saves on having produced the wrong thing.

Ron: You spend time translating in the beginning so that it’s not an oops at the end.

Mike: Yeah you spend time in that conversation. So it’s I don’t know like a pot of translation you’re all there hashing it out. So in the end you don’t have to do any translation yourself because you’re all speaking the same language.

Derek: This is an audio podcast you can’t see me nodding my head but it’s so true. Three Amigos rule that, the rule of three it makes such a huge difference.

Mike: And it’s not right for every client. But we we’ve created this thing that we call testing focused BDD and is a little framework that we have that helps our people who are going in and talking to a client and looking at the problems that they’re having and saying you know what we think BDD is right for you and it’s not right for every client. But as soon as you have a client who says yeah our biggest problem is we develop what we produce really good things and then we have to send them back for rework and that’s a Ting-that’s a flag where we say oh is this right for BDD, let’s see if it’s something that they could do and be useful with.

Derek: Is that testing focused BDD framework something that you share externally or is it something that that is proprietary within your company?

Mike: It is something that we are thinking about taking to conferences this coming year. So it’s not something that we’ve written externally yet but it’s something that we’re going to start doing.

Derek: Okay awesome. We’ll keep our eyes out for that, then.

Ron: Well this is interesting, Mike. I think. I think we can hang out all afternoon and chat. If people want to you know get in touch with you. Where are you on the web and what’s the contact information that they could find you?

Mike: It’s Mike Hrycyk and I’m going to spell the name for you. It’s H R Y C Y K.

Derek: Just like it’s pronounced.

Mike: Yeah just like it’s pronounced. Absolutely, no vowels. So I blog rather intermittently at www.qaisdoes.com. That came out of my brain at one point I said “QA is as QA does” and then I went out and found a URL that matched for me. I tweet, Twitter at QAisdoes. My professional career is at PQA Testing, so as I said we’re testing as a service company and we consider ourselves testing experts and will help any company that has testing needs to figure out how to solve their problem. You can go to PQAtesting dot com for that. If you are all friends of Ron and Derrick and therefore local to Fredericton, that’s where our home office is but we have 6 offices across Canada and I’m in our Vancouver office.

Ron: Well that’s great, Mike. I appreciate you taking the time this afternoon with us. Really interesting topic so thanks so much.

Mike: No problem I had a good time. I welcome you to invite me back someday.

The post #007 – Augmenting the Agile Team: A Testing Success Story with Mike Hrycyk appeared first on Ardent Development Podcast.

Where to find Chloe Condon

@ChloeCondon on Twitter

On the web at https://medium.com/@chloecondon

Enjoy the show and be sure to follow Ardent Development on Twitter.

Follow @ardentdev

Transcript

Ron: Welcome to the Ardent Development podcast. I’m Ron Smith.

Derek: And I’m Derek Hatchard. Today we’re talking with Chloe Condon. Chloe is a former musical theater actress and Hackbright Academy graduate and she is now a developer evangelist at Sentry. She is perhaps the only engineer you’ll meet. I think the only one that I know who has been in Hairspray is Xanadu and Jerry Spinger the opera. She is passionate about bring people with non-traditional backgrounds into the world of tech. If you’re trying to place her face she is the woman giving the thumbs up in the what it’s like to be a woman at a tech conference article, which she wrote. I found that on Medium and there might be other places, Chloe can correct me in a second. And a quick google search for her will tell you that she has a series of getting started with docker videos. You find some theater reviews that she’s on, tech blogs and I think the hilarious videos of her singing after. So Chloe welcome to the show.

Chloe: Thank you. Thank you for having me.

Derek: So Chloe, you’re a developer evangelist at a company called Sentry and some of us have bumped into plenty of developer evangelists in our time. But for those listening who don’t really know what that role is. Could you really unpack it for us? What is it? What do your days look like? Tell us a little bit about that experience is like.

Chloe: Sure, so it’s kind of funny. Usually when I tell people who aren’t familiar with the role they say “Oh is that a religious thing”? And my answer is usually well in a sense. But basically I call myself an extroverted engineer. The title I go by is developer evangelist. Other people go by DevRel, developer advocate. There’s a lot of different flavors and varieties of us. So personally I got into the evangelism space because I have a non-traditional background. I come from theater world. And when we were presenting our projects at Hackbright I discovered pretty quickly like oh wow nobody likes to do public speaking. This is very interesting. So that’s kind of part of what I do. So oftentimes I will go to conferences and I will speak about various thought leadership topics. Right now I’m doing a lot of stuff around the error blogging you know metrics space, in my previous role I did a lot of Docker evangelism. So it’s a combination of a couple of things, it’s speaking, it’s writing content. So a lot of the times and you see tutorials or walkthroughs on different websites that’s often made by me and our content person. Doing everything from case studies to writing code examples for different integrations and features that we have. I’m organizing our meetup that’s going to be a monthly meet up starting in January. So it really depends what I like about it a lot is my role changes every single day. Just looking at my calendar next week I’m like breaking it down and seeing OK I’m writing this thought leadership blog and then all day Thursday we’re filming all around the city for our meet up, we’re doing a promotional video for our meet up. We just published The 12 Days of integrations gif blog posts where we call ourselves very gif positive here at Sentry every new employee gets a welcome gif. e featured all of our integrations over the 12 days leading to the holidays which involved having our different engineers hold up different ornaments with the logos of our integrations on them. So there are some really fun kind of theatrical aspects of my role. But a lot of it requires this pretty deep understanding of technology and our product and being able to code. So I definitely went in more non-traditional route as a first role in these software engineering role or world, I should say. But I felt that it very much aligned with with my past. So yeah now I’m now I’m here.

Derek: So the very first developer evangelist I ever met was a guy at Microsoft, years and years ago. And at the time he didn’t even he wouldn’t use, even though that was his job title he wouldn’t use the term developer evangelist when he was going out around Canada because everyone would look at him like What are you talking about? What does that even? But what’s interesting is that there is. I mean there is a fair bit of showmanship involved in it so I can see how such a good fit given that you have a performance background I think that’s really cool. Do you run into the misconception that because you’re a developer evangelist or you work in developer relations or developer marketing that you know you’re not technical or you’re not a real engineer. Do you run into that bias?

Chloe: You know I think a lot of it is mental for me since I am in a sense still very junior because I only graduated from my bootcamp a year ago. No one’s ever blatantly said that to me but I think the voices in my head say that. I usually do not recommend to the bootcamp grads to jump right into evangelism just because I think it’s very valuable to get the time in the trenches and get that time to really understand the pain points and the workflows of engineers. So I really had to put it on myself my first year to make sure that I was coding everyday that I was doing some sort of technology be that writing about it or blogging about it. Obviously in my last role it was very Docker focused and now I’m learning all about this new space of you know error tracking and metrics and logging. So I think that a lot of it is mental and imposter syndrome. There’s always so much to learn. With Sentry in particular, we support basically every language. So my bootcamp, the curriculum was mostly python and Javascript. So when I go to something like Rubyconf or if I go to something like php conference I obviously know how to code and I can build my own. But I haven’t touched a lot of php so a lot of that is I spend a lot of my free time kind of dabbling in those languages. Use a lot of resources like code school and teen treehouse. But yeah I would say there are definitely evangelists out there who are very technical. My role sits on the marketing team which is pretty typical with a developer evangelist or Dev Rel role but I think that it’s mostly imposture syndrome for me. I have to take a step back and kind of calm myself down.

Derek: One of the things that I had that always impresses me with a good Developer Evangelist is how broad they tend to be. So when I worked for sales force for a number of years and I was in Dreamforce one year. I just walked up to one of the hallway demo presentations and someone from the developer marketing team was up and they were using at least a dozen different technologies in their little 15 or 20 minute lightning talk. It just blew my mind at how much breadth and how little credit they get for being able to speak intelligently about so many different things. It’s similar to what you said. The ability to go and represent your product and your developer tools to people who work in many different languages is a it’s a really special skill set. There’s a lot of developers that I’ve known who if that is the complete opposite of what they even want to do. They say I know Java, just leave me alone and I’m going to program in Java. And this what I’m going to do for the next 15 years.

Chloe: And I think there’s really something to be said as well. And obviously my theatre background helped a lot with this of I mean how many times have you seen a talk or watched a tutorial video that is just so monotonous? And you know it’s not the speaker’s fault like they are a brilliant engineer but they don’t know how to present material. So something like unique that I kind of bring to this space is hey I’ve been performing since I was 4 years, old both of my parents were in the theater. I think it was sort of a shock to come to the world of engineering and technology and go to product announcements and conferences and watch people talk about fascinating things that I couldn’t listen to because “we are so excited to present” and it blows my mind. I’m like I said I you know I’m very junior still and people say wow that was one of the best acts I’ve ever seen. And like thank you. I don’t think it was necessarily the best talk you’ve ever seen. It’s just that I know how I have presentational skills. That’s just something that I’ve been doing my whole life.

Ron: When I was preparing to interview you, Chloe I found your Docker video that you had done on YouTube. And you know I could have used that year ago when I went researching on Docker. I was working with a team and they were debating whether they would start using it or not. And there was very little material that was out there that was that kind of a beginner introductory level. You made me laugh about ten times through it. It was a very good video. I liked quite a bit.

Chloe: Thank you. I think it’s funny because I am so used to being this performer onstage I mostly did musical comedies. And so I was putting all these like jokes in my presentation to kind of like get people away because a lot of times your talks are either really early in the morning or really late at night. And now I’ve had to preface my talks in that during my intro and say hey it’s OK to laugh. Please laugh at the jokes because the technical audience is very different. They’re very they internalize a lot of things. And you know I have to remind myself that even as a performer when I go and watch other performers I’m very stoic and I rarely laugh even if I think something’s funny. Encouraging people to you know interact and I think helps a little bit and helps keep people awake.

Derek: Keep pulling on that thread, coming from coming from a theater background, can you compare and contrast with the culture? I’ll call them industries I don’t know if that’s fair to use. What do you see that similar? And what is radically different?

Chloe: Yeah I think you know the first thing that comes to mind. Obviously I left the theater world because I was not getting paid enough for the amount of work that I was doing. The main difference and kind of what led me to tech was you can do theater your entire life and work hard and pound the pavement and audition and audition and you know take acting classes and go to school for it and get a master’s. You can be the most talented person in the world. But if you are not you know five foot three with brown hair. It’s all about look. And it’s very much out of your control. Whereas in the technology world like the number of work that you put in you really get back. And that was sort of mind-blowing for me to realize because I can’t tell you how many talented people I know have been acting their entire life. They moved to New York. No success. And that’s not for lack of trying. I mean this is just pure. It’s a field that involves a lot of luck a lot of good timing. So I actually got interested in technology because my boyfriend is an android developer. When I was first thinking about going to a boot camp he said Oh let me introduce you to some other women who gone through boot camps that I know from my network and my immediate reaction was Oh my gosh they’re not going to want to talk to me. This is a competitive industry. Why would they want to talk to me because in the acting world if I took another woman out to coffee she would of course say you know here’s the places you should audition but don’t take my part. You know it’s a very competitive industry. Whereas oh my gosh everyone in the engineering world was like oh please, please come. We need more women we need more people we need more junior engineers so it’s a very different industry. Not only kind of the need for our talent but also it’s a different world. I mean my boyfriend constantly reminds me that my degree like my B.A. is in drama. And I think there’s a reason it’s called drama. There are a lot of dramatic things that go on as as we’re seeing from Harvey Weinstein stuff that’s happening right now. That’s very common in the theater industry. So I think there is a lot of crossover. The one kind of similarity but different thing that I always point out to people is there are so many women in theater. If you’re a man who wants to do musical theater like you will get cast. There is such a lack of men whereas in the tech industry there are not a lot of women. And it’s very rare to have a line for the bathroom. Whereas you do a musical theater show in San Francisco and the women’s dressing room is packed full whereas the men’s dressing room has guys in it. So I would say the biggest thing for me is just the mentorship and the community aspect around it has just been so warm and welcoming. If you reach out to anyone for coffee or to pick their brain on a technology or even just turn to the engineer who sits behind you. I know I do that all the time at Sentry. Everyone is so willing to help and everybody wants you to succeed which is so refreshing coming from this very competitive you know cutthroat acting industry.

Derek: That’s fascinating. I’m wondering how much of that has to do with the nature of the people that are drawn to the work versus the just the current state of the market where you know, is acting in oversubscribed with talent and technology is still under subscribed? Or is it, is there something inherently less competitive and more collaborative amongst people who are drawn into tech? I don’t have an answer and I don’t expect you to have a firm answer but speculate if you want.

Chloe: Yeah well it’s funny because I get a lot of parents who come up to me after a gives you know technical talks because you know I walk on stage I’m this very quirky five foot two blonde musical theater girl with sparkle glasses who was giving a presentation on a technical subject which doesn’t happen very often. And the number one question that I get afterwards is my son or daughter wants to get a theater degree. How do I get them interested in technology? Because I’ve been there, you don’t want to squash your children’s dreams. But at the same time you know I struggle a lot with this especially when I first got you know started this journey to make the transition from theater to technology. I was very angry for a long time that I had this theater degree because I looked at people like my boyfriend and a lot of our friends and a lot of my co-workers were just such talented engineers who had been doing this since they were 4 years old. And you know I was doing Wizard of Oz the musical when I was four years old. So I had a lot of like kind of angst about that for a long time but now that I’m in this industry and it’s been in it a year. I see so many important things from my theatre degree and from my life as an actress that they bring into my life as a developer evangelist. So it’s hard for me to you know obviously if I meet a young woman and she tells me hey I want to get a theater degree I’m going to say oh my gosh, don’t, please, learn a technical skill that will be useful for you. But that being said you know. That’s kind of the beauty of these boot camps right. People have a whole life before switching careers and they bring expertise like I was sitting on a panel yesterday at Hackbright where the woman next to me worked in FinTech in more of kind of a completely non-technical role and then now works as an engineer and she brings all this industry expertise. There’s people who have been teachers who now work on technology software and they really have that lake inherent knowledge that an engineer who hasn’t dabbled in that industry just isn’t going to have. So I think part of it is just. The arts are a luxury. And I think it’s something that we treat ourselves to and it does not pay as well. And there is the actor’s union of course. But when you take a look at salaries of Broadway performers it was shocking to me and no one ever sat me down as a kid or as a teenager deciding about colleges and said hey you know how much you’d make as an actor? Like let’s kind of let’s let’s break this down because my dad is a playwright and Director and my mother was a costume designer and we had a very comfortable life and I never really thought about what future looked like. So I think a lot of it is just we it’s a passion that we grow up with. But there’s so many transferable skills even stage managers are now transitioning over to you know Product Managers because it’s the same role. It’s the exact same role but a creative industry versus a technical industry.

Derek: I have a friend and former colleague who has a master’s degree in English and he’s a brilliant engineer and he loves it. Every time he finds somebody who has an arts background he loves to point that out to me.

Chloe: We always joked. Even in the Dev Rel community and also in the engineering community we could start a hell of a band. And like do Dev Rel musical if everybody like, Oh I play saxophone. Oh I was a jazz band. I’m actor, I’m an actress I’m a playwright. There’s so many people who come from that background and it’s fascinating to me.

Derek: It’s really surprising to me how many musicians I’ve run into in my career and in tech, there seems to be something about the way people’s brains are wired that programming and music both seem to come naturally. I unfortunately do not have that inclination. I am as tone deaf as they come. Many many people. I will sit and not clap because I can’t keep the beat either. But I’ll gladly listen to the band.

Chloe: Yeah. If you are interested in in particular music and engineering, Katherine Meyers did a talk at Rubyconf that I think it was titled something like Mozart would have been an amazing engineer or something like that and she is a opera singer turned engineer and she talked about all the parallels between music and engineering and it was absolutely fascinating. Highly recommend checking it out.

Derek: That sounds fascinating. I going to look that up. Okay so before we run out of time, I want to talk a little bit about air logging and reporting. I think to do that we’ll need a quick explanation of what Sentry is and sort of the company and the open source tech. I’d love to just hear a little bit about how about is making the developers more productive or how it’s making their systems more stable?

Chloe: Yeah absolutely. So Sentry is an open source error tracking product that helps developers monitor and fix crashes in real time. Basically you’re going to be able to iterate continuously and it can boost your efficiency and definitely kind of prove your, or improve your user experience. The way that it kind of explain this to people because the number one question I get that our booth is well can I just use my logs for that? Well logs are a really great tool. They’re kind of like the scrap book or the history report of what’s going on in your app and you can set up alerts on your logs. But how do you know what’s going to happen? How do you know other than a user tweeting at you and saying hey this feature is broken. Something’s going wrong. You also have metrics of course and metrics are very useful to have a dashboard to see. Oh you know this line is going up very steadily maybe we should check that out, but your dashboard is only going to monitor the things that you have set up. How do you know about those things that are just totally out of the blue? Users in Australia are all facing this issue when they do this particular mouse click and you know maybe this user used an emoji and now it’s throwing you know an error. What we do is we alert you when those things are happening in real time. So you can kind of think of us as more of a system that uses the power of your logs and the power of your metrics to keep your engineers informed. And then you can delegate those tasks and say hey you know what’s going on here? Is this fixed? Awesome you can ignore them if it’s known issue. It’s really kind of keeping you aware of what’s going on in your app. For all of those kind of edge cases and situations that you haven’t prepared for. Everything from a 404 error to people are running into an issue. I mean this is the difference between someone using your app and a competitor’s app. If they can’t log into your system you need to know that that’s happening. So yeah that’s a little bit about us. We’re also open source so a lot of people have either touched our product or contributed to our product in some way. And you can go online, it’s two lines of code to use it. And it’s pretty great.

Derek: And I am going to ask you some 101 questions here. Is this doing anomaly detection on an error messages? Give me the next level deeper around how this works.

Chloe: Yeah sure. So basically this is going to give you all of the information you don’t have to blindly guess of what’s going on. So the crash reporting is going to give you anything from the browser that user was using. The operating system… you can do feature flags you can have breadcrumbs in there and it’s going to group all of the similar ones together so you know when there’s a big spike in this. The thing that I always like to say is you know it’s never fun to get those angsty tweets from you know user who says hey this is broken. We would much rather take care of that ahead of time so no one is running into that issue. So you can really understand the bigger picture and get that real time insight immediately. You can get the alerts via e-mail or SMS. It’s just kind of this way that you can really have an eye on your application 24/7.

Derek: OK. And at the risk of the risk of sounding like a commercial when I ask you this because I am curious, what is the difference for teams if they use the open source project versus if they come to Sentry the company?

Chloe: Yeah sure. So basically you can totally use us for free, 10k events per month. That’s with one user a seven day history and then I think once you get to about like the smaller packages it’s a unlimited users for I think 29 dollars a month with a 90 day history. We also have free trials online. If you’re doing it yourself, itself hosted obviously if you’re doing it us, we’re hosting it for you. So it really depends on what your needs are. Obviously if it’s more of you know a side project that you’re hacking on and you want to get my idea of the errors that are coming through very easy to just self host. Once you get a little bigger and you want weekly reports and you know basic SSO and these On-Demand events. In addition to all the core features and that’s kind of where we come into play and you can help a little bit more with that. But we started it as just a tiny bit of open source and we’re very passionate about keeping it open source so that’s really fun because it is rare with a product where especially as an evangelist you go out in the field and not only as someone heard of you but they say oh that’s in my app right now. We’re using Sentry, we love Sentry. So yeah it’s fun to have so many people touch it because of that that open-sourceness.

Derek: That that’s awesome. Thank you for that. That’s helpful that’s sentry.io if anyone wants to find that. This been really interesting, Chloe, thank you for your time. Before we let you go. Can you tell you tell our listeners where they can find you on the Internet?

Chloe: Yes. You can search my name @ChloeCondon on most things except for instagram. I’m @unslothorized like an unauthorized sloth. I had taken a little break from writing but I’m starting back up now and over the holidays so definitely follow me on Medium, if that’s your jam? And I tweet about all kinds of quirky engineering things and theater things on the Twitter sphere so yes.

Derek: Alright. Very cool. Thank you so much for your time. This has been great.

Ron: Thanks Chloe, this has been a lot of fun.

Chloe: Thank you for having me.

The post #006 – Developer Evangelism and Lessons from Musical Theatre with Chloe Condon appeared first on Ardent Development Podcast.

Kevin is also the co-author of Building Web Applications with Visual Studio 2017.

In this episode, Derek Hatchard and Ron Smith join Kevin in reminiscing about early programming experiences on personal computers from the 80s and discuss why curiosity and a desire to learn are so important for software professionals. In November 2017, Kevin wrote the blog post “A Touch of Applesoft Basic” about his early programming experiences and introducing his 80s and 90s tech to younger software developers. Check it out for photos of the things Kevin talks about in this episode of Ardent Development.

Where to find Kevin Grossnicklaus

@kvgros on Twitter

On the web at http://architectnow.net/blog/

In print at Building Web Applications with Visual Studio 2017

Enjoy the show and be sure to follow Ardent Development on Twitter.

Follow @ardentdev

Transcript

Derek: Welcome to the Ardent Development podcast. I’m Derek. And today Ron and I are on with Kevin Grossnicklaus. Did I say that right, Kevin?

Kevin: You did, it’s good enough.

Derek: Alright, good enough. Kevin is an old school developer who lives in St. Louis, Missouri. Say it the right way. And runs a great team of seven developers at his company ArchitectNow. At ArchitectNow they build apps targeting a variety of platforms ranging from web to desktop to mobile. When not building apps, Kevin can be found traveling, chicken pickin’ on his Telecaster or tracking his expanding amount of grey hairs thanks to his three teenage daughters. And he’s still holding out for a second season of Firefly. And I’m right there with you. Right there with you. For those of us who are in Canada which is where Ron and I, you might need to explain what chicken pickin’ is.

Kevin: Oh I’m a country guitar player. So American country music old school country music. I’m a Merle Haggard / Johnny Cash type guitar player. I’ve been doing it a long time.

Derek: Alright. So, Kevin, I saw the blog post that you wrote. It really resonated with me and you were going back looking at sort of how you got into programming stuff that you used to work on.

Derek: And I think it all sprung from building a bit of a museum in your new office. You want to give us a little bit of the backstory for that blog post.

Kevin: Sure. As you said it really it was thanks to the power of eBay. I was putting some technology in a new office we had built and buying some things that I had owned a few old, my original Nintendo and an original game cube and things like that that my wife wanted me to get out of the house. So I decided these would be a clever thing to put on the shelf at the office and talk about share with some of my younger developers. You know the things that I grew up playing or enjoyed back in the day and they’ll get a little more use than they are sitting boxes in the basement. In doing that it got me thinking about you know growing up back in the mid 80s when I when I started programming I was 12 years old. My parents bought me an apple II GS and I have been a programmer ever since the day I got the computer so I went on eBay and I kind of wish I still had that computer and I found one and I ordered one and ultimately I had to order 2 and piecemeal a few together that worked and in doing so I went down to my basement and dug up a dusty old box of floppy disks – five and a quarter and three and a half inch disks. Popped them in and it worked. All my old programs that the blog post that you’re talking about is really me looking back at when I was 12 I was in the middle of Nebraska. And that’s a time and a place where not a lot of people had computers.

Kevin: There were no we were still using rotary phones and there was no internet in the sense that we have it today. And I as of this recording I’m a whopping 42 years of age. Some people consider that young some people consider that old.

Kevin: I’m kind of in that middle age but at 12 years old I’ve got a computer and that computer booted to a blinking cursor. It literally did nothing. It shocked me. I was excited. I was the proud new owner of a shiny new computer and I turned it on and up came a cursor, it did absolutely nothing I dug through the boxes of manuals I said it’s got to be more than this it’s got it. And I was expecting video games and all this fancy stuff to come out of it. Ultimately I had to learn to make it do make make that computer do something on my own. And I found a book that I still treasure very much back in my house. I have a book called Learning to Program in Applesoft Basic so in those days you know you’ve got computers that the availability of software, entertainment was limited. The number of other people that knew how to make them do something was limited. So I wrote a program within the first hour just reading this book just starting at the top and saying hey I must type line 10 print Hello World.

Kevin: I don’t think hello world had become a thing back then I can’t remember what I printed. When something came out I was I was hooked. I love that computer and fortunately got another one and oddly enough all my floppy disks, those original programs I wrote that day 30 years ago, still booted and were still there.

Kevin: All my old comments, all my old code in Basic, C, and Pascal and assembly language. So I spent the last month or so kind of reminiscing and going back and looking at what I learned and realizing that ever since that day my entire career and everything I’ve done has been based on that book and really growing from there.

Derek: It’s really cool. So you wrote comments when you were 12 years old. That’s impressive.

Kevin: I spent time trying to this was before you know Google and books and back then the overall surface area of technology was very small I had no peers or mentors to teach me to organize your code. It was just something that I as a young young guy decided it made my life a lot easier.

Kevin: So I evolved into it over the years obviously best practices arose and I read books and you know went to college for it and did other things but it was amazing to see in 88 and 89 me organizing a group of subroutines in a non object oriented language and trying to do it a little more clearly than I did before.

Ron: So Kevin you are really taking me back.

Ron: My first computer was a Commodore 64 and I can remember being down in the basement with my brother and sister and we would put in that game into the floppy disk and it would take, felt like it would take 10 minutes to load a game and we’d be off getting the old hot chocolate.

Ron: What do some of your new staff that hadn’t seen that before say when you showed them some of these devices, what were some of the reactions?

Kevin: Well their first reaction was to the sound. It was a comforting sound to me but it sounds horrendous when you stick a disk in. You know we’re talking a world of solid state drives and usb drives that old 256 gigs and all the great technology we have today on our phone and here this big computer has moving parts and it grinds and it buzzes.

Kevin: Finally it boots but then it boots boots and boots and the sounds you know instant gratification it was not, it took awhile to do about anything. The computer I had the time the apple II GS was a whopping one megahertz. You could get it up to two if you ran in certain modes. So it definitely is a different world than what we’re just used to on the phone. And the guys in my office are younger guys there. I’ve got some guys that are 23 24 25 years old so definitely they grew up in a time where the stuff was I might have been showing a punch cards and they’d been just as excited. They had no idea what a floppy disk was. Never never seen before let alone saw one popped into a computer.

Kevin: That’s hilarious.

Ron: And back then. I mean computers and you guys know this as well as I do it the people that grew up in that era and use that level of technology. If you were of the mind to program and write your own software, you were by nature a hardware guy and a software guy you had to know a little about both. You couldn’t just focus on one and today everything so specialized and every developers you know you work in this vertical or this niche and you know a lot about the front end and not the back end. People just don’t build computers today. There’s a certain subset that do and that’s very cool to see how far they pushed it. But. For the most part you know sadly a lot of our youth just get phones and play games and think that Minecraft is the greatest thing in the world but no one ever puts thought into how it was written.

Kevin: And when I grew up I wanted to know how it was written.

Ron: On your blog post you have a picture of magic quest.

Kevin: I wrote a ton of games

Ron: And these great big block letters I love it.

Kevin: Yeah, cuz the resolution, there was like 40 pixels. And then when I say pixels they were blocks it was 40 blocks by 30 blocks or something. So I learned to animate pick these big colored blocks that you could pick. I forget 32 colors or something like that and the colors had names. I studied a lot of how to animate them. About a year before I got my computer I got a Nintendo, the old original NES, and you know Mario and Zelda things of that nature so I was fascinated, I was like this is the greatest thing and I wanted to learn how to do that so when I got computer program, I thought well I think these two things must go together whoever made that game must be writing software like this and I didn’t know how they did it but I knew that if I could put it on the screen that’s you know baby step in the right direction then I could put two dots that I could put. You know I wrote dozens of games in my youth some never made it beyond the splash screen. I just wrote, me and my buddies would create these great names and ideas and designs a splash screen bragging about what we did. We never actually got too far.

Ron: Well your blog post made me remember my history a little bit because I did a little bit of that. You know we would draw on a couple of pixels on the screen of the pirate ship or whatever in basic. But my story is that really I got serious about computer science in that first year of university and in fact I took computer science as a filler course. You know I thought I was a science guy I was getting in all the sciences and then I got into this computer science as a course and I was hooked. You know the problem solving and figuring it out, but your blog post made me really wonder about you know everybody’s got a different story right. You are quite young and mesmerized by these early computers and started programming and the like. For me it was when I got serious about it when I hit university and it was almost by accident.

Kevin: One of the key thoughts I had looking back is everybody even my co-workers and my peers, I travel a lot, I speak at a lot of conferences. Fortunately with Microsoft as an MVP, I know a lot of great people through that organization. We sit around a lot and talk about hey how did you get started and everybody has very similar stories, there’s that point where you realize this is what I want to do and that’s the key thing today. I think there’s a lot of a lot of us that organically fell into it. But you know I’m a father of three daughters. When I was a young dad I was thinking my kids are just inherently going to grow up and see all the technology and see what I do and they’re going to they’re going to evolve that way and they’re going to be great coders that didn’t turn out. You know they all have their own career paths and touring college out of state now and none of them for for software development but you know as I see their friends kids I don’t see enough kids at least in my peripheral you know 17 18 year olds that come over to say hey I want to be a coder I’m going to college for computer science. There’s a there is that ecosystem but not to the extent that if I was that age today and I saw all the great technology that’s out there with virtual reality and technology is fascinating today the capabilities all the cloud and just ubiquitous processing power and what we can do in terms of software engineering you don’t see kids gravitating towards that in numbers that I kind of wish they were.

Kevin: And I look back amused, at 12 years old I was impressed by the fact that I can write a basic program and print some characters to the screen. If I’d have had an iPhone, can’t imagine where the world would’ve taken me.

Kevin: My kids are not as old as your kids, Kevin, but I’ve been surprised that you know given that they see you know the work that I’ve done over the years and maybe that’s the problem that dad’s work is just too boring from their perspective.

Derek: But I’ve taken them to learn to code events I’ve taught them little bits of python and they’ve done tons of Minecraft. My son was interested in building a Minecraft plugin, extension, I can’t remember what they call them now. He lasted maybe an hour with Java and then he said Yeah, I’m not that interested in that anymore. And off he went.

Derek: It’s an interesting almost cultural change where those of us who got into it when we are younger… So I was probably a similar age to you. My first computer was a VIC 20 and I wrote some basic on that and then when I got to high school I wrote learned some Pascal and was telling Ron earlier that I wrote a blackjack game. I’m sure they the randomizer and would not live up to anybody’s expectations today but you know our world is so technologically hinged today.

Derek: Everyone has a supercomputer in their pocket but really in many ways our culture is very consumer oriented in that we want to use what the technology gives us, we’re not necessarily very invested in trying to dig in and figure out how to really make that technology do things that it doesn’t do already which is what the games you wrote on your Apple II, you were really taking a piece of clay and shaping it into what you wanted it to be. And you know I wonder if we’re I wonder if in some way the seals on all of our devices are sort of teaching us that these are things that we don’t go and tamper with. It’s almost the maker you know it’s the maker culture and you know in 3-D printing for example where we’re seeing the people who would have been interested in programming when we were young are now gravitating to that space.

Kevin: I am fascinated by the maker culture and I think there is that subset of people that are curious and builders. I’m a huge Raspberry Pi guy, I mean, in the midst of all this great technology I do at work and we make iphones and tablets do these great things and we work for billion dollar companies and we build you know we’re in angular and react building really high end websites scale to tens of thousands of concurrent people. When I go home I’m still just as curious and passionate about it as I was when I was 12. This Sunday morning, yesterday morning, or two days ago I guess now I got up and actually had some packages from Amazon in the mail. My wife thought they were Christmas presents for somebody so she didn’t open them. Really it was just me I ordered a seven inch touchscreen for my Raspberry Pi. And I strapped the Raspberry Pi to the back of this touchscreen and it had a RetroPie SD card and I booted a complete NES simulator and I could sit at my kitchen table with a battery and play this little rig with all these wires and my daughters are home for Christmas break from college and they’re like Dad, what are you doing. I’m there with an old retro Nintendo controller on a 7 inch screen with wires sticking out everywhere.

Kevin: And I was really proud of it. I mean I assembled it, I won’t say I built it from scratch but I put it together and I got it all running in they’re like this is what you do on your day off as you sit around and this is what you ordered from Amazon. Yes I’m just as excited about doing this today. Along those lines I was at a conference a couple of months back and we were having a discussion similar to this and the one of the fellow speakers and a friend of mine he had the great quote. We were talking about what we look for in developers and it’s that passion and curiosity just for learning about anything technology related. And he told the group he said pound for pound I always try to be the most curious guy in the room. That resonated with me.

Ron: That’s a great quote.

Kevin: That’s the team that I want that’s the team that I hire. I don’t care what you can code, I can teach you to code. I want you to really love the stuff I want to look at those old things and think why did somebody make that decision. Why was it built like that. I think that is lost somewhat. We live in a culture of big bang theory and Hollywood has all these hacker movies. You know these games. I mean, the day I got my Apple II GS. The new one just off ebay, I plug it in and got those old apps running at the same time one of my daughters had just gotten battlefront 2, the new Star Wars game. So she’s playing on a big screen battlefront 2 with all the amazing graphics and I was in awe of this game I’m like wow this really looks good.

Ron: You want to say Hey kids come over here take a look like how cool is that.

Derek: I’ve got Dr. Mario over here. Dr. Mario, come on.

Kevin: No, and I showed her magic quest with you know 40 pixels by 30 pixels and they’re big and they’re like five colors that I made when I was 12 and she was less than blown away because she’s like I need to ge t back to battlefront, you know save the empire. I think you start out as the Empire in that game. I know people always say if you could go back in time what would you show people. I’d show them video games. Could you imagine what somebody 100 years ago who would think if you showed them battlefront on the big screen? We carry this stuff around on phones.

Derek: You made a comment I think on your blog about the surreal experience of using your iPhone to photograph an old Apple computer and you have the thousand times difference in processing power in that little phone compared to your old old computer and that’s you know imagine if you pulled a smartphone out of your pocket any time before the last 10 years, I mean that would just be magic a hundred years ago be. They might lock you up for your dark arts. Kevin, I wanted to get your point of view on what different types of developers, what they need to think about and what they can do to make themselves better as in regards to understanding the history. So we get very nostalgic about all of these things and we started learning to program a long time ago.

Derek: There are kids coming into the industry today. You said you’ve got people of various ages who work for you. I’m sure you work with clients of all ages and all backgrounds. Curious your point of view on the nuggets, what are the little things that hey it’s important that even if you didn’t work, you know even if you didn’t write basic on a Commodore VIC 20. It’s important that you have these pieces of connective tissue to the past because they influence the way that you do things today.

Kevin: I mean I think curiosity and passion are probably the two biggest things if you have those I can teach you anything else. When I got started like I said the surface area was much smaller that you weren’t inundated with best practices there one way to do things in the whole industry agreed on that. Today thanks to Google, stackoverflow, Perl sites of the world you can get you know a hundred thousand different opinions on what framework… There is a new javascript library. There’s been ten of them released just since we’ve been on this call. Everybody says they’re the best and you should use them and they’re the most scalable and I think a lot of software development really just comes back to common sense trying not to be too fancy and the younger guys I’ve got working for me are some of the best pure developers I’ve ever met in my life. I’m blown away by the skills that they have and they have very little detriment to anything they do except for just lack of years of experience they haven’t had the opportunity to talk to as many customers or see as many products as we have. Sometimes it is just common sense like why should this be required and why shouldn’t this. It’s not that as developers they couldn’t make it work either way. But sometimes those forks in the road come up and you’ve got to make a decision without going back to the customer for everything. But if you’re passionate you’re reading about it you’re keeping up. I’m proud of the technologies my company uses today but they’re going to change next year.

Kevin: They’re going to change in six months. We’re going to have to learn something new and that’s just the way it is. Unfortunately regardless of your age, technology, the ball is rolling downhill faster than it ever has. So you’ve got to race to keep up. It didn’t move that fast back in the day I learned basic and C and Pascal and those were top languages for decades. Now no one ever… Now they’re relegated to the annals of history and we’ve moved on and it’s all Javascript, TypeScript, C#, Java and a whole bunch of other things. And they change frequently. If you want to you want a stable career that doesn’t change much become a math teacher. They’re still teaching pretty much the same core concepts that they have for a century or two. In terms of computers it changes so just because you’re the expert C# programmer really means little in my mind.

Kevin: I want the guy’s who’s curious.

Derek: OK we had a little bit of an audio malfunction right at the end of our conversation with Kevin there so it did cut off a little bit abruptly but it was a great conversation.

Derek: Ron, are you feeling as nostalgic as I am right now?

Ron: Oh man. I’m thinking about that old Commodore 64 and the games even when he talked about you know the sounds the computer used to make and I can picture them again. You know you put the disk in and it would do that whirr whirr whir. It was just taking me back. Oh man oh man.

Derek: Did you have disks for your Commodore 64? Or did you have a tape drive or did you have both? Do you remember?

Ron: Disks, I think.

Derek: Disks, yeah? We had VIC 20 which I think you could get a tape drive for that. Thank you one more time to Kevin. You can find him on Twitter. He’s @-k-v-g-r-o-s, @-k-v-gros, I guess you’d say that, and his website is architectnow.net. If you go to architectnow.net/blog you can find the post from November 2017 where he writes about Applesoft BASIC and the little museum that he created in his office, he’s got a bunch of pictures and screen captures of all the games that he created when he was 12 years old.

Derek: It’s pretty fun to go down memory lane there so I encourage everyone to visit architectnow.net/blog. Alright, that’s it.

Ron: Thanks Kevin.

The post #005 – Programmer Nostalgia with Kevin Grossnicklaus appeared first on Ardent Development Podcast.

Where to Find Derek Hatchard

@derekhat on Twitter

@derekhat on Medium

On the web at derekhat.com

Enjoy the show and be sure to follow Ardent Development on Twitter.

Follow @ardentdev

Transcript

Ron: Welcome to the Ardent Development podcast and today we’re going to be doing something a little different. Normally we would have a guest on the show and we would interview them and we thought that it would be interesting to our listeners to find out a little bit about the hosts. So if you caught the last episode Derek would have interviewed me and for this episode I’m going to be interviewing Derek. It’ll be a brief interview. But just to give you a sense for who are these two guys that are this Ardent Development podcast. So welcome Derek.

Derek: Thanks Ron.

Ron: So let me kick this off by just asking how you got involved with tech.

Derek: Well OK! I’m going to reference an episode that we haven’t published yet. We’re talking to Kevin Grossnicklaus and we talked about programming nostalgia in that one. You were talking in that episode you talk about your Commodore 64 and I asked him about my Commodore VIC 20 and that is actually that’s where it started. I my parents gave me a commodore VIC 20 and I had a book with some basic code in it. I coded some stuff up and I didn’t I didn’t fully understand what I was doing. I didn’t appreciate the power of what I was doing. To me I was like I created a really lame video game. When I went to high school, we had old fashioned typewriters so you took typing on a mechanical keyboard. And then we had computer skills, which was you know basic computer put some floppy drives in the load DOS and learn a little bit of Lotus 1-2-3. When I took that class, I’d gotten through all of the curriculum and so the teacher said Well why don’t you try to learn how to write some code. And so I wrote a blackjack game in Pascal. And that’s how it started. That was the first thing that I really wrote where I was creating some parts of the algorithm that I was really trying to understand what was going on. Even that though didn’t totally seal the deal for me. When I when I was picking what I was going to do after high school and you meet with the guidance counselor. I was applying to schools and one of the schools I applied to you could pick up to three faculties that you wanted to apply to. So I had applied to math or physics like physics and engineering. She said well you might as well put a third one in. Since you there’s a spot there it doesn’t hurt because you might get you know you might get accepted into one or maybe you’ll get a better scholarship offer from one. You can always switch majors later once you get there. So I put computer science in and lo and behold of all of the various acceptance letters and scholarship offers that I got the best one was from the University of New Brunswick. UNB is actually based in Fredericton where I live now. Yeah I had the best scholarship office offer was for computer science as well. I don’t really know what path I want to be on so I’ll go do computer science. I had my moments of doubt when I was in there I ended up actually doing not only a computer science degree but I did a psychology degree in undergrad and currently because I was interested in some aspects of the human computer interaction. Some of the research that was going on at the intersection of those disciplines ended up working a couple of jobs. Technically, I think I only had three jobs in my career the rest of the time I’ve been I’ve been self-employed but I’ve had a couple of jobs went back to grad school. Had this really interesting experience where I went from the consulting world where you would work on things and you had this relatively short feedback cycle in terms of you know your client would accept the work and it would go into production. Or in one case I was actually on a design project. Not sure if it actually ever went into production. I think he may have only ever just designed it. But I found a really hard when I got to grad school. Although I had sort of always fancied myself as an academic. It turns out that I wasn’t excited about the idea of doing research that I published and then waited for a decade for it to make its way into the industry. I was actually really gung-ho to see my work show up in the hands of users as early as possible. Which led me to leave school and my wife was she had her first baby and she was on maternity leave. So here in Canada we had maternity leave policy so as she was home with the baby, I had left school, and we had moved. I said Well you know what I really want to do is I want to build software products so why don’t I start a company and I’ll bootstrap it with consulting work you know start picking up consulting work. And I had so much fun during that early phase, because I was not just writing code for people that I had picked up some work writing. Writing tutorials, wrote magazine articles, I wrote slides for presentations. So basically like making sure all of the technical information was correct and like keynote talks at product launches. Coauthored a book, edited a book that actually was released under a Creative Commons license which was which is pretty fun. So did a bunch of really interesting things and didn’t actually have this really have the traditional school go get a job and write code for 10 years. I almost immediately was into all kinds of different activities surrounding the development space I lots of code during that time but I also recorded videos and recorded audio and I did a lot of writing so it was really fun for me. It’s certainly not traditional by any stretch.

Ron: So I’m remembering back to when we met 15 years I don’t know how long ago it was. I think he told me that you were the regional director for Microsoft and I thought to myself “Who is this guy like he’s just young.” You don’t hear of people having that role. And I thought: Man is this guy ever keen that he’s tied in with Microsoft. I think it’s a volunteer position but you got you got to meet some great people from Microsoft and the like. But I was struck by how young you were you know already running a consulting company Regional Director for Microsoft. You had written a book. I was like man this guy’s all in. Anyway it’s a long time ago now but you seem to accomplish more in your youth. Coming out of university than most of the peers that I would have worked with. I remember sitting back and chatting with you. And you said early in your career you were very interested in all these different types of technology so you would study them all. You were one of the guys that enjoyed the debate. Well what piece of technology should we use in this aspect. So again that was different than what most people do because you know so me included. So I went to university and studied C and I worked in C and I worked in Oracle a lot. When I when I first graduated but you had this breadth across the spectrum which was really it was really neat to see. And at a very young age so was impressive.

Derek: It’s interesting the point you just raised. The difference between people who go deep and specialize in an area and the people who go abroad and really try to learn a lot of different things. Because I think we need both. I think both are essential to a vibrant stable industry. And I’ve pretty much always been attracted to the hey go learn lots of different things and have an understanding of many different technologies. I kind of get bored if I am if I’m doing the same thing over and over again. The consulting company that I had was really focused on dot net development. During that time I was always on the sort of leading edge of what was happening. So there was a new version of dot net coming out. I was going to know that. I wanted to write articles or I want to contribute to a book on the on the latest thing that was coming out. I remember you might not remember this actually, I’m not sure. I actually burnt out the video card in my computer at the time because I was running early builds of what became, must have been Windows Vista, but it was before that name was around. And the cord for the fan on my video card wasn’t connected. So there was no power of the fan wasn’t spinning which when I was running XP it didn’t matter. But this was so it had such high GPU requirements that the card overheated and the computer fried it. Yeah that was the sort of stuff that I love. I used to I used to have to schedule downloads and I’m trying to remember what it was I feel like it might have been one of the early Visual Studio .NET releases but getting a daily or weekly builds of those. Because we are working on a slide deck likely for a product launch. But having to get the builds and download them over my DSL modem and it would take all night for the download. So yeah. Last thing I do at 9:00 at night is I would start the download on ftp and make sure that it had auto reconnect going because if it failed part way through the night and it did a lot of reconnect that was I was screwed the next day. But then you sort of get up in the morning and hope that it finished downloading overnight cause they were such big files and my internet connection was so slow back then.

Ron: So the name of the podcast has taken on the name of your old company your old boutique consulting company that were where you owned and I worked with you.

Derek: I’m glad you brought that up because we have we haven’t addressed that anywhere. There would be a handful of people not very many. There’d be a few people listening who actually would remember that Ardent Development was just a name. The word ardent means enthusiastic or passionate. And I thought it was it really reflected how you know that type of consultancy that I wanted to run and that domain and that Twitter account have just sat pretty much on used for years now. We’ll talk in a minute about what I was doing in between. I love the fact that we have resurrected that brand and are using it for something new and I feel like it really captures the spirit of doing a podcast for developers. This is for the people who are passionate and enthusiastic about the practice of building software.

Ron: So when you decided to shut down your first Ardent Development consultancy, you had an opportunity to go work for a pretty neat company in Fredericton. So can you tell us a little bit about what you’re doing there.

Derek: So there are a couple of stages to that. The first part was I had the consultancy really was started to bootstrap product development. And as happens with a lot of companies that have bootstrapped with consulting the revenue from the consulting. It is so enticing. It’s hard to ever really slice off a part of the company to find whatever product development work that you’re doing. It ends up being a distraction. We were so busy doing consulting work we just didn’t have the bandwidth internally to work on any product things. And so we’re based in Canada did a lot of work in the U.S. at the time the U.S. the Canadian dollar exchange rate was really favorable for us so we could do work in the U.S. and they worked really well when we converted into Canadian dollars. And there was a period of time when the consulting business was just drying up a little bit you know because of the economic downturn in 2008. And I kind of lost my interest in running a consulting company after coming out of a negotiation where I had had a couple of people on the team who are working for really good rates and a customer coming back and saying we know you gave them to us at a really good rate but we need to know if you can go any cheaper. At that point I was like well what’s the point in doing that? You don’t run a business to break even and you know you could do that for some period of time. And it would be great but if they come if you will come and wants to have people below cost it doesn’t make any business sense. And I had to ask myself Do I want to keep doing this? Do I want to be here in 10 years. And the answer was No. I what I had set out to do was fund a product company. So stop doing the consulting. Disbanded the consultancy and spend some time working on product things. You and I worked on some product things during that period of time and then I ended up joining a company called Radian6. Super interesting company doing social media monitoring and management. I was looking for something new. There is the opportunity to go work on some new tech that I hadn’t worked on. Had a great time building some cool new stuff and then sales force acquired the company. So you know I get swept up along the way into the world the big corporate life and really did that for about seven years. Worked as a developer as a software architect and then as a Product Owner for some of our platform features with a social business and then work in what is now called salesforce marketing cloud which is that the bigger digital marketing part of the business. Spent some time as a product owner in that space before the travel actually got to me. I decided that what was really most important to me at this stage was being around my kids. You know and sporting activities and when they were coming and going from school I just didn’t want to be away. Forty percent of the time which was what was happening just the career path that was on.

Ron: Well thank you Derek. It’s been great to reminisce with you a little bit and hopefully our listeners will have gotten a kick out of some of the stories and know who we are a little bit more than they were before they listen to this. We will have other guests on the next show. So, it’s been great. Thanks Derek.

Derek: Thanks Ron.

The post #004 – Meet the Host with Derek Hatchard appeared first on Ardent Development Podcast.

Ron also runs Managing Projects, a site dedicated to helping project managers with thought-provoking articles, interviews, and training tips.

In this episode, Derek interviews Ardent Development co-host Ron Smith about his journey in the IT industry and why he’s doing the podcast.

Where to Find Ron Smith

@manage_proj on Twitter

On the web at https://chalder.ca/ and https://managingprojects.ca/.

Enjoy the show and be sure to follow Ardent Development on Twitter.

Follow @ardentdev

Transcript

Derek: Welcome to the Ardent Development podcast. I’m Derek Hatchard. I am here with Ron Smith. This week we’re going to do something a little bit different than normal. Normally we have a guest on the show. We ask them questions and we really help to bring some of their insights and thoughts to you. This week I’m going to ask Ron a couple of questions about himself so that as you listen to him talk on the podcast, week after week, you know a little bit more about who he is and where he came from. So first of all, welcome Ron. Thanks Derek. And why don’t you just take us back. Tell us how you got started in the tech industry.

Ron: So I built software for a living for years and years. And then I had a stint where I went on some testing teams so I tested some software and became a test lead and went that route. Then I started leading these development teams. What I realized was that I was a pretty good developer but I was really good at leading teams leading people. And I found that I was one of those guys that wanted to work with the teams to help the teams to grow and evolve them. So, I got into this I.T. technical project management. Started mentoring some other project managers as well. So that’s really where my sweet spot is. I’m one of those project managers that really enjoys hanging out with the developers and the architecture groups. I don’t code per se anymore but I’ve got that background that lets me stay in the conversation and I get some really neat projects because of it.

Derek: And you and I met we were talking about this just the other day you and I met maybe 16 or 17 years ago. We were both living in Moncton New Brunswick. I had started a consulting company. We ended up working together for a number of years. We bought a rental property together. We’ve done we’ve done a number of things. You really helped to keep the keep things moving in the right direction for the for the consulting company. You know as it grew you know it wasn’t a massive company but you know once you’re in more than a couple of people it definitely gets harder to get to keep everything pointed in the right direction. After that, we we worked on a number of projects together. Do want to give your point of view your perspective on some of the things that we worked on.

Ron: Well one of the things that comes to mind is we had our hand at a little startup that we bootstrapped on Tuesday evenings. We were both working and we decided to set aside Tuesday evenings one night a week. So we would collaborate on Tuesday evenings. We actually produced two products. You had a third product that you had kind of brought into the fold. That’s what we were doing we were determining where to host it. We were getting some administrative help. It was basically a two-man shop. It was brainstorming what requirements the product should have that was building it testing it. If you took two guys and turned them into their little mini I.T. shop that’s basically what we did. Some people go to university and they put money down to learn and to have these experiences and that was time well spent to go through that and to learn some of those lessons that you get as an entrepreneur to attempt to launch some of these products. It was invaluable.

Derek: One of the things that I remember and I won’t say any names on the on the show here but I do remember with one of the things that we are working on. You had made a sale. I’m a terrible salesperson. It’s not my forte at all but we had created this product they had a framework and I’m looking at it going like well there’s so much more to do. We really have to finish the product we haven’t hit MVP. And meanwhile you went out and you made a sale and it just it just blew my mind. That’s amazing. He gets someone to write a check to buy the product. It was pretty cool. That particular product – I guess I’m being very mysterious as we talk about it yeah. If we had it if we hadn’t shuttered that one seven years ago it would be very interesting to see where that would have gone. You’ve been self-employed for a fairly large percentage of your career now. Can you talk a little bit about what that journey has been like for you.

Ron: You’re really business development and your marketing and you are the one who has to get the work done. So it’s quite fulfilling. It’s been really good. It’s certainly not for everybody. You need to have a certain risk tolerance and you need to have a certain network to be able to hear of projects and the like that are happening. But I’ve really enjoyed it.

Derek: Be interesting to hear from some of our listeners about their experiences if you’re self-employed or working in a large company. How you especially folks have done both. Love to hear some of that compare and contrast if you want to go on Twitter or e-mail us. Really interested to hear your stories.

Ron: You know you can get that type of sense if you’re self-employed but you can also get it in a small shop as well I can remember when I first went to work for you. Years and years ago I went from a very large company. There were so many tasks that had to be done and there were people that would do all these things and I remember coming in to you and saying well we need to set up a new sequel server instance and the computers aren’t racked yet. And I said who might do that. And you said why don’t you. It was it was a very you know so when you’re when you’re working for these really small companies there’s not a ton of people to go around and you get a chance to touch so many different aspects of it. You basically handed me the book said the desks are over there and said it is not too bad! So you’re learning really goes through the roof. I’ll tell you a funny story I remember our interview me sitting down with you. And you said So do you do any blogging. And I look to you back in the day and I said what what’s a blog? Everybody’s got to start somewhere right? Anyway, now we fast forward and you learn so many experiences working for these these small companies that your breadth of knowledge. You have to be deep in in what you’re willing to learn and put your shoulder into and it’s very similar when you when you’re self-employed.

Derek: So let’s talk about the podcast for a second. Why the Ardent Development podcast? Why are you doing this?

Ron: Why would I do such a thing? So I’m one of those lifelong learners and I really love to learn. I love to meet people who are doing interesting things and the I.T. industry has the spectrum of the monotonous day to day show up every day get your work done. But there’s this other end of the spectrum happening on the other end that is really interesting people doing interesting things being treated very well by companies and lots of opportunity. And in your career, you can find yourself depending on where you’re working and what opportunities you have falling somewhere within that spectrum. I have really enjoyed teaching. I’ve always been the person who wanted to pass that information along to my peers and it just seems like a natural fit. You see things and you learn things about how corporations work or how I.T. works or what have you and you want to pass it along. And this is a really good way to do that. It’s really quite fun like the people that were we were interviewing last week. You know I laughed out loud several times during the interview because of how creative they are. So that’s my why.

Derek: In addition to the Ardent Development podcast you have the site ManagingProjects.ca. I would encourage folks to check that out as well. You have the Managing Projects podcast feed as well which is on iTunes. And you can listen to those on your site. Also some interesting interviews on there. There’s also a free e-book you have posted can you remind me the name of it?

Ron: Yeah, it’s called rockstar estimating guide.

Derek: Thank you. And that’s really great. Folks should go and grab that it’s free and has some great information about just getting better at estimating which is something that you’ve written about and spoken about over the years. Years ago, at the maritime devcon conference here in Canada you had given a session on that and it’s been one of your pet topics. That and projects at risk which I think. Yes, and as I said you’re insane for being passionate about that and you seem to love projects that are in need of intervention.

Ron: Yeah. The trouble Project Recovery. I kind of fell into that over my career because you’d see these projects that were there were going sideways on a company and you just want to help. And I tried my hand at it. I was lucky enough to work for a company that gave me the opportunity to try it years ago. And I tell you I’m hooked. I don’t know what’s the matter with me but I get jazzed up like the harder the project it seems the more fun it can be. Now when you go into these projects everyone stressed out and everything else that comes with it. So for me it’s the restoration. You take a project, or a project team, or this client conflict and you’re able to resolve it. There’s a lot of emotional good that comes. How can I help I’ll go in and let’s make this better as quick as we can for whatever reason I’m just wired. I seem to think they’re fun. I don’t know what it is.

Derek: If anyone wants to get a hold of you Ron, other than the ardent development e-mail address and the ardent development Twitter feed. Where else can people find you online?

Ron: Well I’ve got a Web site for my company. It’s chalder.ca. That is my Chalder Consulting Web page. You can reach me at ron at chalder.ca and on the managing projects Twitter account which is Manage_Proj on Twitter.

Derek: OK. We will put that in the show notes as well so folks can check that out. They can click through to those sites and find you. I hope that everyone found this little peek behind the curtain interesting and we will see you next time.

The post #003 – Meet the Host with Ron Smith appeared first on Ardent Development Podcast.

Where to find Andrew Burke

@ajlburke on Twitter

On the web at http://www.shindigital.com/

Andrew’s other projects include:

• http://www.beancountertech.com/
• http://www.remembary.com/
• http://www.starshipsstarthere.ca/

His “4 Weird Things About Time” talk from ConFoo Montreal is available at https://www.youtube.com/watch?v=RM3LUB_MVa4

Enjoy the show and be sure to follow Ardent Development on Twitter.

Follow @ardentdev

Transcript

Derek: Welcome to the Ardent Development I’m Derek Hatchard, here with Ron Smith. And today we are talking with Andrew Burke. Andrew has been a professional independent developer for over twenty years working in everything from HyperCard and Lotus Notes to Ruby and rouse and iOS. In addition to building software for various businesses he teaches web development, speaks at conferences and has several SaaS products and iOS apps on the side. And in his spare time, he also does fan art mashups of iconic science fiction ships and characters with iconic Nova Scotian scenery which is actually pretty cool. they are surprisingly popular. But they are fun. I think my favorite is the fisherman demanding the return of Firefly. So welcome Andrew. It’s good to have you on.

Andrew: Thanks. Good to be here.

Derek: Today we’re talking about weird things about time and this is something that you’ve been basically on the conference circuit. I guess it was 2015, you did that talk. An insanely popular talk a lot of people still tell me how much they enjoyed that talk. You have done it in Montreal, Vancouver and I don’t know where else. Talking about time has me thinking we are recording this in December which starts with the DEC which to me means 10 but December is the 12th month of the year. So what the heck is up with that?

Andrew: Yeah that’s the first weird thing about time I talk about in the talk. Anybody who’s a programmer knows that the closer you look at things like times and dates the weirder and weirder it gets. And I’ve had a lot of times in my career where I get really frustrated with time and date tracking and time zones and stuff. So I started really looking into things and got really kind of got obsessed about how all these you know calendars work and where are the names for things come from and how these systems fit together. And I found they kept reminding me of stuff in software and so the first thing I talk about is if you ever notice that the last four months of the year have the wrong name. So September has a 7 in the name but it’s actually the ninth month of October and November and yet December. That’s sort of it’s a good hook to get people started in the top because everyone’s like hot never noticed that before. And what’s funny is that a lot of people figure that it’s because people put July. You know the Romans put July and August in. And you know after August you have September and that’s where the names are on because July was named after Julius Caesar. And August was named after Augustus Caesar so they named these months after these emperors and a lot of people said that was my first impression was they were just added these months and stuck him in there. But it turns out those months were actually named quintilis and sextilis before they recalled June, July and August, and it was actually it turned out half of the months of the year had the wrong names because quintilis has a five in it and sextilis still has a six. So that got me even more interested in how things fit together and eventually I discovered that it looks like a very very very early Romans just didn’t bother counting the first part of the year. So they basically started in March and went to December and they only had ten months but those months were still about 30 days. The beginning of the year which is you know what we now have is January and February. They just didn’t bother because it’s muddy and gross and if you’re a farmer or a warrior there’s nothing you can do it just sort of hung out at home and waited until they could do stuff and that’s when they started labeling, labeling the months. Obviously that didn’t last very long once they got more sophisticated and the culture got bigger. But that sort of was supposedly the origin of where the month names come from is that they just didn’t bother naming a whole chunk of their year which I found kind of fascinating.

Ron: Still kind of feels that way in January and February right.

Andrew: Exactly. I mean I sort of thought about having, like in the Maritimes we could have, we could have a sort of a everything from January until maybe About April we could just have this month called you know, terrible. Or something, or you know we just, yeah why bother counting the time until like you know when it’s a snow and like mud and rain and you know and you know there’s some of those times a year and so you get the same thing there were. We still have snow on the ground in late April, and it’s kind of depressing. So yeah I was thinking about like how we name these things that reflects the world that we’re in and the context are in and and especially the developers I always think about as an engineer you sort of want to cover everything and be really really thorough, but often users don’t want to know all of the terrible stuff. So you know, if the Romans could actually skip out a whole six of the year and eventually end up taking over the known world anyway, it’s good to sort of think about maybe where you’re what what you can skip in your UI or your you know process, that would actually still make it useful for users. So that’s the kind of thing the whole talk is kind of got a lot of that kind of thing, where the weird stuff that happened in history turns out to kind of reflect on stuff we do all the time as developers. That’s kind of been one of the fun things about doing that.

Derek: Yeah. And it really is a fun task. I encourage everybody to go watch one of the YouTube recordings of it, it’s thoroughly enjoyable. So it kind of caught your interest and I know when you came to speak in New Brunswick a couple of years ago you already had a recording of the talks. Walk us through a little bit of how did this evolve from have learned a few things to, I’m going to go and really talk about weird things about a time and helped to shed some light on some of this weirdness to the rest of the developer community.

Andrew: Well I just kept, I kept finding things and there’s a bunch of things I couldn’t fit into the talk even things with like actually want to. I do have and I removed it since for time but when I have a lot of the recordings is off by one errors you know start do you start from 1 or zero that came back that went all the way back to sort of 50 B.C. which is kind of funny and all these weird sort of programmer things and so I kind of got obsessed with this myself. And then I did a sort of rough version of this talk several years ago. We have a pod camp in Halifax which is sort of an unconference. And people just sort of show up and do talks in a very early version of this talk which was kind of kind of a rough version I did there and people seemed to like that. And then when I sort of really decided I wanted to get much more into doing speaking. I’m not, I’m you know I’ve been doing a lot of programming over the years but I’m a fairly, I mostly do sort of complicated business software, trying to model messy business processes so I haven’t usually had a lot of chance to do super leading edge, bleeding edge software with the shiniest new tools because usually those are not the kinds of things you want to have, you know to run a business on. They are kind of fun the show off. But they’re hard to run a business on. So I’ve tended to do work with stuff that’s fairly stable and not very exciting often. So you know I actually do have another talk. I do, that’s about stuff it’s really cool in Ruby but it’s stuff that most people have already been doing for about a decade. So it is not leading edge, so I was trying to find a really good in to have an interesting topic that would be cool for people in conferences and this calendar thing or this no time thing sort of seemed to be a really big really good idea because for one thing it’s a stuff that a lot of people don’t know. The other thing a lot of it happened a thousand years ago. So I don’t have to keep redoing the talk every year when the technology changes.

Derek: Smart, smart.

Ron: What about writing apps for changing time zones and that kind of thing? Do you get into that very much?

Andrew: A little bit. What I try to do whenever I do the talk is I always try to find recent news items as a little bit at the end. Where at the end I usually say well you know this is all history. We don’t have any of these troubles, any of these problems anymore. Right. And then there’s always something new in the news that I find you know with either the latest one I do is like daylight savings time. Every single country and state and province in the world seems to have their own different time of doing daylight savings time and it changes all the time so every time there’s a daylight savings. Places like South Sudan, Sudan used to be one country, now it’s South Sudan and North Sudan and North Sudan is keeping daylight savings, but South Sudan isn’t. Among all the other problems they have in South Sudan. Daylight savings is one of those and constantly there’s all these adjustments have to be made. Every country has got different ones and leap year and leap seconds is another big deal. Amazon S3 had to go through a huge nightmare to figure out how to handle leap seconds because obviously if you’ve got a whole system with lots of cron jobs running in a giant data center, having an extra second suddenly show up can really mess up all of your all your delicate time-based systems. So they had to do a whole bunch of juggling to fit that kind of thing in. So there’s all that kind of stuff happens. The GPS satellites have to take into account relativity, because they’re going so fast and they’re going into a different part of the gravity, well of earth which changes their actual perception of time. And so we have to take this into account in figuring out where we are. We have to take relativity in how time it’s actually kind of elastic, just to figure out GPS. That’s you know, yeah, it’s kind of insane making. Actually when I gave it it’s when I gave the talk at Maritime DevCon, you know I sort of put this GPS thing in and talked about you know people going to Mars and while these probes it’s really difficult because it takes a long time for time to go to go through space for messages to go through space and to talk right after mine opened it just by coincidence opened with how complicated it is to communicate with satellites. and they had so I think looking at the sun from four different places in the solar system and it was really really difficult to tell when something happens at the same time because the satellites are in different places. It takes maybe 10 minutes for the messages to get to each other, and then they’re going at different speeds and for the different messages. So everything is totally synchronous. And then you have to counter for like relativity and all that kind of stuff too and it’s just completely nuts. And so it was a great follow up to my talk where he was like Yep that’s exactly what happened. It’s completely weirder than you ever thought.

Derek: All right. So let me ask. Let’s do something easy then, Andrew. OK I just I just want to put a countdown to Easter on my website. That’s easy right?

Andrew: Yeah. Well now it is because it’s all on your computer. But it took, it took several centuries for them to figure this out. And then several centuries more to actually stabilize it. Yeah because Easter is one of those things, it’s part of the problem is Easter is based on Passover roughly it’s loosely based on the Jewish festival of Passover. The Jewish calendar runs on the lunar year while the you know the Julian and Gregorian Christian calendar runs on a solar year. The cycles of those phases of the moon is an often, it’s a really common way to measure time because it’s really obvious to look up and see the moon but the cycles of the where the sun is and the seasons and the length of the days and things like that is also really popular. And the problem is those don’t fit together very well unfortunately. So it is actually if you try to track lunar months and solar year you have 12.36 lunar months in a solar year so they don’t actually fit so civilizations have to sort of pick whether they’re going to track the moon or the sun. And by putting Easter to be sort of loosely tied to Passover it’s putting a lunar festival calendar into a solar calendar and that kind of makes it a giant mess. So you end up with these, sort of the three rules for Easter. Looks like the early church ended up arguing about a lot of things and one of them was Easter, but they finally figured out a simple system which is. Easter is the first Sunday, after the first full moon, after the spring equinox. And so that’s sort of makes sense. But once again we got this really messy thing where you’ve got the equinox equinoxes a solar cycle and the full moon of the lunar cycle. They don’t fit together very well. And then you’ve got the Sunday thing which is extra arbitrary 7-day cycle on top of that. So figuring out when Easter actually is, turns out to be this huge messy calculation. And back when they were figuring this out early on this is a middle age, the dark ages even, they didn’t have they didn’t have the modern concept of decimal fractions and they mostly wrote everything by hand in Roman numerals which is terrible for doing complicated math. And so there was lots of people did these systems for figuring out when Easter is but it would take forever and a lot of them had lots of mistakes. But you wouldn’t know they had mistakes until suddenly one year Easter turns out to be on a Saturday or something like that. So it became this huge nightmare mess and all sorts of different cultures had different versions of celebrating Easter. And one of the five things I talk about in my talk is a particular king and queen in Britain, ended up the celebrated Easter at different times and it became a big headache for everybody. They finally figured it out and that actual thing they figured out for Easter turns out to be why it’s why we count this year as 2017. And it’s a long story which I’ll go into into the talk but you’ll have to watch the talk to get the details on that. But Easter is such a weird mess. It took a long time to figure it out and it sort of ties in with all sorts of weird issues of how the solar year doesn’t fit into the lunar year how the days don’t fit into the months and turns out to have all sorts of weird side effects with leap year and rounding errors and all sorts of things too.

Derek: So fascinating. There’s one more thing from your talk that I want to ask you about. And then and then I want I want to get some of your bigger picture thoughts. But this one is cool. Anyone who’s got a Mac or Linux machinery UNIX based machine can go and do this. You do, I think it’s cal 9 1752 September 1752.

Andrew: Yeah you yell out of it depending where you are if you’re in the English-speaking world probably you’ll get this depending but if you’re say in France or something you might not. But yeah, Cal 9 1752 gives you a month with three weeks in it. And that’s not actually a bug. Well it’s not a computer bug it’s not a software bug but it actually is due to a bug in how people measured time. And this is actually due to the way they had to fix the bug. But it’s a bug that took centuries to figure out and centuries more to actually fix. And in fact hasn’t been completely fixed everywhere in the world yet because it’s a very, it’s one of those annoying bugs that sort of only it accumulates after things have been running for a while because it’s basically a small rounding error that accumulates and then it took centuries for people to find it. And then once they found it took a lot of time to actually implement a solution that would get everyone on board and it became a big headache. Basically it’s that when they set up leap year, which was a great idea because calendars before then especially in the Roman Empire used to be adjusted on an ad hoc basis you have months following the moon but then didn’t have some extra days in the year because the most totally match and they’d sort of let those accumulate and then add an extra month. And the problem with that, is that, that was decided mainly by politicians. And what could possibly go wrong? And it was sort of a bad luck thing to have this extra month soaring in so when they set up, when Julius Caesar set up the elite, the modern Julian calendar. It was self-correcting it had a leap year to have an extra day you’d get to February and then it would just self correct all the time. But the problem is the month turns out to be the year. It’s 365.2425 and change days. So you end up losing about a day every century. Even if you’re doing the leap year. So after a few hundred years the dates are kind of out of sync from the equinox by you know about a week and you know when you’re trying to figure out Easter based on when the Equinox is, this can really mess up all your calculations and it took centuries and centuries to figure it out. And Catholic Europe set it up in 1563 and adjusted their calendars around then by removing ten days from the year but Protestant Europe, by that point Europe had split into Protestant Catholics or the Protestants weren’t going to go with this like Catholic thing. And so this became this big headache if you left France and arrived in England. You ended up arriving in the past. It’s just kind of crazy making because France had adjusted the calendar but England hadn’t because they didn’t want to do it some were some Catholic thing. So all sorts of crazy this kind of thing that makes historians totally nuts because you can’t tell when something actually happened because you know things you know everybody has a different date system. And I almost did a whole of it talk about how all the different countries tried to solve this themselves because it’s basically debugging but it’s debugging done by kings and emperors and popes and stuff and you know and these are people who are not usually used to dealing with the kinds of things we have to deal with when we debug. So how do you find the problem how do you fix the problem? How do you get people to accept the problem? Part of the thing is it became really political obviously because it was about Easter and Popes and stuff like that. And England finally you know, a century later than, a century or so two centuries almost after Catholic Europe switched England finally switch in September 1752 and to adjust they had to remove 11 days from the month. So September 1752 was the adjustment. And that’s why when you look at it, it’s Tuesday the first, Wednesday the second and Thursday the 14th. And that caused a lot of headaches for everybody. It’s fine now but for that year was actually kind of tumultuous because there’s supposedly riots in the streets with people demanding their 11 days back. And I think they remember they had to do a complicated thing for things like a for if to paying rent or you are doing something by the month. Suddenly you’re paying a lot more rent because it was only a three week month and you still have to pay your full month of rent or something like that. So for the rest of the year they had to do two different versions of tracking time for like the month and the old monthly cycle that’s a full month long and the one by the calendar cycle, it was a big headache. But once again these are all debugging issues in a certain way. And it’s weird to see parliamentarians trying to figure out how to debug had to debug something.

Derek: As much as I like to think that we are evolved as a civilization. I can’t help but think if we did that today, it’d be riots in the streets. Yeah Andrew tell me you’ve got in the talk that you gave you have a number of lessons and takeaways that really software professionals can glean from these weird things about time and some of the history about how our calendars work. Can use recap for a few of those things? What are some of the lessons and takeaways that you think are important from the modern software professional from all this historical baggage that we carry around with time?

Andrew: Yeah I mean the big one about the whole Easter the whole removing days from the year to get the adjust for this rounding error, technology ends up being cultural in many ways. They figured out that there was a problem sometime in like the 12th or 13th century, even earlier possibly, but they only finally got a fix in several centuries later. But it then took centuries more for everyone to roll in. In fact still the, Eastern Orthodox churches the Greek and Russian Orthodox churches still haven’t switched over to the Gregorian calendar. They still use the Julian calendar which is why Greek a and Russian Easter is actually a week and a half later than a Protestant Catholic Easter and Christmas. It’s kind of weird. Anyway, the issue is this is much more about culture than it is about technology per se. And I think we see a lot of that these days with say Twitter and Facebook, you know they think they’re all engineers. Google as well YouTube they’re engineers they want to solve a technical problem. But these technical problems and of having all these huge cultural echoes across everywhere where you know- we want to have a news feed, and then it turns out that news feed ends up being full of fake news that ends up disrupting civil society with all sorts of things and you put things on Twitter and you change the way Twitter works and suddenly there’s all sorts of extra echoes that come across because the problems are cultural and political and sometimes religious.

Those turned out to be much more difficult problems to fix than simply changing how many characters there are in the field or something like that. Also I’ve always been a fan of history and one thing you know I often say the military history but the problem is military history is kind of extra depressing because you know it’s big projects, it’s big project management, it’s how to deal with disasters but it ends up being having, you know, a lot of people die and suffer and it’s terrible. But this one with calendars was just sort of a nice sweep of the history that didn’t necessarily involve explosions and machine guns and stuff but I did like you. Every time you study history you see these sort of echoes. Everybody’s dealing with giant fiascos you know every large project at the end of the day is kind of a fiasco. And especially as a developer who works mostly on my own I always figured oh my gosh I’m the only one ever having these problems. You know I’m the only person who’s ever had a bug that had a big software project that’s gone live. And of course reading history and reading other postmortems of other projects I realized now that’s what everyone deals with. And I think reading history and looking at history really helps you realize that you’re not alone. Everyone’s had to deal with weird stuff like this for centuries, to be honest. You know one of the other things that keeps coming up is because calendars and time systems are inherently messy. They don’t round to nice round numbers. I wish they did, but they don’t. We constantly have to sort of use things that aren’t quite precise to be usable. The last bit in the talk is actually about sort of time zones in Greenwich Mean Time and there was a lot of pushback when they instituted and standardized Greenwich Mean Time in the UK, for example, because a lot of places it’s easy to tell when it’s noon by just looking at the sun and where the shadows are. And even in a place the size of the UK, noon can be up to 10 minutes, 12 minutes away from the Greenwich Meantime noon and people get really upset that you know you’re reinforcing centralized noon from you know, London. And you know we have our own noon here. So in fact through the 19th century there’s clocks that actually had to two sets of minute hands so you could keep track of you know when it’s noon here when it’s official noon. This cornerstone of our entire civilization, time zones and Greenwich Mean Time that we used to coordinate all of our systems all around the world is actually wrong almost everywhere. It’s actually incorrect it’s not actually you know it’s not actually noon in most parts of the world but it says that it’s noon because you’re always off by whatever from the central part of Greenwich Mean Time. So it’s actually the time is never correct, almost ever, except unless you’re in a tiny tiny piece of the world. You think that the foundations that everything you build is super solid but it turns out nothing’s actually. The closer you look the weirder it gets and the more inconsistent and strange it turns out everything is based on.

Ron: I can picture you Andrew talking to someone who just ran a Y2K project.

Andrew: Exactly.

Ron: I’m telling you, you know there’s these two digits were missing. And you’re looking at them thinking, you have no idea.

Andrew: And in fact one of the other things I bring up is that you know it’s the negativity whether it happened or not is not something I go into but the general consensus was it actually happened at six B.C. not zero. So it actually should be 2023 right now and that’s mostly due to rounding calculations. A convenient reference state that people could use to better figure out calculations. But yeah. So even the year the actual year that it is, is wrong.

Derek: So it’s all a mess. We don’t know what year it is. We don’t even know what time it is.

Andrew: We don’t know when Easter is. Yeah exactly. Well the thing is the point of the weird thing of the intro for the last read thing about time zones is that at Oxford you’re allowed to be five minutes and two seconds late for class or any meeting at Oxford because Oxford is five minutes and two seconds off from Greenwich Time. So you’re allowed to be you’re allowed to get to Oxford Oxford. Time is like our time here not Greenwich Time because they’re sort of passive aggressively sort of you know cranky about the fact that London got to know Greenwich got to be the official time. Of course, Oxford that’s where all the smart people are. They should have the official time. So you’re allowed to be late for class in Oxford. So yeah maybe tell them in your time zone you’re allowed to come home late but not in our times.

Derek: This is all just awesome. I find this so fun to talk about. We are at the end of our time however. I would encourage everybody to have an extra five minutes and two seconds and two seconds. I want to encourage everybody go to youtube search for four weird things about time you find a copy of Andrew’s talk there. Watch the whole talk, it’s great. I think I’ve watched it three times actually if I can be totally open and transparent with everybody. But before we let you go, Andrew. Can you can you tell everyone where they can find you online?

Andrew: My big thing, I do a lot on Twitter so I’m Ajlburke. on twitter that also goes for Instagram. You get sent back to Twitter anyway. I have a Website for my business which is in shindigital.com. If you want to look at fun photoshop pictures of spaceships in Nova Scotia you can go to starshipstarthere.ca that’s starships start here, All one word, dot ca. That’s a lot of fun and that’s probably the best ways to get hold of me. Twitter is where most of the action is and you can follow some links from a Twitter profile there as well.

Derek: OK great. We will put links to all of those things in the show notes so people can find you there as well. Thank you for your time today, Andrew. This was super super fun! Really really great talking to you.

Thanks. It was great talking.

The post #002 – Weird Things About Time with Andrew Burke appeared first on Ardent Development Podcast.

Mentioned in this episode:

• Dreaming Big Being Bold 2: Inspiring Stories from Trailblazers, Visionaries and Change Makers
• Michael Hyatt
• Patrick Lencioni
• Liz Wiseman

Enjoy the show and be sure to follow Ardent Development on Twitter.

Follow @ardentdev

Transcript

Derek: Today on the Ardent Development Podcast, we are speaking with Mike Hayes. Mike is a certified coach, teacher, and speaker with the John Maxwell Team and the president of Changing Leaf, a leadership development company dedicated to developing better leaders. He’s also the co-author of volume 2 of the book Dreaming Big and Being Bold: Inspiring Stories from Trailblazers, Visionaries, and Change Makers. Recently, Ron sat down with Mike to interview him for his ManagingProjects.ca website and we thought that Mike would be an ideal first guest for the Ardent Development Podcast. And with that, I’ll turn it over to you, Ron.

Ron: Welcome, everybody. This is the first episode of the Ardent Development Podcast. We have Mike Hayes from Changing Leaf from Moncton, New Brunswick. So, welcome, Mike.

Mike Hayes: Thanks for having me. Good to hear you guys.

Ron: Good to hear you.

Derek: Welcome, Mike.

Mike Hayes: Thank you.

Ron: So, listen, we were chatting last week about this whole concept of you’re working with people who are going through a transition, coaching them, and they’re in a new role and we had talked a little bit about what you would say to them, how you would coach them, and after this conversation I started thinking well what about those people who are in a role and they’re just passed up for these opportunities.

Ron: They can’t figure out why. Can you unlock that mystery to some degree of, cause you see this. You see this with people that say why does Billy get this promotion. You know I’m working hard. In fact in some cases I may think I’m working harder. I don’t get it. Can you unlock that for us for a little bit.

Mike Hayes: Yeah it’s a fantastic question and it’s one that I think many people and different organizations are struggling with right. Like how do I know I make that leap from the position I currently have to go up to the next rung of a ladder.

Mike Hayes: And I guess I’ll just speak from my personal experience working in a larger organization for over 20 years. I was that person who was moving up in the organization and having the opportunity to contribute at higher levels. And I was doing that while my peers were observing this happening and I remember them asking me like how come you’re getting selected to go and be part of these initiatives.

Mike Hayes: And I’m like, well, one of the things that I’m doing is taking control of my own development. I’m not waiting for the organization to say well here’s how we plan to develop you and here’s a training session that you can attend. I didn’t wait for any of that. I started reading books on leadership I started attending conferences I started to watch TED talks and what I was learning I was sharing and bringing that into conversations with leaders and organizations and they could see that I was bringing more value to the conversation. And I think that was part of the reason why I was able to have the opportunities that I had is because it took control of my own my own development and I think…

Ron: You didn’t worry about you didn’t worry about you know who’s going to pay for my books. Who’s going to pay for my subscription to. You know you just did it.

Mike Hayes: Yeah. Yeah absolutely because I saw the value in it. I am also like a lifelong learner. I have a what I call an AOL which is an attitude of a learner. And when you have the attitude of a learner you can just gain so much knowledge from from everybody that’s around you. I think sometimes when people look at opportunities to learn they think well that only happens if I go to a classroom that only happens if I attend a webinar. And those are great great things to go to. By all means. But sometimes they’re not the most convenient for people and there’s learning opportunities in books and you can select mentors that are famous people and learn from them like John Maxwell and Patrick Lencioni and Liz Wiseman like these people are available for us to learn from. But the question becomes Will you invest in yourself and add more value to yourself so that you can add more value to the organizations and the people that you’re you’re working and leading in. And if the answer is yes then I think people are going to make that leap because they’re taking the initiative themselves.

Ron: So what I’m wondering is what stops people though from from doing that because there’s you know like when I was younger I think I had that view I had that I had I had the sense of I should go to my manager and I and you know I was interested in Oracle certification one time and I went to my manager and I said you know what I’ll do all this study I’ll do all I’m really interested in this field there’s a DBA who is willing to mentor me.

Ron: Would you pay for my books or would you pay for a test. When I go to write it and you know the manager said Write me a business case. Why that’s important. And I mean I thought oh my. And so that hit a bit of a brick wall or I felt that, I never wrote a business case. I just went and bought the book.

Ron: And you know I’ve never got certified in Oracle but it was it was early in my career and I think that was one of those moments when I said like you phrased it very well are you going to take control of your own destiny to some degree and not not let the answer be a no because your manager said Oh we don’t have budget for that this term.

Mike Hayes: You know what no stands for, eh, Ron? It’s an acronym N-O stands for next opportunity. OK. So when you get a No it just means OK well you know the next opportunity I’ve got to find another way around this. It is when people experience a barrier or an obstacle, you have a choice there you either accept it and stay where you are and do nothing or you find a way through it, over it, under it, around it. But if you really want what’s on the other side of that barrier you’re going to find a way.

Mike Hayes: I often tell people as well that you know if what you are facing and what you’re dealing with in your organization is not more complicated than space travel then there must be a solution there just has to be right because we’ve figured out how to do space travel. So if it’s not more complicated than that then we just need to find we know there’s a solution we just haven’t discovered it yet. But you asked the question like why what prevents people from making that leap. I think you asked that question. And you know one of the things I think is people make assumptions about their growth and one of the assumptions I think they make is that they assume that they’re automatically going to grow. Because I’m working in an organization, I’m gaining experience. I’m automatically going to experience growth as a result of that and sometimes that’s true.

Mike Hayes: If you have the right leader above you that is putting you in positions to work on projects where you can experience growth and use your strengths and in new ways. But if you don’t have that leadership above you that’s positioning you for growth, growth is not automatic. People don’t automatically get better.

Mike Hayes: They get better with great intentionality.

Ron: Sometimes they get stagnant. Like I talked to a recruiter friend of mine one time and so my background is I.T. so we were talking about computer languages and how much experience of this and that you have.

Ron: And they had made a comment to me Well if you’ve been working in the mainframe field for 20 years OK I’ll put four down I’ll put four down at four years experience and use a little bit tongue in cheek. Of course the people with 20 years experience of mainframe they should know it in and out.

Ron: But their point was that you know after that four year mark of working on a technology stack you’ve done most of your learning by then and then after that you’re just getting better at it. But your learning slows down you know. So do your growth opportunities and that kind of thing.

Ron: But I wonder, Mike, so break this out. So I started the session with saying how come Billy or Sally or Jane on my team seem to be recognized by my manager and what am I missing? You know speaking about…

Ron: So take the analogy or the example that I’m getting passed up. I’m still working hard. I’m solving just as many technical hurdles. What am I missing, as a developer? Talk to us about that a little bit.

Mike Hayes: Yeah. Well as a developer you’re you’re what I’m going to refer to as an individual contributor. And so in organizations we have all kinds of people who work on teams that don’t have people reporting to them but they’re doing a job they’re doing a function and they’re contributing individually at a high level. They’re they’re high performers and we can count on them to deliver quality work time in and time out. So these are these are great people and organizations need these strong individual contributors to get the work done. But when you when you’re making the leap to say a supervisor position or lead hand or a management position then you have people reporting to you the skill set is entirely different and simply because you’ve been a rock star as an individual contributor in your role for several years it doesn’t necessarily mean that you’re actually going to be able to inspire people and you’re going to be able to engage people and you’re going to be able to resolve conflict with people. The skill sets are entirely different. One of the skills that that I think people need as they are moving into that management role and they’re going to be dealing with you know the many different people many different personalities.

Mike Hayes: The school I would recommend people investigate and develop an emotional intelligence you know emotional intelligence is a set of emotional social skills that not only increase your awareness of who you are as a leader but it also increases your knowledge and ability to express yourself in productive ways that makes you a collaborative thinking partner with people and it gives you the ability to develop meaningful trusting relationships so that as you’re working with people you’re making decisions you trying to solve solve problems. You’re able to do that in a way that manages your stress manages the stress of the group and the team and you’re going to be able to achieve great work and get it get great results because of your ability to work with people. But in absence of that skill set of engaging people and building trusting relationships if you solely rely on your track record as an individual contributor you’re not going to make it you’re just you’re not going to do it.

Ron: So I can picture kind of a grid then. And I think I agree with what you’re saying so. So let’s take the scenario. I’m a manager and I’ve got a whole bunch of people that report to me they’re all technical They’re all part of a technical team and it’s pretty easy to measure throughput. It’s pretty easy to measure technical competency but so if you’re going to fill in the rest of the matrix though in in them determining who is it that as a manager I want to promote into a role of leadership.

Ron: I would look beyond that. In fact so much so I think that you know if you didn’t have some of these things on the EI spectrum, that you may you may be passed up.

Ron: Can you break out a couple of those that that that might relate to that in the example that I gave a developer who’s… they’re very very technical but then perhaps an example or talk about that a little bit to say OK I’ve got a manager that I don’t really feel like I’m connecting with yet I can sense that or that managers connecting with other people in the team more what are the steps if someone goes through to try in to try and bridge that gap. Because it’s not it’s not intuitive to a lot of the folks especially in my field.

Mike Hayes: Yeah it is a great question and one of the scenarios I’m thinking of and I’ve worked with a lot of clients who are in this position where on a Friday they were peers with their group. But then on Monday they step into their promotion for the first time and now they are managing the people that they had worked with. And you know it’s the dynamic shifts right. So it’s really funny because some of the some of the peers they worked with are really graceful about it and they they want to support that person in that role and maybe they have good relational history with with each other. So it makes the transition easier. There’s some people on the team that are peers that were going for the position as well and they’re kind of like you know it should be me that’s in that role so that’s a different dynamic to manage. But if we focus on the on the the individual contributor who’s now a manager on that Monday for the first time right. I think the secret to success is to come at that with some great humility. You know, your day one as a manager, you’re there to learn. You’re there to develop. You’re there to make things better for the people that you depend on to get the work done.

Ron: Somewhat of a somewhat of a servant’s heart for the for the team to try and help them with their job and to get things for the team when they need them as opposed to an elevated authority.

Mike Hayes: Yeah yeah. You what you’re not there to do is to bark orders and to tell people what to do. I mean you do need to give direction for sure you needed to set direction clearly and you need to ensure that you’re making assignments and delegating the work in a way that is utilizing people strengths and resources but you’re also there to encourage you’re there to provide coaching feedback. You’re there to listen and understand you’re there to connect with people. OK. And by connecting what I mean is that you’re there to build trust with them by following through on your commitments. You’re there to care for people you know to to care about the challenges that they’re experiencing and you’re also there to offer your help and assistance. I think one of the things that a person in a management or leadership role needs to do with this need ask themselves two questions. How can I help you? What are your priorities and how can I help you?

Mike Hayes: And if you did those two things on day one you walked in your position you said Help me understand where your priorities are and how can I help you. You would go a long way to connecting with people and getting things done through people.

Derek: Now one of the functions that I know I’ve seen a lot in developers promoted to manager is because they were so good at their last job they were a high performing IC, individual contributor, and they’re now a manager. And then when it starts going wrong or when there’s a tight deadline or you know production is down they are in there and they’re fixing it and they’re saying no one can do it as fast as I can. I can do it as well as me and they don’t coach and mentor their team and they don’t pay that, take that investment, don’t take time to invest in the people around them to make them all better and may end up burning themselves out. And then being a terrible manager. Their teams are miserable and their teams don’t know where they should go or what they’re supposed to do as they sort of pick up the easy work and then when the when the hard work comes around the boss takes it and then they feel demoralized.

Mike Hayes: Yeah without question. And if it perpetuates you create this dependent relationship and you’re absolutely right Derek. The rest of the workforce looks and goes well, I’m not going to I don’t have to do this hard task here because I know that you know my boss is just going to come along and take it away from me anyway so I just let them have it from the start. So that if you really want to create is an interdependent relationship where you know everybody that’s working on the work says I really need my manager for support. And then the manager is looking at the team saying I really need your team. I really need this team to perform because this team makes me a better leader and how we all work together is by me providing the space for you to to to make mistakes to not do it as well as I do the first time you know and that’s where that humility comes in again to be able to just be OK with it not being done the way that you’ve always done it and to give people that opportunity to learn and to do it their way up with their own style and approach to get to the result. But it takes time.

Derek: I think that I think that is such an important point. I have a friend who does he is a phenomenal manager and one of the things that he does is he finds the best people he puts into the into a role and he lets them do things their way. So he he still oversees of course but he does not expect his his team to do things exactly the way that he would do them and it makes him such an effective leader and it makes the people on this team feel so empowered. I mean I found it really inspiring to watch. I think that’s such an important point and I don’t know if that comes naturally to a lot of new managers.

Mike Hayes: I don’t think it does. I think the tendency is to say I think they feel the pressure to perform. And as a result of feeling that pressure to perform they they quickly slip into oh we got to be perfect. I’ve got to prove myself I’m in this new role so I gotta deliver results and if I don’t deliver results quickly and in an almost perfect way then I’m going to be you know I’m going to be in trouble here. So there’s a tension there of allowing people to do it their way while they’re learning and maybe sacrificing a little bit of time as they as they learn. And that tension between trying to build the trust and get things done. Yeah it’s it’s a it’s a little bit like a dance I guess you could say.

Derek: Mike, lot of the things that you’re talking about would really connect back to emotional intelligence. One of the things that’s what one of the one of the challenges in the software industry is that a lot of people are attracted to I’m going to sit at my computer and do my solitary task for hours on end. The computer doesn’t really require a lot of emotional intelligence in order for you to be successful.

Mike Hayes: Sure.

Derek: And then as soon as you start working with a bunch of humans it becomes critically important. And so it’s maybe not on the radar of a lot of individual contributors who are whether they’re developers or testers or in some cases even product managers because they know they have specific deliverables that they are creating as opposed to people that they are nurturing and growing. And I know that you do emotional intelligence coaching when you when you do that and you get people people who are you know stepping into or have just recently stepped in management type of roles. What are some of the big revelations that people see I’m really curious like what are the what are the lightbulb moments that really stand out to you when you deal with people.

Mike Hayes: Well I think there’s a couple of things with the emotional intelligence assessments I do one of them is like the first level of assessment is a self assessment. And it’s it’s that leader you know being honest with themselves and looking at who they are so that they can elevate their awareness on their strengths and their areas of development. So there is a self-assessment component but there’s also a 360 component to the assessments that I do where people can select multiple raters from the people that they work with their peers to their team to their manager above them, their friends and family as well. And that’s where we get some really interesting data because a person might rate themselves as being you know really really strong in empathy. And then you have this group of multi raters that will say you know what you’re not overly empathetic especially when I’m like are approaching a deadline or something like that right. So we see the gap we clearly see the gap in the results. And then I think that surprises people with that gap. But what’s really interesting Derek is what happens then is what does that person do with that information. And I can really tell quickly how the person is going to be successful or not based on their response or reaction to that. And the leaders who are secure in themselves and they’re humble with it and go wow you know I didn’t realize that’s how I was showing up in conversations with people at work. I didn’t realize that’s how I was showing up in my family.

Mike Hayes: I want to change this I want to do something about that. The people take that opportunity and humbly accept the challenge to grow are the ones who are going to be successful. The insecure leaders though they get defensive and they try to justify it. Like no way I’m not like this at all. You know what I mean they have these blindspots and I’m like oh boy you’re in for a long road, man.

Mike Hayes: You know the people are not making this stuff up.

Mike Hayes: That multi rater group that you selected, they didn’t all get together on a conference call or in a meeting and say we’re going to really sabotage this person. No this is how you’re showing up and this is how people perceive you. If you want to grow and you want to succeed you’ve got to pay attention to that feedback and do something with it.

Mike Hayes: Yeah. Absolutely.

Ron: I’ve got I’ve got a question for you here. There’s been a topic and I think this does relate to emotional intelligence.

Ron: Connect the dots for me if it does what I’m envisioning you know who should be put into a leadership role. This whole concept of staying calm comes into play for me. Is this like when when that the wheels are falling off on a project deadline something urgent is happening. This whole concept of staying calm so you see some managers that literally you know they they might think it’s their job to walk around and yell at people until the problem gets resolved. So there’s this term that I’ve come across a lot of clients will say this.

Ron: You know I want to see a sense of urgency but I think what gets mixed up at times is that gets translated to the team thinks that people should be panicking. They should be standing on a table yelling. And so I’ve seen this in lots of different occasions. But my sense is that you know you want people in those leadership roles that can stay calm they can do things quickly urgently. But this whole panic this whole panic and I often think, I see this in the development region a fair amount, is the people are just getting mad and they’re saying I can do this and shove aside. But I but I have a very difficult time saying that they are someone that’s actually going to get promoted into leadership and I wonder do you have any experience with that stuff or can you connect that with EI.

Mike Hayes: There’s definitely a concrete connection to EI for sure one of the components of the model deals completely with stress management. And there’s a component called stress tolerance. So it’s really the individual’s ability to perform in challenging circumstances in circumstances where there’s things that are unknown as well, too. So how does a person rise to the occasion and still get the work done in absence of critical information that’s needed or in a time sensitive situation right. How do they deal with those changing priorities. Because as projects are being managed and dealt with there’s changing priorities that take place and there’s deadlines to meet and there’s a lot of stress that comes with that. So when when a leader is practicing emotional intelligence and they have a high level of stress tolerance and have the ability to just be calm.

Mike Hayes: What that does for the team is that it sets the tone and the pace for the team to perform and they look to the leader and they go OK well my leaders not freaking out here. I shouldn’t be freaking out either.

Mike Hayes: They take their cues from the leader but I also think as well, too, think of a word like a hope as well, too. I think in times of and challenging times of stress and challenging times of uncertainty, people are looking to the leader for hope that we’re going to be OK for the future and that’s where this other component of the most intelligence comes in which is called optimism. That whole ability to remain hopeful and resilient despite setbacks some that we might be experiencing. And it’s it’s that whole ability to create this environment that you know it is challenging right now but we’re going to be OK. And I want to really make it clear for the listeners as well too that I’m not talking about like a Pollyanna kind of you know optimism that is just like we’re going to be really cheerful all the time. I think the really great leaders also will come alongside their their people and recognize the struggle they’ll acknowledge it and they’ll say…

Ron: It’s not false hope just to get someone feeling better about their day.

Mike Hayes: You’re absolutely right. And you can there’s a way to speak to people that you’re still calm but you acknowledge and recognize that there’s a struggle right now and you do it in an authentic way. But you also offer that hopeful message that this is how we’re going to get through this. And things are going to be better tomorrow right.

Ron: You’re reminding me. So this is an interesting conversation because you’re now bringing me to a point of I’m now picturing different managers that I’ve had and which ones I’m trying to relate what you’re saying with what qualities that these leaders had. And I tell you my favorite manager I’ve ever had a Newfoundlander. We had a guy from Newfoundland who I absolutely related to. And he would make me laugh almost every time I talked to him. And we I would say battled through some of the most difficult projects of my career. And you know what I’d sit down with him and we would put the facts on the table we develop a plan and we’d play the plan. And at one point I remember talking to him and he had said to me he said Ron this is this really hard stuff, eh, but it’s kind of fun in a weird sick twisted kind of way and he jokingly said that and you know there’s there’s this yeah.

Ron: You want to you want to go back into the ring you know with a comment like that. You don’t feel deflated at all. You know you feel like your manager’s got your back. They’re realizing what you’re doing is difficult but they’re somehow turning it into this challenging fun environment that you wouldn’t want to be anywhere else. It’s really quite neat but I’m only really resonating with you know my Newfoundland manager that I love to work with him again someday but those are the types of feelings that come out for me when I’m listening to you about this emotional intelligence connection for management and who might grow into those roles. That’s what I’m picturing.

Mike Hayes: Yeah. No exactly and I I can relate to what you just said too because I I’ve had managers and leaders I worked with in the past that I want to do my best work under their leadership because of the relationship that we had.

Mike Hayes: I had just such respect for who they were as a person not only like the work that they were doing but just who they were as a person their character and their integrity. I think it’s a wonderful thing when when we look at a leader and we believe in their capabilities. But it’s an entirely awesome thing when that leader turns around and says I really believe in you. I believe in the team and I think that’s what your your manager was doing for you. It’s like hey this is this is tough, Ron, but you know it’s kind of fun. And I believe in you I believe that we’re going to get through this because of your capabilities right.

Ron: Yeah I think so too because you’re not always sure when you’re in those situations you’re not always sure what’s on your manager’s mind. And when you when you can have this open door policy that you can come in and talk and you’re going to leave with perhaps more tools to do your job or they may help you with it. And you know there’s a spring in your step and you want to get back into the fight. You just appreciate that so much because the other extreme is those managers don’t offer those things and they just say I’m tired of your complaining. Everybody knows it’s a hard thing. Get back to work and get X done. You said you’d get X done where’s X. And there’s this real, there’s a chasm in between these two examples of management.

Mike Hayes: Yeah there’s one is highly empathetic and one is totally absent of empathy whatsoever. Right.

Mike Hayes: And some of the best managers that I’ve worked with have the ability to tell a story about how they were in a similar situation in their career. And when a manager can just relate to the struggle through sharing of their own experience it just releases the tension and elevates the trust right because now you have an employee that is saying OK, well, you’ve been there too. OK so what did you do, and there’s a real exchange of value in learning that takes place sometimes when somebody is managing for the first time like they’re just there in that role they think they gotta try to prove themselves. They think they have to be perfect. So it puts them in a position to not talk about their past failure puts them in a position to not admit when they’ve made a mistake. Now what they fail to realize is that if they would just be a little bit vulnerable and let people in, it’s actually a credibility builder for them because nobody is perfect and your team is not expecting you as a manager leading a team to be perfect they’re expecting you to be human and being human means that we come with flaws. We come with a history of mistakes and failures that’s how we’ve learned that’s how we’ve grown and gotten to the place that we are in organizations is through learning from our failures as we experience success and when we can share some of those past experiences it pours into people and it equips them to get back into it and to get the work done again right. Real people.

Ron: You know I think I could talk to you all afternoon on this topic, Mike. So here’s one thing though that I’d like to leave but I’d like to leave listeners with what is one tangible real world thing that someone can do to say I want to somehow connect with my teammates. I want to connect with my managers not in a manipulative I want a promotion kind of way but in a perhaps I need to be connecting more than I am today. Like what. What would be what would be one thing you can leave them with that says you can try this.

Ron: Not that hard. You just have to be intentional about trying it.

Mike Hayes: Yeah. What I would say to that is do whatever you can to elevate your awareness on a skill or behavior that you need to grow in that is going to make all the difference in the world for you making that next leap. So maybe it’s communication or maybe it’s how to solve problems whatever it is identify what that thing is and then go to work on learning all about that behavior practicing and applying that behavior and take it to the next step by letting people know what you’re working on. Being vulnerable and being truthful and honest and say hey you know what, I know I need to work on my listening skills so I’m doing that and ask people for feedback at the end of conversations saying you know what I’m working on my listening skills, I just like to know based on a conversation we’ve had on a scale of one to 10, 10 being the highest, how would you rate my listening skills today what can I do to improve. What do you need more of from me as your leader and what do you need less of from me and just be open to feedback on that very skilled behavior that you’re trying to develop and improve. That’s what I would say.

Ron: I love it. So, it’s putting yourself, at least giving some thought to a self-assessment, because some people might approach this as let’s change the world, right? The world’s broken, that’s why I’ve never been promoted. It’s just broken.

Mike Hayes: The victim mindset. Everybody else is the problem. And you know what? The truth of the matter is that most people want to grow, most people want to go to that next level, right? They have these uphill hopes. But the problem is that everything worth having is uphill all the way. It takes effort, it takes work. And we all have uphill hopes, but a lot of people have downhill habits.

Ron: Oh, another one. Another one. So you’re leaving us with AOL, the NO, the EI, and the uphill habits, oh man.

Mike Hayes: It’s too much to take, eh? It’s too much.

Ron: Love, love the acronyms. I love it.

Derek: I need a little book of Mike-isms.

Mike Hayes: Yeah, I should try to write these down.

Derek: Alright, Mike, we’re coming to the end of our time today. Before we let you go, I know that you have some consulting services, you’ve written a book, can you just tell us where people can find you online?

Mike Hayes: Yeah, absolutely, they can go to ChangingLeaf.ca, that’s my website. I’m also on Facebook, so you can go Changing Leaf, you can search that on Facebook and find all my contact information there. I’m also on LinkedIn so you can find me there as well. Yeah, I’d love for people to connect and if there’s a leadership development need that they have either through workshops or coaching or keynote talk, I’d certainly love to engage and see how I can add value to what people are up to.

Derek: Alright, great, so that’s Mike Hayes, ChangingLeaf.ca. Thank you, Mike, for you time today, this was absolutely fantastic.

Mike Hayes: Awesome, thanks for having me, it was a real pleasure, guys.

Ron: I love it, thanks, Mike.

Mike Hayes: Thanks, take care.

The post #001 – Emotional Intelligence and Leadership with Mike Hayes appeared first on Ardent Development Podcast.