Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

Jeremy’s Bio:

Jeremy Clark makes developers better. By drawing on over 15 years of experience in application development, he helps developers take a step up in their skillset with a focus on making complex topics approachable regardless of skill level. He is a Microsoft MVP for .NET, and he has authored seven courses for Pluralsight, including “C# Interfaces”, a course aimed at giving developers a clear understanding of abstraction. He loves speaking and has delivered over 200 technical presentations in the last 7 years in the United States and Europe. Jeremy lives in northern Washington with 2 dogs, 2 cats, and a banjo.

Episode Highlights and Show Notes:

Arsalan: Hi everyone. Today my guest is Jeremy Clark how are you, Jeremy?

Jeremy: I’m doing great. Thanks for having me.

Arsalan: It’s so good to have you. I was going to your profile, your website looking at some of the information that we found about you before this interview and I was really amazed that it seems that you’ve done a lot of quality work. You are also a teacher and a mentor. You’ve done a lot of different types of things. I really want our audience to get to know you and really understand where you’re coming from and how you manage all that. I’d also like to hear the story of how you got into independent consulting because that was not planned. You just fell into it. How did that happen?

Jeremy: Yeah. It was not planned at all. I spent the bulk of my development career as a corporate developer at the Disneyland resort and it was a great place to work. I never saw myself as someone who would do contracting or consulting work because I’m not a risk taker. I’m the type of person who needs that regular paycheck every week even though having a regular job is kind of an illusion of safety because we don’t know if the next paycheck is actually coming.

Jeremy: I always felt like I needed that security and I couldn’t go months between paychecks without knowing where my next meal was coming from and things like that. I always saw myself as sitting here and getting a regular paycheck and that’s the way it was going to be. Through a series of small steps, I ended up independent, which is kind of scary. Part of it was that I left that corporate job and workforce startup and part of it was that it was time to start something new. At one time, I managed to save up some money and live within my means, which is always a good challenge to do. I also kind of burnt myself out at that startup. I got to the end of my time there and I realize that I needed to move on to something new because I was burnt out and I needed to relax. I had a friend who said that I needed to quit my job without having a new job. I was like “what? You want me to quit my job without having a new job?” But at the time, I was a senior developer, which is always a good place to be, and there is a good demand for my kind of work. Plus, I did need to break before starting something new. During that time, I started to pursue teaching because get down that’s what I really love to do. I really love to help other developers and make developers better.

Jeremy: So, that’s what I decided to do. I pursued a couple of different paths and I got into cloud teaching and spent some time with that. That didn’t quite work out the way I planned, and I ended up taking a contract job in the meantime and patted the bank account a little more. Then, I ended up with an opportunity to do a Pluralsight course. This was a great opportunity for me because again I wanted to get into teaching. I figured this was a good way for me to show what I could do. I wasn’t really looking at it as a kind of financial solution. I was more looking at it as a marketing and brand building kind of thing because, in the Pluralsight catalog next to these famous people, there’s a little bit of street credit for me.

Jeremy: It turned out that my first course did unexpectedly well for me financially. That gave me the opportunity to do some more courses and I haven’t had a regular paycheck in about four years now. Again, it’s that whole security thing. As it turns out, sometimes you can have that security even though you don’t know when your next gig is coming. A lot of that is because I started speaking within the community. I also started speaking at local code camps. I started regional events in different parts of the US. Then I started speaking at professional events and international events and it’s an interesting trip. Here I am independence. In January, this year, I went to Iceland for a consulting gig. It was for people who had found out about me through various channels.

Jeremy: So, I look back at my life and back in 2010 I was sitting in a cube farm programming. It was a great job, but I look at my life now and it’s like “wow! I’m flying to Iceland to spend a week talking to this team of developers.” It wasn’t intentional, but because of the way that things worked out, it’s just where I ended up. I’m very happy with where I am because it gives me what I need which is to share what I know with other developers and just kind of make it better.

Arsalan: It’s interesting that we have so many different paths that we could follow as new developers. When you’re starting out, when you’re a new developer or still in high school or maybe you’ve switched jobs and you just want to be a programmer or a software developer, you really don’t know what options you have or some of the things that you can do. Those are some of the things that my audience hears struggles with. We don’t know what we don’t know. One of the benefits of having you on this podcast, Jeremy is that they can find out that there are other things that they can do. If they live in an area where there are not many jobs, then they have one option. They can become consultants or do independent work. In your case, you told me that you were consulting with clients that are far away. You are probably also consulting remotely Sometimes. Is that correct?

Jeremy: Yes it is.

Arsalan: You have the opportunity at home and you also can create courses. They sell, and you don’t have to actually do any active work. It’s passive, is that right?

Jeremy: That’s right. The passive income is great because that’s really covering my living expenses right now. What that means is that now I can put my effort into other pursuits like having the opportunity to travel to other parts of the country different people whether it’s having them talk to code schools or to talk to different people on podcasts like yours. It’s nice having that income coming in, but it’s not something that you have to pursue daily. With that said, I know some people who have had great success with it and others who have had moderate to minimal success with it. So, I’ve realized that the position that I’m in is special. I’m very thankful for where I am. But I don’t know if I would’ve been able to actively get to where I am because I just sort of fell into it.

Arsalan: So, sometimes that happens to us. We set out to do one thing and something else happens to us. It just depends. I’ve seen this happen again and again. In fact, seeing that most successful people who call themselves successful fell into what they’re doing. It’s just incredible how many times I’ve heard that. Some will say “I lucked into it. Random stuff just happens to me.” They just do something that they really didn’t think they should do and it works. Then, they drop everything else and get on that bandwagon.

Arsalan: Some people have started companies making a product that they really didn’t want to make, but accidentally made a product. It then turned out to be their flagship product.

Jeremy: I consider myself very fortunate for where I am, but there is also a lot of heading in a direction. So, it’s kind of like what I said about wanting to share my knowledge with other developers. I started out speaking at local code camps and user groups. I started a blog and doing some little YouTube videos and things like that. I’m not exactly sure where I expected to end up. I didn’t end up where I expected to end up, but it’s kind of along the same direction. I don’t think it’s purely random chance. I think that a lot of it is that you create your own luck. Get out there. Talk to people and find out what’s going on. Then, you sort of generate your own luck.

Jeremy: A good example of that that is when I was at that startup. I kind of came to the end of my time there. There were some changes going on in the company. It turned out that I had put in my notice at that company the weekend before code camp. So, I was at a code camp that we can in southern California and talking to the people who I knew from within the community. So, during that time I had about half a dozen people who said “oh, you’re available? Talk to us. We have openings within our company.” I ended up having six leads come out of that. These were people who I knew within the developer community and I just talked to them and met with them at user groups and things like that. That network of people who I didn’t know before has been influential in my career as well.

Arsalan: The key here is that you were out there speaking [to them] and putting yourself out there. First, people know you to be knowledgeable and technically efficient. They know that you can do the job because of the teaching that you do and the writing that you do. Then, you are getting in front of people. If you had the same technical acumen and the same ability but we’re not out there speaking and you weren’t on this podcast and you weren’t writing blogs, then I think you would find yourself in a different situation. You may not have the exposure or the leads. To your point, we really must put ourselves out there if we want to make a change in our lives.

Arsalan: A lot of developers who I’ve talked to, and have known personally, would like to change their situation. Maybe they would like to grow professionally or get into consulting, but they don’t have people coming to them. They don’t have a name. Here’s what I would like to know. [With this question, we are talking about] someone who has been working in the field for years and are at a place where they like to go independent and maybe even make some courses for Pluralsight or some other site or maybe even find their own clients and do some client work, but they don’t have a name and people don’t know them or recognize them, they don’t have a VIP award. Is it possible for these kinds of people to pursue the path that you are on or do they need to do all the things that you did first?

Jeremy: That is a good question. I have a lot of colleagues who are on similar paths, but everyone has their own pace that they go with. The first thing that I would suggest is to find a local Meetup. Talk to other people who are within your developer community, but not people whom you directly work with. That is one way to open your eyes to what is available out there. When it came to [public] speaking, I just didn’t think that I had anything to share because [I was a] corporate developer sitting at a desk, and I don’t want to use the word developer like it’s a negative thing, but I was some kind of corporate developer. I wrote business applications, nothing world changing. I was affecting my users’ lives, but [it was] nothing hugely exciting. Yet, I always thought that I would love to speak and share and things like that. I would go to these big conferences and [think to myself] “oh, it would be awesome to be up on that stage talking to people, but what do I know?”

Jeremy: I was listening to a podcast and they were talking about the .NET world, which is where I lived these days. When .NET first came out, everyone was talking about the basics because C# was a new language, .NET was a new environment, garbage collectors, and how the classic languages worked. Now that that’s been established, people are talking about the latest new technologies in .NET. No one is covering the bids for bringing new developers into the environment or brand-new programmers or people who are coming over from other environments. And [I thought to myself] “you know what, I can teach those basics. I have a good handle on them and a good weight of explaining them.” I took the challenge and I signed up to speak at a code camp that was coming up a few months later. That started it.

Jeremy: I got hooked on it. I realize it isn’t for everyone, but I encourage everyone to try it at least once. If the only thing that is holding you back is [that you think you don’t know enough to get up on stage and talk to people], here’s the secret. None of the other speakers are experts either. The important thing is that you have something that you know that could help somebody else. When I’m talking to somebody and trying to encourage them to go share with they know, I tell them to say something that they wish they had known six months ago. It’s that thing that you struggled through and you finally got over the hurdle and you’re like “I wish someone had told me this six months ago.” That is the topic. You don’t have to know everything about everything. All you must know is one thing more than the people you’re talking to and you can be helpful.

Arsalan: This is great. For everyone listening right now, this is beneficial because you always have something to teach. I’ll give you an example of my seven-year-old kid. She has been programming on Scratch for a couple of years. It’s not really coding the way that we think about it, but it is programming. She is at a point where she is comfortable teaching her three-year-old little sister on how a few things work on Scratch Junior.

Jeremy: That’s awesome.

Arsalan: She’s a teacher. I also started teaching a new class at a K-8 school locally. I’m teaching kids about programming and I want to start awareness between the parents and the students that programming is a valid and legitimate thing that they can pursue for fun or for a career. It’s something that exists. When I was a kid, I didn’t know that it existed. So, I’m trying to teach them, and my daughter is in there and I know that when it comes time to do some things, she’s going to be over there and helping the kindergartners and first graders and even people her age because she has been doing it for over a year and she feels comfortable. That’s incredible for me to think about because since she’s a kid. I’ve been trying to get her into programming, but she wasn’t interested until she started doing it. Now as far as that thing now, for that particular thing that she’s working on, she is an expert to all of the kids who are younger than her.

Jeremy: Right.

Arsalan: If I ask her to talk about what she just learned yesterday and how she made a program she could totally talk about it. For all the other kids have never actually seen any programming, that would be very valuable. It just opens a lot of avenues in my mind. All of us can do this. A lot of us are just shy because we’re thinking to ourselves, “What do I know?”

Jeremy: Right, and what I found was that some of the best articles on my blog are talking about learning something new. So I wanted to learn functional programming and I took so I wanted to learn functional programming and one of the languages that I took was F#. I decided that I was going to go through the first 10 boiler problems, which are standard. I would call them brainteasers, but when you’re learning how to program, it’s mostly mathematical things. Write a Fibonacci sequence and calculate the sum of even numbers up to 100 or something like that. So, I decided that I was going to try to do this using F# in a functional sequence and just say “okay, here are going to be the things that I ran into. Here’s where I ran into a roadblock and here is how I got around it.” I’ve heard some great things about that series from someone in another country asking me if I was going to do any more of those boiler problems because they were following that series. It’s just having someone say that that thing that you did was useful to them.

Jeremy: As far as those boiler problems are concerned, those have been around for a long time and there are thousands and thousands of solutions to those in various languages and people have done them in F# before. They have done them in all the languages before. Putting my process out there of how I went through this is helping other people. It’s awesome to think that something that I would normally be doing can actually impact somebody outside of that. So, you don’t have to get up in front of other people and speak. It could just be a matter of writing some blog articles or maybe putting out a little YouTube video if you’re more comfortable doing talking and live coding things than writing. There are many things that we can do to share what we know. The one hurdle that we do have to get over though is that hurdle of being wrong.

Jeremy: In our industry, we have this fear of being wrong. We have this fear of people coming up to us and saying, “Oh, you’re doing that wrong.” So, we just have to put ourselves out there and realize that we are human, and we are imperfect, this is my process, and if you have a better idea, then great! Share it! If you want to rip me, then go somewhere else. I don’t want to hear about that.” Part of it is just saying that you are going to put yourself out there. It’s scary. You’re going to get some comments that you’re not going to like, but it’s going to be totally worth it in the long run.

Arsalan: You must have somewhat of a thick skin because some people love to bring everybody else down. It’s incredible that it happens, but it happens on Twitter and it’s going to happen anywhere that people are going to post comments.

Jeremy: It really amazes me because I have this video on YouTube, which is An Introduction to Test-driven Development, or Intro to T.D.D. In this drive-by comment, someone said: “this drive-by development is awful.” I was like, “who is this who feels that they need to go to YouTube and find a random video and comment that this technology does not work?” You must realize, first, that you’re not going to please everyone. It was a tough thing for me to get over especially when I was first getting up and speaking in front of people. Then, after you do it enough, you’re going to refine it and find those people you’re targeting. It took me many years to refine and hone into it, but I know who my audience is now.

Jeremy: So, when looking for places to speak, I’m not sure shot-gunning it. [I’m considering] who are the people who are going to most benefit from what I have to say and the way that I normally say it? I know I’m not going to hit those cutting-edge things. I don’t do that leading-edge, new technology stuff. That’s not my thing, but [for others] who do that, more power to them. If I have of .NET programmers who want to get better, then that’s basically my target audience. There are a lot of people out there like that, which is nice. I’ve been able to identify that. Now, when I get the comments that say “Oh, this is too basic,” I can say, “That’s fine.” Yet, there are a lot of people who are getting a lot of benefit out of it. So, being able to separate those people is nearly impossible. I’m still crying inside when someone doesn’t like me, but that rationalization allows me to focus on the people who I am trying to reach.

Arsalan: It’s hard to take it. It happens to me. It happens to everyone. It’s hard to take it. It happens to me. It happens to everyone. Sometimes, you get somebody who just doesn’t like you. It’s that. Sometimes, they are saying things that they don’t mean. So, you must have thick skin. You must be able to focus on the positive people, the people who will give you positive energy versus the people who are pulling you down. That’s going to happen everywhere except when you are in a face-to-face environment or when you’re giving a presentation. You will probably not get those comments from people who are present. Virtual people like to throw all kinds of things that you.

Jeremy: Yeah, and the nice thing about code camps are an awesome place to start speaking if that’s what you want to do because first, it’s free and people aren’t expecting things. In fact, I always offer people things like a “double your money back guarantee” if they don’t like my topic. Plus, everyone in the room wants you to succeed. They don’t want to sit there and waste an hour. They want you to succeed. They want to learn something from you. Everyone is rooting for you there. Again, not everyone is going to walk out getting what they wanted out of the topic or the presentation or whatever. So, generally, there’s a very good positive energy in the room. Nobody wants time. They want you to succeed.

Arsalan: I did want to ask Pluralsight also about the MVP award. Did you have the MVP when you approached Pluralsight?

Jeremy: So, by timeline, yes, I was awarded an MVP before Pluralsight. As far as Pluralsight is concerned, they don’t really care who you are. They want to know if you can teach. That is one thing that I found that was nice. They have an audition process, and anyone can go through the audition process. You go to their website and somewhere on there you can click to show that you want to be an author. You go through a process where they send you some instructions and you do a sample video and then they will see if you can teach. They don’t care who you are. They want to know that you can teach.

Jeremy: If you want to talk about the technical aspect of presentations and whatnot, they do a-peer-to-review system where there are some people who are experts in those technologies will view to determine if something is way off when it comes to the technology, not for 100% correctness. So, the MVP idea and Pluralsight are an interesting mixture. MVP awards are basically Microsoft recognizing people who contribute to the developer community. So, through my speaking, my blogs, and things like that, that is how I was initially awarded that. I’ve been an MVP for six years now. So, it’s been great. So, Pluralsight and MVP have interesting aspects to each other, but I would not say that one requires the other.

Arsalan: Do you remember your first encounter with programming?

Jeremy: Yes, I do and it’s just because I was thinking about this a couple of years ago. I’d like to say that first experience with programming was with my dad. He brought home an Apple II that was left over from work and I started programming some Basic and that was my first programming thing. But, you know what, that’s not what it was, and this is going to show how old I am now. So, I apologize for that. I had a ¾ gray beard, but I just shaved so I look a lot younger now. I trace my first programming experience back to CRISP 79, which seems a lot longer ago now. I got this toy called a ‘Big Track.’ It was basically a programmable tank. It was a tank that had six wheels and the little LED thing on the front and it had a CAD on the back. It was a number pad. So, it was several arrows and you would punch in a program for what this thing was supposed to do. You would program it to go forward a certain number of lengths for each vehicle and you could say ‘right 90°.’ So, it would go right 90° and then go forward five or….and then fire the little fake laser thing in front. It was horribly frustrating, but I found out that I was a programmer because first, there was no going back and fixing a program because there was a splay. It was just a matter of programming it and hitting go. There was no ‘go back and debug because line 3 was wrong.’

Jeremy: So, I found myself writing out my instructions on a piece of paper before I typed them into this little keypad. That was my first experience that real life doesn’t always match theory. If you say ‘go forward and turn 90°, it’d turn 85° or 96°, depending on the surface that it was on. These were on plastic wheels and so if it was on carpet it would do one thing and if it was on the tile it would do something else and slide around a little. So, if you told it to turn 90° and it only turned 80° and plows into the coffee table rather than going around it. So, the way you debugged it was by going back and telling it to go 100° rather than 90°. I look back at this and wondered how I ever survived that because that was just a little programming experience. Yet, I guess that was just the time that I found out that I liked doing things like that and I wasn’t completely frustrated by it.

Arsalan: Some of my best experiences were when I was young, and I wanted to do programming. I had access to a computer growing up, but I think back in the day we didn’t have all these instructions. We didn’t have the iPhones and the iPads, and we didn’t have cable TV. Well, I didn’t have cable TV. We didn’t have anything. So, all I had was what was in front of me. I think it would be good if we could find a way to make things simpler again at least for kids so they could focus on things and not get distracted all the time.

Jeremy: Yeah, that’s an interesting challenge. There are times when I’m like “That’s great! I have the entire internet open to me. So, I can solve this programming problem.” But, at the same time, part of me wants to go back to 1980-whatever when I’m typing in basic instructions that were printed out in the back of a magazine. So, you just typed in these programs and you learned to debug based on how badly you typed and by going through them. That’s how we got programs, you know. There was nowhere to download stuff from. You had to type them in yourself.

Jeremy: I didn’t have a lot. So, I always had old computers. That Apple II that I talked about, it was well past its prime by the time that I got a hold of it. You know what’s great? Having a computer that you can hook up to a television set. Oh man, now I feel old.

Arsalan: Yeah. We’ve all heard about it or done it. We are lucky that we are in an era where we can have high definition screens on our desks. Even 20 years ago, that would’ve been the stuff of dreams.

Jeremy: Oh yeah.

Arsalan: So, did you study computer programming, computer science, or any other related field in a formal environment?

Jeremy: No and that was interesting because I am, for the most part, a self-taught programmer. So, like I said, I did hobby programming and back in the day, I ran a bulletin board system where you would basically modem into a specific computer to do stuff. That was quite a thing back in the day. How I got programming for real was that my brother worked for a software distributor. One day he drops this gigantic box in my room. He told me it was a compiler. It was a C++ compiler. I installed it and there were command lines of C++ and I ended up writing some little programs for his bulletin board. I wrote a multiple choice, trivia quiz. It was fun, but it was my first foray into programming for real.

Jeremy: Back in college, I was an English major. I don’t regret that at all because it taught me critical thinking skills that became very useful to me as a programmer. Then, when I decided that I wanted to do programming as a profession, I realized that I didn’t have any formal training and wasn’t sure how I was going to get my foot in the door. That was something that, I don’t want to say that I lucked into to, but I was in the right place at the right time and kind of pursuing a path.

Jeremy: I ended up on the user side of a project. So, I was working at the Disney Land Resort and I was on the user side of this big, resort-wide system that we were doing. I was doing the requirements meetings and I was building some little things and access according, so we could figure out what our requirements were. The develop manager saw that I had the right mindset and I was asking the right types of questions. So, she had a junior position open. So, I said “Awesome! I will take that!” I would say that I got started late as a developer. I wasn’t a developer until I was 29 years old. Most people that you are practically over the hill at that point and that was just when I was beginning my professional journey.

Jeremy: I am very fortunate because that team that I ended up on was focused on going forward. So, everyone was thinking about how we could propel ourselves forward and meet our users’ needs that best way that we can. Everyone was sharing. So, the senior developers were sharing with the people who knew less than they did. So, it was an inspiring growth environment. I attribute how rapidly I was able to progress as someone with no formal training to that and I wish that more people could have access to that. I realize that was a rare experience that I got to experience. It was awesome!

Arsalan: That is amazing that you had the opportunity and found yourself in the right place and at the right time. I have had a lot of other people tell me similar stories, not the same. If you work at a company that deals in technology or maybe have a technology, they may need someone to build some custom applications for them.

Arsalan: It appears to be a common pattern. Some places just need someone to write some Excel or Access or some Visual Basic, or something simple. Some places may have websites, or, in your case, more. The lesson that I take from this is this. Let’s say that you are out, or you are a student, and you want to do software development, but you don’t have any experience or training. So, you get a job in a different position, but you know that this company has a department where they hire developers. There is an opportunity for you to work within the system and either apply for an open position or maybe have a good working relationship with managers there in those departments.

Arsalan: I’ve seen it happen time and again where people go from something completely unrelated to software development or to testing and then they work up. Eventually, they all end up in the same place. Once you have a little bit of experience, then nobody asks how you got that experience or whether you have a degree. Nobody asks if you have a master’s degree or a Ph.D.

Arsalan: I spent many years studying computer science and computer engineering. It turns out that it wasn’t needed for the job, at least. So, I think that’s a good lesson for all of us to learn, especially for those who are listening to this podcast right now and they are apprehensive about getting a job somewhere. Go get the job. Having a job is important. Being jobless is no fun.

Jeremy: You reminded me of the steps before that because when I started at Disneyland resort, I was making hotel reservations. That was my first job there. I was using a scheduling system. I hate to use the scheduling system, but basically, the manager was going through an Excel sheet and typing in the schedule for everyone. Because of seniority and other things, if someone changed their position, she had to rearrange everything and fill in the schedules all over again.

Jeremy: It was this huge manual process. I knew some Excel and I built a pivot table. I told her to just type in the schedule in the pivot table and that would turn it into a grid. It was little things like that where you could save time that is valuable in the long run. I don’t know that the little schedule spreadsheet got me the programming job, but it was small steps to, first, prove to myself that I could be technologically useful and to prove that to other people as well.

Jeremy: So, there are some things that you can do even if they are technologically out of your realm. I see my job as a developer to make the world a better place. That’s just me making other people’s jobs easier.

Arsalan: So, that was your first job as a junior developer. You were excited. You have never done it. You are 29 years old. I don’t know how people reacted to that, but a lot of people who I know would not necessarily react very positively to joining their company, their closed knit group with little to no experience. It happens to a lot of us. Getting accepted and viewed as a valued member, an equal and contributing member to each team, take some effort. How is that experience for you?

Jeremy: Like I said, I was on a very welcoming and open team. So, it was probably smoother for me than what a lot of other people go through.  it will take time before you become useful in the department. Realize that if you are brand-new to the area, you’re going to be a drag on the area for a while. So, just because it is in of that. That’s not necessarily that you are a new developer, it might be because you’re new to the industry.

Jeremy: When I took a contracting job in a completely new industry, I didn’t know how anything about these people’s line of business works. Although I was rock-solid as a developer, and the skills that they needed, it was a learning process in determining how they did things. I think I think that the key to becoming a successful developer is absorbing knowledge. You must want to learn. You can learn the technologies. You can learn about the business space area. You can learn whatever the problem space it.

Jeremy: There are so many things out there to learn, but you must be willing to do it. If somebody must keep handing you things that you need to learn, you’re not going to be successful. Yet, if you go and find new things to learn and start participating and that experience, the other developers are going to see that you are serious. You will be showing that you are interested in improving and getting better and wanting to be a productive member of the team. That attitude goes a long way toward softening those people who might be a little harder towards that.

Arsalan: Were you completely on your own or did you have a mentor over there?

Jeremy: It was kind of weird because we tried to set up a mentoring relationship where everyone was paired up in the department, but it didn’t last very long. So, it was more of an informal thing. Different people on the team had different areas of specialty.

Jeremy: So, when I first joined the team, I was given reporting because it’s hard to delete data if you’re doing reporting. It is easier to hang a server, though. I’ve hung servers while doing reporting before. Yet, it’s something that you can approach, and you can learn how the data is set up and people looking for you to get it on a piece of paper and things like that. During the initial process, I am talking to people who know the system, the data that I’m working with so that I can understand how the relationships work and things like that. I’m talking to people who know the tool.

Jeremy: We were using Crystal reports. So, I was able to tap into these people to do the different areas that I needed to learn. Then, eventually, I would be able to do programming. When I first started programming, we were using Delphi and doing some actual language programming. So, we were getting more into the actual application space. It was more of an informal system where we were sharing with each other and we would pair when we ran into problems.

Jeremy: Now, as a senior developer, I’ve heard about these teens who have a 15-minute rule and I really like the idea of this. During the 15 minutes before you asked somebody how to do something, you must spend at least 15 minutes looking for a solution on your own. That could include looking on Google, Stack Overflow, or the software that you have in your environment. So, you must spend at least 15 minutes trying to find an answer before asking someone else. So that gets you past always asking somebody else for help and helps you figure it out.

Jeremy: On the flip side of the 15-minute theory, if you spend more than 15 minutes looking for something, you must ask for help. So, that prevents people from getting stuck. It also promotes that sharing environment. That way, someone isn’t sitting there spinning for two hours being stuck on a problem. They are asking for help and other people are used to asking for help and giving help. Again, it depends on your teammates wanting to be involved in that, but I like the idea of doing some due diligence first and realizing when you get stuck and then asking someone for help.

Arsalan: That’s good advice. I’m not seeing both sides of the equation. I’ve been on both ends of this divide. I’ve been the one asking and the one being asked these questions. The problem is that, for the people who are new developers, the person that you are asking also has his or her own tasks. Everybody is under the gun. That’s what happens.

Arsalan: The problem is that sometimes they are deep in their process and if you interrupt them, not only do you break their flow and sometimes that means that something gets delayed for them, which further adds to their stress and therefore their response to you may not be as favorable. So, I think it’s good to have some type of process. One of the companies that I worked at had this umbrella process. It rained a lot in Chicago, so everyone had umbrellas. If it was on the desk, that meant not to bother them.

Jeremy: Yeah. I like that. This is one of the things that I miss from being in a cube environment. It’s nice when you can pop your head up over the cube wall to look at the person and figure out what’s going on, once you have some experience and you can see it. You can tell if they are deep in meditation while trying to solve a problem or if they’re just looking at the whiteboard or if they are talking to a client or whatever. You can get that visual of how busy this person is before you approach them. Considering I’m working remotely with people, I’m not quite as comfortable with that. I feel like I might be interrupting you if you’re deep in thought. I do miss popping my head up over the wall to see if that person is available or not. So, yeah, the umbrella method does sound pretty good.

Arsalan: If you could start over, is there anything that you would do differently?

Jeremy: I learned many things the hard way. As someone who likes helping the next generation of developers, I love telling people the problems that I ran into and the things I wish I could avoid, but I know that people won’t listen to me and they’re going to have to experience those problems themselves. The advice I usually give has to do with best practices. Before I say anything further, I hate the term best practices because it implies that this is the right thing to do in all circumstances. When I was a new developer, I always thought that best practices applied to academic people and not to regular programmers. So, I proceeded to make huge messes. I eventually realized that the people who had for 30 years or more might know something more than I do. So, I would encourage people to understand the best practices.

Jeremy: I don’t always follow them, but not because I don’t want to use them, but rather, it’s because I know that they don’t apply to the specific situation that I am in. So, listen to your elders. I know that I’m kind of in with the elders, but that’s self-serving. That’s what I wish I would’ve paid more attention to when I was younger. The first solo application that I did in this one department, I was doing a start to finish reporting application. I ended up putting all the logic in the code behind the main form of the application. When I was building it, I figured that it was a simple application, and this wouldn’t be a big deal. Yet, as it got bigger and bigger, I then had 700 lines of code in this one form. I had to reap the benefits of that because I supported the application for many years. It was a moment when I wished that I could have gone back to do it over again and have things in different places based on functionality. Yet, I don’t know if I would’ve learned my lesson without making that mistake. So, I don’t know what a good answer to that is.

Arsalan: I have two little girls. There are arguments or debates between my wife and me about what to do if they are doing something potentially dangerous. My wife’s point of view is to allow them to fall and get hurt and learned the lesson. I like that approach. In general, but then it gets to a point where I feel it’s a little too dangerous and I want to enforce some rules. So, I think there’s a balance here. The people who you and I are talking about, who read blogs and take your courses, or listen to this podcast, or do this, may not always understand this. It’s always a good idea to try it if you’re unsure, then if you fall flat on your face then you’ll know it’s not a good thing and you’ll learn a lesson. However, sometimes it’s beneficial to listen to people who have been there and take their word on it. Often you can save yourself so much trouble and heartache if you could avoid the big problems. I wish I had.

Arsalan: You were mentioning, that as a new developer or just as a young person, that you are so full of self-confidence sometimes and think you know everything. I’ve suffered from that. I just want to believe my own experiences, but sometimes it’s better. There are patterns and there are anti-patterns but we’re not going to go into this. When you’re looking at software development, there are ways of building good software that is just bad. They’re not all bad, but they are generally bad. So, I think it’s good knowledge. The best way to do that is by listening to podcasts, watching YouTube videos, reading blog posts, and all that other stuff that’s out there that Jeremy Clark and other people like him are putting out.

Arsalan: So, Jeremy, are there any podcasts, YouTube channels, or any other places on the internet that people can glean wonderful information?

Jeremy: Yes. There’s a lot of good stuff out there, but there’s also a lot of bad stuff out there. I like Pluralsight because they go through that vetting process. So, it’s not random content on YouTube. It’s curated content where they have found people who know how to teach a topic and are not confusing things.

Jeremy: Another thing that Pluralsight does is that they don’t have multiple courses on the same topic. So, you’re not looking at 32 courses on how to do Angular 2 or Angular 5 or whatever the version number is up to at the time. They are all more targeted and there are one overview course and a lot of specific courses. So, you don’t have several overview courses to pick from. If you are a video learner, then I highly recommend Pluralsight.

Jeremy: Unfortunately, I am not a video learner. I figured my brain doesn’t work at the same speed as video. Basically, my brain speeds up and slows down and video runs at a constant speed. So, for me, print media is the best way for me to learn whether it’s blog articles or paper books. I’m one of those people who still like paper books where you can flip back and forth between pages. Find out the best way that you learn and try to get yourself into the environment where you will learn best. I’m kind of a book person. So, I talked to a lot of my friends about the resources within the community to see what other people are doing and recommending. That’s what I do.

Arsalan: That’s good to know. Pluralsight is very good. You can check out Jeremy’s courses, and we can put the links to Jeremy’s courses on our webpage for this episode. It’ll be in the notes with the transcript of our interview and all the links. If you have a promo code, you can share that with us if you’d like and we’ll make sure that it’s on that page.

Jeremy: I’ll make sure to get you those links.

Arsalan: Awesome. So, we’re finally at the close. It’s been a lengthy interview. I’m grateful to you for giving us so much of your time today. Before we close, I still have a couple of interesting questions that I think our audience could benefit from. One of the things that I’ve noticed is that you are focused on .NET. .NET is not one technology. It is a suite of technologies. It doesn’t appear that you have diverged from your focus, which is a very good thing. I would like you to talk about how you keep up with things and how you decide which new technologies to learn. What do you do? What’re your criteria? Also, give us some advice on how to learn new things.

Jeremy: The first thing to understand is that I cannot know everything. That was a hard lesson for me to learn. I think what I want to focus on. I like to attend user groups, code camps and community events and talk to people about what technologies they are using, what’s interesting, and what’s exciting. I ask myself, what makes me happy? In the current world, I’ve developed an interest in machine learning and functional programming.

Jeremy: Although I’ve talked about using F# earlier, I’ve started learning Haskell for functional programming. Part of the reason I did that is to get out of the .NET environment. That way I don’t confuse functional bits with .NET bits. Most of the work that I would be doing would be in the F# world. I dabbled in Scala and a couple of other things. I’ve also seen some cool things out there that I haven’t had a chance to dabble in.

Jeremy: So, people ask me which technologies they should learn. I usually explore a couple of different things. I asked them if there is a specific industry that excites them. Do you want to be in medical devices? Do you want to be in entertainment? Do you want to be in finance? If there’s a specific industry that you want to be in, go and find out which technologies they are using. Then, start exploring those. That’s one direction that you can go in if you are looking at a specific industry.

Jeremy: Another way is this. Ask yourself what types of programming are you interested in? Are you interested in the hard-core computational stuff? Do you like the UI design and presentation and trying to figure out how to interact with your users? Do you like the service, communication or service bus type of stuff that’s kind of in the middle? Then, look at what’s available in those worlds. I love XMAL as a UI technology. Desktop-based and people might see that as limiting, but there are a lot of Windows machines out there. For people out there who like a broader reach, there’s the web. The web is the hugest reach we have. So, if you like the client side of things, JavaScript for programming presentation logic. That’s a huge area to explore. Either focus on an industry or a technology that makes you happy. I try to encourage people to do things they love. While we all need jobs, we also need to do things that we find fulfilling. Did that answer the question? I feel like I’m talking in circles.

Arsalan: I think that is a great answer because it’s hard to answer questions like these because we want to know how you picked a technology and or are so many things that excite you. I think there’s also the aspect of which industry you want to go into because where is the money? Ultimately, you could do something for fun or you could say that you want to do it professionally and you need to learn certain types of technologies because that is how a means becomes an end. Some people have different motivations. If you are just starting out or are a new developer, if you are young or looking to establish yourself, then I encourage you to focus on things that will get you a job. Focus on things that will get you noticed. You need to make your mark. Once you have done that, then it’s okay to branch out into things that interest you. When you’re getting yourself established, the first four or five years are the hardest. In our industry, it is hard to find senior people. So, it gets easier with time.

Jeremy: Oh yeah. It does. I wholeheartedly agree. I would say that JavaScript is the place to be right now, but there are a lot of corporate developers out there right now and .NET is huge in the corporate industry. So, it might also depend on which part of the country you’re in. If you are in the Silicon Valley area, then a lot of the open source technologies and some of the more niche languages and languages that aren’t quite as widespread are things to look at. Yet, if you’re working at a bank, then they are going to be using JavaScript and .NET for a lot of the backend stuff. There are a lot of corporate jobs out there. I was a corporate developer for 11 years and I am proud of that. There’s nothing wrong with that.

Arsalan: So, how can people get in touch with you, Jeremy?

Jeremy: You can find me under Jeremy Bytes everywhere online including my website: Jeremybytes.com and also on Twitter. Each I do quite a bit of speaking so I travel the US and venture internationally from time to time. On my website, there are also links to my YouTube channel where I have some screencasts on various topics, as well as my Pluralsight courses. That’s pretty much the one place to go to find out where I’m going to be.

Arsalan: All right. Jeremy Bytes everywhere on the Internet. That’s a good lesson in branding. I am so excited to have Jeremy here and be able to talk to him about some of the questions that our audience has. If you are listening to this podcast and are really excited about learning or you want to learn more about Jeremy or check out his courses, or if you want to see a number of our other guests, our previous guest was Reuven Lerner and we talked about Regular Expressions and he’s an expert in that, if you just want to let know how to get started, you can send me an e-mail@us.mentoringdevelopers.com. You can also tweet at us at @MentoringDevs. Let us know what you think about this episode and if there’s a specific person that you would like us to talk to would like to pursue that as well.

Arsalan: All right, Jeremy. It was so nice to talk to you today.

Jeremy: Thanks for having me.

Important Links

• Jeremy Bytes Website
• Jeremy Bytes – Pluralsight
• Jeremy Clark—YouTube
• Meetup
• Pluralsight
• Scratch

Thanks for Listening!

Do you have some feedback or some advice for us or our audience? Please give us a review on iTunes or Stitcher and share your thoughts.

If you found this episode useful, please go ahead and share it with your friends and family. You can do that easily using the social media buttons at the bottom of this page.

Subscribe to the show on iTunes or Stitcher (for Android users) to automatically get new episodes every Tuesday.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

Damian’s Bio:

Damian is a Cloud Developer Advocate specializing in DevOps. After spending a year in Toronto, Canada, he returned to Australia – the land of the dangerous creatures and beautiful beaches – in 2018.

Formerly a dev at Octopus Deploy and a Microsoft MVP, he has a background in software development and consulting in a broad range of industries. In Australia, he co-organized the Brisbane .Net User Group and launched the now annual DDD Brisbane conference. He regularly speaks at conferences, User Groups, and other events around the world, and is an occasional guest on various podcasts like .NET Rocks and Hanselminutes.

Damian has his own Channel 9 show – The DevOps Lab. Check it out for real-world guidance on implementing DevOps in your organization!

Most of the time you’ll find him talking to developers and IT Pros to help them get the most out of their DevOps strategies.

Episode Highlights and Show Notes:

Arsalan: Hi, Everyone. Today, my guest is Damian Brady. Damian, how are you?

Damian: I’m good, thank you. How are you?

Arsalan: Doing fantastic. And, you are not in the US. You are actually somewhere else. Where are you right now?

Damian: I’m in Australia at the moment, on the East coast in a place called New Castle, which is about two hours North of Sydney.

Arsalan: Right. Is it true that it’s summertime over there? It’s hot and sunny where you live?

Damian: Yeah, it’s very much summer time. It’s been 30-something degrees every day, which is Celsius. I can’t do the conversion. We’re talking 90’s [in Fahrenheit], I think.

Arsalan: Wow. I live in Ohio and we’ve had lots of snowstorms this time of the year. We are not very far from Canada, where you lived for a while. What were you doing there?

Damian: I was living in Toronto for 12 months, basically for my wife’s work. I went over there with her. I’m lucky enough to be able to work pretty much from anywhere in the world. So, I went over there for a year and we just got back to Australia maybe two weeks ago. It was a bit of a change. It was -28 Celsius, which is probably pretty close to that in Fahrenheit when we left Toronto. It was plus 30, in the 90’s I think, when we got to Brisbane, where I used to live in Australia and then we came down to New Castle, which is where I’m living now.

Arsalan: Yeah, the world is a large place and the climates are so different. It’s just amazing to meet people from different parts of the world and it’s really good to have someone from Australia on our podcast. We haven’t had that before.

Arsalan: You currently work for Microsoft. What’s your title again?

Damian: I’m a cloud developer advocate for Microsoft.

Arsalan: We’re going to unpack that in a little bit, but first, I want to hear from you about something interesting that happened to you in your career as you were starting out when you were a student. You were in college and you were working on a voting system for the Australian elections. What happened there?

Damian: Yeah, it was interesting. I was in the third year of my IT degree. We had a group project, which involved a few people. We set up our tasks. The project was to write an electronic voting system. So, everyone would submit their votes and it would follow the Australian Federal Voting System, which has preference allocations and all sorts of fancy stuff that happens with Australian elections.

Damian: My part of the project was to write the algorithm that actually counted the votes. It was right up my alley, but I needed to get a couple of questions answered. Mainly, the biggest one was what happens if two people have exactly the same number of votes? So, I went to the Political Science department at the university and spoke to a professor there. It shocked me at the time that there wasn’t actually an answer.

Damian: The answer that he gave me was “we would do a recount and then there’s a different number that comes out.” This is fine for, well, I don’t know that it’s fine, but it’s understandable when you have a bunch of humans counting paper votes. But the computer is probably not going to get a different answer each time. So, I think what that taught me was that without that conversation, I probably would’ve just made an assumption or skipped that requirement or something. But, having that conversation with somebody who might end up using that system was really important in finding out what bits needed to be defined. The conversation is what is needed to happen to get the real software working the way that people needed it to work.

Arsalan: I think the biggest difference that I see between someone starting out in software development and a veteran is that the veterans are more jaded. They tend not to trust the initial set of requirements that are given and they know that when they dig deeper and think about the problem in detail when they actually show the user how a potential system will work, sometimes our understandings are different. Until you dig deeper, you really don’t know.

Arsalan: It’s not all about writing code, right? It’s more than that. It’s about doing the right thing and sometimes it’s hard to know and maybe that is the hardest thing in software development.

Damian: Yes, absolutely. I’ve done a bunch of jobs over the last 15 years or so. I think that writing code is the bit that everyone can do. Actually, having conversations with people and realizing that exploring the requirements are a bit more than what’s just written on the paper is a necessary part of it. We’ve always heard the thing in software development where the user or product owner doesn’t know what they want. They ask for something and you deliver that exact thing. Then, they decide that they didn’t want that after all. That’s just a known thing with more experienced developers, I suppose. But, whether you become jaded and say “I’m not going to get this right. I might as well write the best code I can” or whether you go the other way and say “well, the best thing to do would be to work together and have a conversation and sit down with the person and deliver something really early that they can see and shape the direction that they want the software to go.” That’s kind of the two directions that I’ve seen people go in software development a lot of the time.

Arsalan: Right. So, the modern trend, especially in smaller organizations, is to use Agile methodologies. By that, they mean that they are not going to assume that they know exactly what to do up front. They are going to assume that they don’t [know] and they are going to take it one step at a time.

Arsalan: Let’s say that they are going to iterate. So, imagine that there’s a for-loop going a hundred times. Every time, you learn a little bit more and then you make a little more of that software. That is something not thought up in a meeting with a standards committee who has decided that we need to do this. We are doing this because we have found that all other methods are not working.

Damian: Yeah. Agile kind of came out of the acknowledgment that at the start of the project, that’s when you know the least about what’s happening. You know the least about what the requirements really are at the start. So, the idea of defining everything to the nth degree up front and then trying to implement that in another period of 6 months or 12 months is inevitably going to lead to something which maybe isn’t exactly what you needed at the time. So, Agile was a reaction to that. We said, “let’s acknowledge that and accept it and do it iteratively.”Like you said, let’s just do a little bit at a time and realize that we’re fallible as humans. We may not know everything up front and we can change the direction based on what’s happening in the environment as well.

Arsalan: Right. So, I want to change tracks a little bit. I want to talk to you about your initial days and how you started, not just how you got your first job. Why did you want to be a developer? What was your first encounter with programming? When did you first realize that is a thing that somebody can do?

Damian: Well, I was fairly lucky, actually. My dad was interested in technology. He’s a solicitor, or lawyer, in Australia. He was really interested in these new computer things that were being made available to the public. So we had a computer in our home quite early. It was an old one from my dad’s work. Then at some point, we got an Omega 500 and dad and I bonded over writing code. It was Omega Basic. We were buying computer magazines. At the time, that was how you learned to write code. You’d buy a computer magazine and then there’d be a few pages of code that you’d have to copy to get something worth working.

Damian: Then, I realized that you could tweak little bits of that code and make changes. It kind of became this thing that felt really powerful – to be able to make this device do what you wanted it to do. It was just little games and things like that. So, it was really early. It was probably when I was around 10 or so when I would’ve written my first software that was my own code, I think. That was the initial exposure to this world of computers and programming.

Damian: I maintained an interest while I was at school and high school, but I actually went into music after high school. I got this false impression at the university that writing code was going to be turning up every day and typing stuff out based on really strict specifications that were sitting next to me. [I figured] that it would just be this really boring thing, almost like data entry, I think.  That was an incorrect impression that I have since learned, but at the time, that’s what I thought software development was. So, I went and did a year at the Conservatory of Music in Brisbane until I realized that doing that all day, every day was really taking the enjoyment out of doing music. I experimented with a few other degrees and a few other courses at the university and found programming again as one of the courses that I did. Then, I went straight back to that and I’ve been there ever since.

Arsalan: That’s great. What kinds of music were you interested in? Were you an instrumentalist?

Damian: Yeah. I actually played jazz trombone. [It was] a slightly unusual one, but I think the main reason why I started playing that [was that] my dad played trombone. So, we had one in the house, which was very convenient, but I also learned piano when I was younger. I played piano and trombone, but I haven’t picked that up in about 10 years. So, I don’t know whether I could [play] anymore. It was jazz, mainly. I still enjoy jumping on the piano and playing what I hear on the radio.

Arsalan: That’s great! For the longest time, I wanted to play the electric guitar. It’s typical. There is nothing unusual about this. The reason why I got into programming was that I wanted to make video games, which is also very typical, and I wanted to be a rock star.

Arsalan: I wanted to play the electric guitar. I never had an electric guitar until I had a friend who was a very good guitarist. I was buying a guitar for him because he needed a car. So, I drove him to a guitar store and we were looking for guitars. I said “hey, do you think you could help me buy an old guitar for myself?” So, I ended up buying a guitar. It was a very cheap Squire, but I loved it. I was horrible at it because I never took a lesson.

Arsalan: I enrolled in college. I was in college and figured that maybe I would change majors and they would teach me how to become a musician and how to play guitar. I was music major. So, I went through the requirements and it turns out that you already need to be a good enough musician before they’d let you in. I was confused. I was thinking “what’s the point? If I’m really good, then I don’t need to go.” So, that was a really interesting part of my life. So, I have a tremendous respect for musicians, especially the ones who go to music school because they are already pretty good.

Damian: Yeah. I had lessons. I did all that stuff before that phase of my life. So, when I went there, I thought I was pretty good. When I went to the conservatory, I found out that I was not actually very good at all. I was quite good at the theory, which has a bit of a math component to it. But if you put me on the stage next to any other trombone player in that entire building, and probably a bunch of people who don’t play trombone, I was probably not going to be in the top half of the players on the stage. There’s a very good chance that I would’ve been the worst trombone player in the building at that time. So, I completely appreciate what you mean. The standard just to get into those things was really quite higher than I could cope with in the long term. Yeah, you already need to be able to play.

Arsalan: So, you didn’t do a music major. Did you go to school and get a computer science or computer engineering degree? What were you doing there in college?

Damian: After the conservatory, I decided on my ability and how much I was enjoying it, I was never going to be able to make a living from this. It was not really helping my love of music. So I went to the university and enrolled in a general science/bachelor of science degree.

Damian: I did a bunch of really unusual and unrelated subjects. I did philosophy. I did a chemistry subject. I did physics and biology, and I did an IT subject. I did an algorithms subject and that was the one I loved. So, I thought that maybe I had just gotten the wrong idea about the profession. So, I switched my degree to a bachelor of information technology, which is what it was at the time. It was a little more business-oriented programming, I supposed, rather than computer science. I saw a lot of stuff on databases and algorithms. But, I also saw some things on project management and that kind of thing. I ended up with a bachelor of information technology.

Arsalan: Do you think it helped you in your career?

Damian: A little bit. To be perfectly honest, I think I learned a little more in the first six months of actual working than I did in that four-year degree. There are a few science-related things like O notation for the complexity of algorithms and things like that that I can still rely on my knowledge of that and my learning of that. For the most part, I think most of the practical knowledge that I have was learned on the job.

Damian: I’m glad that I did the degree. It got me interested in the subject again. It helped me learn how to learn, I suppose. But I don’t think that it was completely necessary at all for a software development career.

Arsalan: Yeah. This is a theme that I observe in a lot of the interviews that I do here for Mentoring Developers. It turns out that you don’t really need a programming degree, or computer science, or computer engineering, or any kind of IT degree to find success. Apparently, a lot of my superiors in my career don’t have anything to do with computer science as far as their education goes. Yet, that has not hindered them [in becoming] more successful than I was because they were managing me and nobody ever cared. I, on the other hand, went to college and graduate school. I studied for years trying to learn as much as I could. Then, when I got out, I realized that I didn’t need to do that.

Damian: Yeah. It was a little difficult at the time to get a job in software development. This was 15 years ago in Brisbane, Australia. It was difficult to get a software development job if you didn’t have a degree. You would have to enter a company, maybe, as a technician or support person or something like that and work your way in. But that was at that time. I think the trend is changing. I think people are realizing that if you can prove that you are a good software developer, there is no real reason to have a degree attached to what you’re doing, which I think is a good change. I don’t think it should be a requirement, necessarily.

Arsalan: Right. So, in the US, what I’ve noticed is that a lot of companies want their new employees to have a college degree, but not necessarily in computer science or computer engineering.  What they are looking for is someone who is educated in other ways, understands how to deal with people, and has a level of comprehension. They feel that is a good differentiator. They get thousands of resumes per job and they don’t want to go through them. So, they feel like it’s worthwhile to have that as a filter.

Arsalan: But, having said that, I know a lot of people who never went to college and they are very successful. The reason that they are successful is that they were able to get their first job maybe through contacts or maybe they worked their way up from QA and just got their foot in the door somehow. They proved themselves and very soon the company, maybe, needed twice as many people. It was very easy for them to move up.

Arsalan: A lot of times I have noticed, in these days for the past 10 years, that you are able to work on your projects even if nobody is hiring you. Then, you can show people what you can do because we have the internet now. If you can show people what you can do, then you can show people your code using Github. All of a sudden, we have the ability to promote and market ourselves.

Damian: Yeah, absolutely.  Github, or something along those lines, [provides] a much better indicator of the code that someone writes [rather] than the fact that they have a degree. I knew a handful of people who finished the degree that I finished and I don’t think that they’d really be able to write code. It wasn’t really a requirement. You could get through the degree program without being able to write software. So, saying that you have a degree doesn’t mean that you’re going to be a great developer. Whereas, if you have an example of code out there, on Github for example, it’s something real and tangible that someone can look at and say “well, yes, here is code that works and it looks like this and it has a nice architecture and the person knows what they are doing.”

Damian: Having said that, I know there has been a bit of a trend lately as well. That is, if you’re applying for a job, show us your Github account so we can have a look at all the code that you have written. So, there is almost a pressure for people to write code in public even if their day-to-day job doesn’t allow them to do that. So, they are almost compelled to write code outside of business hours just to prove that they are a real developer. I don’t think that is necessary. Personally, I have a problem with saying that if you’re not writing code outside of your 9-5 job, then you’re not a real programmer. I’m a little wary of that being an expected requirement for somebody. You might really enjoy it, but you might also really enjoy doing other things outside of your day-to-day job. So, there are good and bad parts, I guess, of having that.

Arsalan: Right. I think that in some parts of our industry, some subcultures within our industry, we have taken this too far. You’re absolutely right. I have talked to people and personally experienced some very strange behavior among recruiters and hiring managers. Some people who are not actually going to do the final interview or [make the] final determination will put these filters in because they don’t want to interview a hundred people. They want to interview five people or two people. They want somebody at a higher level of personnel, like Human Resources or a hiring manager, who is not actually doing the coding, to filter people out. They use a degree as a filter sometimes. We have these keywords. So, you have a keyword filter and how many keywords do you have on your resume? Then, you have a Github profile and what is your activity level? [It’s the] heat map for Github. How active have you been? That’s been used for some reason.

Arsalan: You are absolutely right. I am going to say most software developers don’t work in open source. There is no reason why they have to. What ends up happening [is that] we are creating a culture where we are saying that you have to be so passionate and obsessed with programming that that is all you want to do 24/7. That doesn’t mean that a person who writes code 24/7 is necessarily a better software developer than someone who likes to have his 9-5, do a good job, and go home and take care of his kids or play the guitar. We assume that if you are not obsessed with this, it is not going to work. In my experience, it happens a lot with startup companies where they don’t want someone who has another passion because they want them to work 12 hours a day.

Damian: That’s always the danger. Yeah. If you choose someone who is passionate, then you can see that they’re working on side projects and things for a few hours at night. Then, maybe you think that as an employer that you can utilize that time as well. I think that it is a bit of a work/life balance and I am probably a bad example of this. I tend to not write a ton of essential stuff that’s out on Github. I’ll do a little bit, but I also have the problem where, especially if my wife is working late, I’ll just keep working until she gets home. So, I’ll do 18-hour days occasionally just because I really enjoy what I’m doing. I don’t think that it is necessary for me to do that, though. In fact, it’s probably not healthy for me to do that too often. I need to have some other things going on.

Arsalan: Yeah. 18 hours a day may be taking it a little too far, Damian, but on the other hand, you have a cool job which we get to talk about now. You are a developer advocate, but not just a regular one; you are a cloud developer advocate. A lot of our listeners may not know what a developer advocate is [or] may not know what a cloud is. So, let’s talk about what you mean by a cloud and what a developer advocate is.

Damian: So, we’ll start with the cloud, I guess, because I am a bit of a Microsoft person. I work for Microsoft at the moment. So, when I talk about Cloud, I am usually talking about Azure. But, IWS and Google Cloud platform are options as well and they have awesome features. There are really just those three big players in Cloud at the moment. So, when I talk about cloud, I am talking about the developer cloud. There are kind of two types.

Damian: There’s a consumer cloud where you might look at things like DropBox or Apple iCloud or things like that where your general consumer’s photos go, their emails go, and all that kind of stuff.

Damian: The developer cloud is really where programmers will put their stuff. So, rather than having a web server that you host like a rack or a service sitting in an air-conditioned room somewhere in an office that you have to maintain, you can put all your stuff on a cloud that Microsoft, Amazon, Google, or someone like that manages for you. You don’t have to worry about the maintenance of the hardware and, in most cases, you don’t have to worry about the maintenance of the operating system either. You just give it your code; give it the stuff you want to run and it will run it for you. The company will run it for you and they will charge you based on usage, in most cases.

Damian: Lately, the developer clouds have started expanding a little bit in what they can do. So, traditionally, it was more like a server that you can rent, essentially. But, these days the cloud is much more about functionality. So, think of things like cognitive services in the Azure cloud. You can upload a bunch of photos and tag people in what’s in those photos. Artificial intelligence that Microsoft hosts for you will learn about your photos and be able to answer questions that you have later on. You can give it another photo and ask “is John in this photo” and it will give you an answer based on the information that you’ve given it.

Damian: So, it’s really kind of expanding with all the stuff that you can do, but not needing [you] to maintain your own hardware [or] write these complex AI algorithms and things like that from scrap. So, I guess I’ve kind of gone off on a couple of little tangents there, but that’s really what the cloud is. It’s more or less hosted computing and hosted stuff like that. You don’t have to manage [it] yourself. Microsoft, Amazon, Google, or someone like that will manage that for you.

Arsalan: That’s great. That’s a lot of information, but I want to talk about the history of what happened here. Initially, maybe 20 years ago, if you wrote a piece of client-service software or web-based software, then, it needed to run on a powerful computer that everyone in the world could access. You could run it on your own computer, but it isn’t always going to be there and if you have a lot of users, it isn’t always going to work.

Arsalan: Back in the day, we used to run web servers off of our own desktops. I am guilty of that. But now we have realized that we need servers. We need a dedicated hardware machine that doesn’t necessarily have all of the stuff that you need for a computer or for a consumer. I mean, it does have a display, maybe, but it’s very fast. It’s a fast processor. It has a lot of memory. It can allow a lot of people to connect to that computer at the same time. So, that’s where we start and then we make it bigger and bigger and it costs a lot of money to have this running.

Arsalan: We then have to make sure it’s cool because it can generate a lot of heat. So, cooling it is expensive. Then a fault appears and you have to replace it and you have downtime. That used to happen also. I remember back in the day, a corporate server that was running exchange and handling emails and so on would go down occasionally. Then, we would have to wait until it was up again. So, going through that now, a company that has a lot of servers can say “why don’t you rent mine and you don’t have to take care of it. We’ll take care of it for you and then we can take care of millions of other people.”

Arsalan: Now, it becomes something like a utility. So, you pay for what you use. Behind the scenes, if they have to replace hard discs or put new servers in, you don’t have to worry about that. So, now you have a computer that you can just rent in the cloud. So, that’s where I think this whole cloud thing first started, correct me if I am wrong.

Damian: No, go ahead.

Arsalan: You could call it infrastructure as a service. Then, after that, people built software on top of that. So, you can have software as a service like Salesforce that other managed platforms that are running there on top of some kind of cloud infrastructure that you can use as a consumer. You will not know that it is running in the cloud. Or, you can offer it to your customers. Then, we moved on to the platform as services where we are just abstracting away even just the infrastructure or framework around it. All you have to deal with is code.

Arsalan: I think that I am using the correct terminology here. If I have a piece of code that is supposed to run inside of a Microsoft server or in a different type of web server, then maybe Microsoft can give me that web server and I can just tell Microsoft where my code is and to run it. Now that we have Github and the ability to clone and all the wonderful things that we can do with ‘Git,’ I can just tell Microsoft where my Github or my bitbucket repository is. Then, you can just pull the code and build it. If it works, then deploy it. That’s another way. I don’t have to know that there is a computer.

Arsalan: Later on, we moved into even more specialized cloud services where we are not even doing an entire program. We are doing just a little snippet. I can provide this little function for you and it’s going to run in the cloud and there is going to be a server behind it. There’s going to be a hardware processor for this Github memory, location, and all at full tolerance and patches for the operating system. I have no knowledge of that and I don’t care. All I want to know is that this function will run. So, it’d be more like some Lambda functions or cloud functions. I don’t know what Microsoft is calling it.

Arsalan: Lots of platform providers are providing this feature now. So, I see that as an observer. I’m looking at this whole cloud phenomenon as an evolution. It’s almost come to a point where you are expecting that. You are expecting that everyone who has a large infrastructure and who have a lot of users or who may have a lot of loads, they are not going to use their dedicated servers, but something on the cloud. I don’t know if you could talk a little bit about some of the new features that you see evolving in the cloud.

Damian: Yeah, I think you’ve got that trend exactly right. More and more stuff is being taken out of your hands if you liken it to an analogy of electricity. If you had a little generator in your house that would generate electricity, then you have to maintain that bit of hardware and so on. You have to maintain the wiring and stuff like that. Maybe an electricity company can wire it up to your house. Then, you have to worry about the wires that run through the walls of your house and all that kind of stuff. Or, you can just rent a place that has power plugs on all the walls. As long as something works, as long as you have the right power plug, you can just plug it in.

Damian: That’s kind of how it is with this platform as a service thing. You have code that is a particular language and is Microsoft or Amazon or Google, and they know how to execute code in that language. You just have to provide the code. You don’t have to say “well, this isp.net code needs to run on an IS server and it needs to be on this account and all this stuff.” You can just say “here is the code that I want to run when someone hits this URL.” Azure functions give you that ability. If you give Azure a snippet of code and tell it ‘when you do this, execute that snippet of code.’ It’s similar to the AWS Lambda that you mentioned as well.

Damian: So the trend, I guess, is probably taking more of that away from the developer. You don’t need to worry about the things that are pretty much commodity if every time you run a web application it was on an IS server running on a Windows machine and you gave it C# code, but you have to set up that Windows server on that IS machine. Then, let Microsoft do that for you.

Damian: There are other advantages that you get for this as well. Let’s say that you have an e-commerce site that operates in the US. It might have a lot of traffic between 5 PM and midnight every weekday. Yet, between 3 and 4 AM, nobody is visiting that site. If you had your own server, whether it’s your server or an infrastructure server, a rented server from a cloud provider, then you have to worry about what electricity that server is using when nobody is using it. We need to have a machine that is capable of handling the largest load but can also go down to nothing. So, we are wasting all this electricity and power. If you use a cloud provider for your application, and you have them scale it depending on how many people are hitting the thing, then you are not actually getting charged anything if nobody is hitting your site. Suddenly, if you hit a major news program or something and you have millions of people hitting your site, then Azure or whoever it is can scale your application or the hardware behind it up to handle that load. You don’t need to worry about those intricacies. So, that’s another advantage of doing that. Just give it the code and letting Microsoft, Amazon, or Google work out the stuff that is a bit painful to manage yourself.

Arsalan: That’s true. I’m a big proponent of adopting the cloud as your backbone because I, personally, don’t enjoy doing a lot of the infrastructure work. You have to do it when you’re building something from scratch or when you’re testing it. But, for regular maintenance, I don’t know of any developer who likes doing that. So, I appreciate all that. However, I’m just thinking of the conversation we had before we started recording. Your focus these days is on DevOps.

Arsalan: We’ve had DevOps discussed on this podcast before where you are doing some developing and some operations. You’re actually doing something with infrastructure. You’re not just writing code. Let’s take 30 seconds to talk about what DevOps is and then I’ll ask you my question.

Damian: Sure. DevOps means a lot of different things to a lot of different people. I come from a software developer background. So, when I think about DevOps, I think of it as reproducible ways to deploy my code, test it successfully, and make sure that everything works the way it is supposed to work. Microsoft actually has a definition for DevOps, which was written by my boss, Donovan Brown. It is the union of people, process, and products to enable continuous delivery and value to our end users. It is really broad and really just refers to changing the way you operate so that you have a focus on delivering value rather than writing a particular feature that’s on your backlog, for example. That value could actually be things like scaling up your website if you have a lot of traffic. Or, it could be having the ability to recover from a failure if there’s a problem in one of your data centers. But, really the focus is on how you can quickly and repeatedly push software or infrastructure changes out.

Damian: If you come from DevOps with a background in systems administration and operations, there’s a lot more emphasis on making sure that your infrastructure is tolerant, things are able to be repaired more quickly, and you can rebuild servers if they need to be rebuilt, and so on. It all fits into the idea that DevOps is delivering this stuff to your users in a way that adds value to them and quickly and efficiently doing your best so that it works the way that it’s supposed to work.

Arsalan: I think that’s a very good definition. The way that I’ve heard it described by some other people who I’ve listened to in the past is that essentially you’re taking responsibility not only for the correct function of your software but also the correct operations. That means that if something is wrong in the infrastructure or there is anything wrong that stops your production site from functioning, then instead of having two different people (one responsible for fixing the code and pushing it out and the other person for making sure that it keeps running) you combine these two roles into one person. You are responsible for both.

Arsalan: So, my question was that if you think of DevOps like this, it makes sense if I’m running a hardware rack in the back of my office, then I [also] have to manage many different things. It makes sense for efficiency’s sake. The one person who knows the product or the software intimately would be responsible for making sure that it runs and would hope that once you’ve identified and ironed out the kinks that it continues to run. If there’s a problem that pops up, that same person is notified [because] they are familiar with it. That makes sense, but I’m wondering how that works in the cloud because now I feel that a lot of those responsibilities are taken over by the cloud company. Microsoft is doing the patches and maybe even pulling my code down and they are deploying it. So, does that mean that we don’t really need DevOps anymore?

Damian: No, I don’t think so at all. So, it does change a little bit with the cloud, but rather than the busy work of making sure that patches are up to date and you have the appropriate network activity and things like that, your emphasis can be more of making sure that everything is running correctly and efficiently. [That’s true] even if you back up to the deployment of the software where your job may have previously been provisioning a server, ordering something from a manufacturer and getting it in, putting it into the racks, wiring it up, installing all the software and operating systems, and making sure that everything is right.

Damian: You don’t have to worry about that stuff anymore, but you still need experts who can say what this application means. This is what this application needs to run. So, the traditional DevOps role, traditional operations role, can transition to “well, the resources that we need to run this application are these things. There’s a web application that runs under app services.”

Damian: In Azure, for example, here are the scaling settings that we need. Once it reaches a particular percentage of usage, it will then scale up to another one. Maybe we need to separate one resource group from another to provide a bit of isolation. Here’s an entire test environment that’s going to duplicate that. More importantly, here’s the monitoring that’s required. Here are the thresholds that mean that we need to look at something that’s going wrong. If there are more than these many exceptions in this area over a particular time then you need to be notified. We need to make sure that the information we get is such that we can identify what the actual problems are. So, there is still plenty of work left to do within that respect.

Damian: In terms of the actual deployment of the software, there’s a lot that goes on. If you’re writing a website, for example, it’s not really enough to say here’s my web application and there’s my code and that is my website. Do the sync whenever it’s required. Usually, there are plenty of other things that need to happen.

Damian: There are databases involved. There are other backend systems that need activity. There are notifications that need to go out to people. There are approval processes to get things approved to go into production. So, that whole process becomes part of the DevOps role. When I say DevOps role, by the way, this is something that the team should own rather than having an individual DevOps team or DevOps person. Ownership should really belong to the entire team. You may have operations specialists. You may have monitoring specialists. You may have software – the programmers themselves who are specialists on the application as well. But the team as a whole owns what ends up in production.

Arsalan: Yes, I think that’s an excellent answer. DevOps is alive and well, folks. So, if you are listening to this podcast and you are having second thoughts about DevOps as a feature of your career, don’t give up. There is hope.

Arsalan: In this podcast, we like to talk about the technologies that people are working on because it’s really fun and exciting to know that there are so many possibilities and this is an opportunity for us to learn. So, I really appreciate it, Damian, that you gave us a chance to learn from you about your experiences and what you are passionate about.

Arsalan: We also want to talk about how you got started and how you got your first break or your first job because a lot of us are struggling. We may have some coursework in computer science. We may have a degree. We may have some experience doing side projects. We may have a little bit of experience, but a lot of us are still struggling to get our first jobs. So, from your point of view, I’d love to know you got your first job.

Damian: My story about getting my first job is probably not terribly exciting. I finished at the university, put a resume together, and then started applying for positions. The first job I got was a government one. It was in a language that I hadn’t really touched very much, which was all the .Net stuff. So, it was very traditional. I finished my degree. I applied for a job and went to a few interviews and then got an offer. Subsequent jobs, though, have been very different. There have been a few that I’ve applied for, but, especially lately, I’ve kind of followed what I’m interested in.

Damian: The really great thing about software, I think, is that there are so many different areas that you can go into. You can fall into stuff that you really like and it can be completely different from the person next to you. I have a bunch of people who I went to the university with. We did exactly the same degree, but we barely speak the same language when it comes to writing software, even though we are technically software developers. So, there’s a huge range. I think that [for] the climate I was in at the moment, it was just important to get a job, any job.

Damian: I don’t know if that’s the case anymore. I think that these days it’s more important to find something that aligns more with what you enjoy in software rather than just picking up whatever is available. But, if that is what you end up doing, picking up any job that’s available, you can definitely lean towards the stuff that you do enjoy, which is kind of where I ended up.

Arsalan: Sometimes you have to take a few steps before you get to your destination. Here’s what I’ve noticed. In a lot of cases, I’ve found successful software developers. When they started, they did not start in jobs or even in places where they wanted to be. But, they lucked into being surrounded by other people who are really knowledgeable and helpful, even though they were doing something else. Just by being in that environment, they were able to learn and grow. So, there is the opportunity.

Arsalan: Obviously, if you are a new software developer and you want a job, there are many ways of getting it. We talk about this on this podcast. If you want to learn more about some of the different ways of how you could get a job, then go ahead and email me at us@mentoringdevelopers.com. I will reply and send you some resources and we can start a conversation.

Arsalan: If you could start over, Damian, what would you do differently as a new developer? Are there things that you did that you kind of think “boy, I wish I hadn’t done that.”

Damian: I don’t know that there’s anything that I wouldn’t have done, but I definitely would’ve done some things a bit earlier than I did them. It took me a while to realize that I could pursue the parts of the job that I was interested in. For the first seven or eight years of being a programmer, I thought that I was at the mercy of whoever was employing me. Every bit of software development that I did was going to be based on exactly what my boss told me it was going to be. I was going to be pigeon-holed in a particular language, a particular type of software and things like that.

Damian: It took me about eight years to realize that I can read stuff that I’m interested in. I can emphasize the parts of the job that I like, even without really changing my job. We have a saying in my group of Microsoft DevOps-focused Cloud developer advocates that you shouldn’t ask permission to do your job properly. So, if you, as a programmer, think that it is really important for you to speak to the customer about what they actually meant when they asked for a feature, then you shouldn’t need to ask permission to speak to the customer. The same goes for tests. If you think tests are important, you can do that. That’s part of being a professional.

Damian: That led me eventually to where I am now. I thought that one of the things that I really enjoy was learning new stuff and teaching it to other people. So, I started doing that. I would find a bit of code that I had to write as part of a feature – that was my job description, essentially, to write this particular feature. I would find a part of that, that I was quite interested in, and I dove a little deeper into how to make that work really well. Then, once I learned that there was this great algorithm for compressing images or something, which was fascinating, I would end up teaching other people those bits of information because I found that very interesting.

Damian: That led to this whole developer advocacy thing where it has become my job to learn things and then teach other people. So, even within my own job, I was able to focus even more on the things that I liked and maybe my next job would focus even more on it. The one after that might focus even more. You make your own path, rather than being pigeon-holed. It took me a long time to realize that I was able to do that.

Arsalan: I think this is excellent advice. Obviously, you can think outside the box. A lot of times, our managers or the people who are managing us really know what we should do. A new developer would go in and think that the people who are managing them or who are more senior know exactly how to tackle every situation. So, they need to be told what to do because [they] don’t know and that person knows everything. In a lot of cases, we are all learning. When we start a software project, we may not even know what to do even if we have 10, 15, 20, or even 30 years of experience.  We may have never done something exactly like that. So, if a junior person comes up and takes initiative and reaches out to a customer or writes tests, most of us are going to appreciate that.

Damian: Yeah.

Arsalan: I have been in situations, Damian, where it is not appreciated. So, let me be clear. Writing tests or talking to customers is scoffed at. It happens in situations where maybe some of that is not billable or some of that does not add to the bottom line of the company. Those types of political things happen.

Arsalan: For most organizations, especially for in-house developers or for people who are really invested in the software product, they will appreciate any initiative that you show. That means that they don’t have to think for you. You can think for yourself. You are going to be an asset to the company, not a liability.

Damian: Yeah, that’s exactly right. I’ve worked in plenty of those places as well where you tested a few things that you wrote if you had time, but, of course, you never have time. In those scenarios, I think you just have to do your best at what the best thing is for writing good software and delivering value to customers. Yet, at some point, if you’re not getting any momentum, you can’t change that culture. If you feel like it really needs to change, then maybe what really needs to change is which job you’re in.

Damian: There are organizations that are going to say “we don’t have time to do DevOps. We don’t have time to do Agile. We don’t have time to do tests.” There’s not a lot you can do to change that. What you can change is where you work.

Arsalan: What’s exciting about 2018 and beyond is that there are so many jobs regardless of where you live. There are a lot of remote jobs as well. If you live in a city or a town where you don’t have a lot of opportunities, maybe there is an opportunity somewhere else. So, don’t give up. If you’re in a situation that is hurting you in becoming a good software developer and a good professional, a lot of times our work environments are not professional, you should feel free to move on. Even if you are at a dream job, you shouldn’t think that you should retire from there.

Arsalan: I think that our society as a whole has moved on from that idea of getting a job and then staying there forever. At least in the US, the employers don’t guarantee you a job at all. So, you shouldn’t feel obligated to stay there until everything falls apart. That doesn’t mean that I encourage job-hopping. I’ve seen some really aggressive job-hopping in my career where some people would change jobs in weeks or in a couple of months. That doesn’t give you anything.

Damian: Yeah, definitely. You could try to change what happens in an organization before jumping away. I think the average is about two and a half to three years in a job and then I leave, but not because I hate the place and can’t work there anymore. I leave because I don’t feel like I’m growing anymore. I’m doing the same stuff day-to-day. I’m not learning anything new. It’s not working out for either party then. They basically have someone doing the exact same thing that anybody else could do. I’m not learning or enjoying it and it’s time to move on.

Damian: If something is not working, then it would be great for the company and for you if you were able to change that in the organization. You can’t do that in a week. So, give it a go for a while and then if it’s just not working, then maybe look at other options. I think that’s good advice.

Arsalan: The most important thing that I like to tell new developers is to not give up. Stay in the game. If you stay in the game long enough, you will succeed. There are plenty of opportunities out there. There is something just right for you. Yet, obviously, if you don’t like software development, then don’t be a software developer. But, if you want to be a software developer, let nothing stop you like a bad job, a bad boss, bad technology, or bad choices. All of that can change.

Arsalan: I’ve seen companies change from within and be completely transformed. A bad boss can leave and a new boss can come in. Or, maybe you could become the boss. That happens too. I’ve even seen situations where a company is using really old technology because that’s all they know. Then, all of a sudden, there’s a new budget and more money. If you talk to the right people, the technology changes and now they are doing Agile and Scrums and they have Kanban boards going and you’re now working on an open source or some other technology that you’re excited about. So, it can happen. Or, you could just move on and find another job. Maybe, if you have a couple of years’ experience, you could go out on your own. I’ve seen people become independent consultants. I’ve done that and sometimes that works out really well.

Arsalan: If you’re listening to this podcast in 2018 or 2019 and so on, you’re in a good place. This is a good time to be a software developer. Right, Damian?

Damian: Definitely. I would agree.

Arsalan: It’s been a pleasure talking to you – so much amazing advice. I think people are going to love this episode. There are so many more questions that I could ask you, but we’re coming up to an hour and I think we need to stop. Before we go, I want to give you a chance, Damian, to talk to my audience and give them a message if you like. Give them advice or talk about something that you’re working on, that you’re passionate about, and that you’d like them to check out.

Damian: There are so many things. One thing that I would say as a result of me starting to work at Microsoft about 8 months ago is that Microsoft is a very different company for developers than it used to be. A huge amount of our code is out on Github now. It’s open source. Their whole developer advocacy group, which is the group that I’m part of, our job description is to literally help people succeed.

Damian: If you’re in the industry and a little jaded about Microsoft from the days of forcing upgrades and all sorts of developer stuff that went on a while ago, have another look. Azure is primarily the Linux server these days. Microsoft is one of the largest contributors to the Linux code base. I think it is the largest contributor to open source according to some Github stats as well. It’s a very different story these days. I’d have another look.

Damian: If you want to learn how to use any of Azure, a great starting point is docs.microsoft.com. There are some work-throughs, videos, and all sorts of stuff. You can also reach out to any of the Cloud developer advocates, too. We should be very easy to find. I think it’s developer.microsoft.com. That’s our job – to help you succeed, and to some extent, whether you’re using Microsoft or not. So, reach out and if you have any problems with anything, we’ll have a look at the docs. Things have changed at Microsoft.

Arsalan: If you want to talk to Damian or you want to send him a message and can’t find him, you can always find me at mentoringdevelopers.com. This is going to be episode 66. You’ll be able to find links for everything that Damian is talking about, show notes, and transcripts at mentoringdevelopers.com/episode66. It’s easy. So, if you want to find another episode, like episode 60, all you have to do is change it to mentoringdevelopers.com/episode60. So, all URLs are fun like that. I am also very responsive to email at us@mentoringdevelopers.com. If you want to send a message to Damian and you want to ask me and Damian something, I will make sure that I forward your request to Damian if you want. Or, you can reach out to Damian directly.

Arsalan: Alright, Damian, it was a pleasure talking to you.

Damian: You too, Arsalan. Thank you very much for taking the time.

Arsalan: Thank you so much, and thank you, everybody, for listening. See you later.

[convertkit form=4889308]

Important Links

• Twitter: @damovisa
• Blog: https://damovisa.me
• Cloud Developer Advocates: https://developer.microsoft.com/advocates
• Microsoft Docs: https://docs.microsoft.com
• What is DevOps?: https://www.visualstudio.com/learn/what-is-devops/

 

Thanks for Listening!

Do you have some feedback or some advice for us or our audience? Please give us a review on iTunes or Stitcher and share your thoughts.

If you found this episode useful, please go ahead and share it with your friends and family. You can do that easily using the social media buttons at the bottom of this page.

Subscribe to the show on iTunes or Stitcher (for Android users) to automatically get new episodes every Tuesday.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

Holly has learned a great deal about mentorship as both mentee and mentor during her time in the tech field. In episode 64, she shares that knowledge with you and Mentoring Developers Co-host, Sara Ines Calderon. Be sure to listen in for all the juicy details.

 

Holly’s Bio:

Holly has over a decade’s experience in web development and server management.  Besides being a lead developer at Praxent, Holly is the Executive Director of Women Who Code Austin, where she leads a network of 2600+ women in tech.  Prior to software development, Holly served at a disability non-profit.  She an has expansive knowledge of the challenges faced by individuals and families affected by disability.  Merging her experience as a software engineer and disability advocate, Holly is determined to see software applications and technology in general become more accessible and inclusive.  She is leading the charge on her team to implement accessible features and also being a voice in the technology community for those who are underrepresented and neglected.

 

Episode Highlights and Show Notes:

Sara: Hi, everybody. This is Sara Ines Calderon, and you’re listening to Mentoring Developers. Today I’m here with my great friend and someone who I admire very much, who’s actually been a very great mentor to me and a mentor and inspiration to so many other ladies I know here in Austin, Texas, the one and only Holly Gibson. We’re going to talk to her about her journey into technology and some of the challenges she’s faced and where she’s at now. We’ll also talk about her work with Women Who Code Austin. So, Holly take it away and tell us a little bit about yourself.

Holly: Hi, Sara Ines. It’s great to be here on your podcast on Mentoring Developers. I really care about this topic so it’s something that I’m excited to talk about. A little bit about me, I am a developer at Praxent, which is a custom software agency here in Austin. I didn’t start out as a developer. I have a degree in theology, which is a very far move from software development. I went to a coding bootcamp about four years ago and having mentors along the way to get to where I am today was so important.

Sara: That’s cool. Tell us a little bit about your life. You said you got a degree in theology. So, how did you go from theology to wanting to do a coding bootcamp. Then, tell us a little bit about some of the jobs that you’ve had before this job, where I just want to say that you mentioned you were in charge of some of the job groups framework. You are a senior developer or architect. What step made you want to go to the coding bootcamp? How are your jobs before you got to this job? Also, tell us a little bit about how along the way you founded a chapter of women who code in Austin, despite having your hands full with code school.

Holly: Yes, of course. In college, they had a couple of classes in web design. I took them. There was one class in basic JavaScript. This was over 10 years ago. So, it is not the JavaScript that we use today. It is very far from it. I liked it. I liked the ability to create things. I thought it was a lot of fun to make the computer do things, but I didn’t know how to find a job with the degree and theology. So, I went to marketing and I did that for a while.

Holly: When I moved to Austin four years ago, I learned about code schools. There was one that was coming to Austin and it was perfect timing because I was looking for a new job and I wanted to do something different than I had been doing. I had been working in the nonprofit arena will, which is great and very fulfilling, but it doesn’t pay very much and I felt like I had mastered all the skills that I needed to run programs and be an event planner. I wanted something more challenging. So, I went to a code school, Makers Square, which is now rebranded to Hack Reactor.

Holly: It was hard. It was one of the hardest things that I’ve ever done. I felt stupid every day because you’re learning new things and there’s so much to learn that the information is so broad. Learning to program sounds daunting in a way, and it was. Through the code school, I was able to build a couple of apps and that felt really great, but I still felt that I didn’t know anything. So, I decided to start the Women Who Code chapter because I wanted to meet other women in tech. So, I would have friends. I was new to this city. I was new to the industry. I needed a job. I needed to network. I met some people from the San Francisco Women Who Code chapter and they wanted one to start in Austin, and they were looking for someone to help. So I agreed to help.

Sara: Little did you know that help meant doing it.

Holly: Yes, help meant a part-time job. It started out as a very small group of us. There were maybe 10 or 15 women and we would get together and hack on different projects and Google together because a lot of times you don’t know the answer and Google is your friend.

Sara: Sure. That’s awesome. So, you had a couple of jobs before this job. It sounds like you started in a kind of peer mentorship when you are first still in code school because everybody knows a little bit about something different. So, together, you know more. It sounds like you were doing that. I know that when she started to work. You were also consistently pursuing mentorship as well, which is something that I’ve always thought was admirable.

Holly: Yes. So, my first job out of code school was at a startup. It was an education startup. There were six employees and I was the only technical person. I was the only developer and I did everything for managing the server, the database, and the web application, and I had no one to ask advice from. The CEO barely know how to program her iPhone or set up her apps. I was helping her all the time. So, I had to find someone because I didn’t know anything about databases or servers. I barely knew the framework that we were using for the app. We were using Rails and I had just three months experience from the code school.

Holly: So, I went to the local Rails meet up, and I heard some of the speakers talk. Some of what they were saying really connected with me. It was very interesting. So, I went to the speaker after word and was asking questions and I explained my situation that I was working at a startup by myself and I didn’t have anyone to ask questions from and he said that he would meet with me on the weekend to explain some of the things with me.

Holly: When we met, it went really well. We really connected. So I thought, okay, I like this guy. He seems very friendly. He seems like he knows what he’s talking about. Maybe he’d be willing to meet again. So I asked him if he’d be willing to show me some more stuff. So he agreed and said he is usually there at this coffee shop on Sundays. He said that if I wanted to come there, then he could help me. So I went there every Sunday for four months just to get as much information as I could out of him. I’d buy him coffee. I’d buy him a taco or whatever he needed and I would ask him what books I should be reading. Which blog should I be reading and who should I be following on twitter? What are sources of information that I can trust? What should I be learning? So, it was really helpful to have him guiding me.

Holly: Mentors provide information and knowledge. They see where we need to improve. They also offer encouragement and help us keep going. There were a lot of times that I felt very frustrated at the start up. I felt like I didn’t know what I was doing, like I was an imposter, like I shouldn’t be there, and it was terrifying to be by myself. I like this quote from Oprah Winfrey: “A mentor is someone who allows you to see the hope inside yourself.” So, by meeting with the mentor I saw that I was learning and growing and that I could keep going.

Sara: I think that’s a really important point about mentorship. I think the best mentors are the ones who can point out how you’ve grown because you can’t always see that if you feel like you’re treading water and barely keeping your head above water. You’re not going to notice that you’ve just swam 5 miles. So, that’s a really good point. I consistently love hearing those stories. I certainly don’t wish that on anyone and I hope you never feel like that again, but it’s a great story now.

Holly: Yes. I survived.

Sara: That’s really cool. So, tell us a little about through Women Who Code, how you have the opportunity to meet all sorts of people, mentees and mentors. What are some of the things that you think are most important for someone who’s learning how to be a good mentee or how to look for a mentor? As you yourself are a mentor to others, what are some of the things that you think are important to keep in mind if you’re going to be a mentor?

Holly: So, I’ll start with the first question. How do you find a mentor? I think MeetUp is a great place to start if there is a MeetUp on a topic that you are wanting to learn more about. For me, being a software developer, Rails was the software framework that I using. So, I went to a Rails meet up. Now, I’m mostly doing Javascript and React. So, if you can find a React meetup, like Women Who Code has a React meetup. I know you’ve been mentoring women and learning React even if it’s just learning alongside them. You guys are mentoring each other. In your company, if you can find a developer who knows more than you do, you can set up office hours. We have a senior developer at my company who I meet with once a week. I gather the questions during the week that I want to bring to the meeting so that he can then help and explain things to me.

Sara: Is that a formal company process or did you ask to put that in place?

Holly: I asked to put that in place. We don’t have a formal process and I think that a lot of small to mid-sized companies don’t have a mentoring process. I wish they did. So, I kept going to them with questions because I knew that they have more experience than I did, but because they’re busy trying to meet deadlines and stuff, they couldn’t always answer my questions. So, I asked if it would be okay if we did office hours like once a week and I could bring my questions to them then and it’s all on the calendar. He said that was fine. I asked the supervisor if it was okay if I did this because an agency and we bill our hours. He said yes and that this was learning time and applies to what we are doing.

Holly: So, I did it and since then I started office hours for two other individuals  who I mentor because I saw that they wanted to learn things. One of them was a PHP developer who wanted to learn React and some of the Javascript framework. So, I suggested that we do office hours and I could help her learn. So, I’m always trying to find a mentor, but also willing to pay it forward.

Sara: That’s really interesting. I really like what you said about finding someone within your company and creating a process. Just because one doesn’t exist doesn’t mean that you can’t create one. So, that is one of the things that you think is important to be a mentee and how to find a mentor. Tell us about, now that you’re a formal mentor through your work, what are some tips on being a good mentor? As you mentioned, I do run a few meetups now. We have a React meetup through Women Who Code Austin. We have Rockin React. Holly started this theme at Women Who Code Austin where everything is alliteration.

Holly: Yes. We have Lightning Learning and Rockin React.

Sara: Rockin React. Was it Mobile Madness?

Holly: Yes. It’s memorable.

Sara: It’s memorable. So, why not? It’s fun.

Holly: Learning should be fun.

Sara: Yes, learning should be fun. So, I guess one of the things that I struggle with as a mentor, especially in groups, is how do you provide value in groups because there are people from all different levels and experiences? Like I learned last week, just because somebody knows something, it doesn’t mean that they are going to learn something new by going over it again. Sometimes having to explain it to someone else can help you formulate something in your mind. So, what are some things that you’ve learned as a mentor? How do you be a better mentor to people?

Holly: I learned something while I was mentoring through a code school here called General Assembly. They set up a mentorship program for their students. I was mentoring one of their female students and every week I would ask her “what do you need now?” That’s because things change. In my own experience, I’ve had a situation where the mentor had a curriculum of things for me to learn, but many of the times I came, he would ask if there was anything else that I wanted. There was always something else I wanted because usually, if your new, what you need is what is most pressing. My mentee was going on interviews. So, what was most pressing for her was to learn how to do coding interviews. If I’m on a project, the most pressing thing for me is how to get this project done. So, as a mentor, you need to be flexible and ask what the mentee needs because you are there to serve them. They are not there to stroke your ego.

Holly: So, it changes. Sometimes I did resume writing with her because she needed to brush up her resume. Sometimes we went over code challenges. Other times she just wanted advice. For example, sometimes she had different job offers and she wasn’t sure what she should do or how she should negotiate her salary. I just gave the best advice I could and knew that she had to make the ultimate decision. My advice may not have been exactly what she needed, but I could give her stories from my own experiences and from other peoples’ experiences and then leave it up to her to decide whether or not this was what she needed to do or if she needed to find something else. The thing to remember is that their situation is not your situation.

Sara: That’s a really good point. So, what do you do if you are mentoring someone and they ask you something that you don’t know? How do you deal with that?

Holly: I would say that I don’t know. That is so important. I think you should never set yourself up as the expert who knows everything because we don’t know everything. Also, they are going to figure out that you don’t know everything and their opinion of you is going to be lowered if you lied to them. It also teaches them to be okay with not knowing things themselves. You want to be able to say to them that you don’t know and suggest “let’s research that, let’s Google it, or let’s find someone else who has  an answer, or find a book that may have the answer.” That will teach them how to find the answer for themselves next time so they don’t have to ask you. Also, when they are on the job, they can go to a senior developer or supervisor and say that they don’t know how to do something and not worry about being shamed or something.

Sara: That’s really cool. I like that. So, let’s talk about how there’s mentorship in groups. I think that’s something that you have a lot of experience in. I have some experience with it since we started the React meetup. I’ve found that it’s different.  I don’t know that I’ve gotten a lot of one on one mentorship, certainly not as much as I wanted. There is such a thing as group mentorship where you can be around people who make you feel like you can figure things out and it actually makes you figure things out. The reverse is also true. You have people who tell you you can’t do stuff, or they ignore you, or they treat you like your not good and that can make you feel like you don’t know and so you won’t even try. How have you experienced that? You were Women Who Code for a few years where it was basically just you and you’ve been able to build a really cool board and group of people that have all been able to build the organization in their respected areas. How has that been good mentorship to you and what have you observed about mentorship since you’ve been involved with all these thousands of women over time?

Holly: With Women Who Code, specifically, I guess group mentorship, we have a variety of events. So, there are different offerings for people to decide what they want whether it’s React, Python or small topics like Lightening Learning, which is short, five to ten-minute topics. So, people can come to what they want. We always leave room for questions. So, all the women feel like they can ask questions and we do our best to answer them. If you’re going to do group mentorship, you definitely need a topic. All of our events have a topic of some sort. I think the best one for mentoring would be our Hacking Hangouts because people actually bring a project that they’re working on so they can ask for specific advice.

Holly: When I first started it, I knew I couldn’t answer everyone’s questions and help everyone at the same time. So, I would have everyone go around and talk about what they were doing and what they need help with. So, if one person had a Java question and someone else was a Java developer and I wasn’t a Java developer, I could match them. In group mentoring, if people are coming with individual needs, it’s great if you can match them up with someone and make it more one on one.

Holly: We have found through one of our events that people will meet each other and they have similar things that they’re working on. So, they will meet outside of the event, like at a coffee shop. For example, they are both looking for a job and they go over code challenges together or they are both trying to learn React together. So we’ve also seen informal mentoring or peer mentoring forms. So, that’s really cool. So, I would say to treat everyone friendly and make them feel safe so they can ask any question they want. Do your best to help them and if you don’t have the answer, try to direct them to a good resource.

Sara: Sure. That’s aweswome. That’s really good. One thing that I found really interesting about some of the stories you’ve been telling us is that it sounds like you’ve never really had a mentor who was another woman, necessarily. It also sounds like a lot of the people who have been mentors to you have been men. So, why don’t you talk a little bit about that? I’ve had a different experience. Like most people, I’ve worked mostly with men. It’s hard to find these senior folks who wanted to mentor me. Then, I did find one and then I had to find a new job. So, that was very short-lived. I did learn a lot when I was working with him. Is that something that people talk about to you or is it just something that people take what they can get in terms of finding mentors who are similar to them, demographically speaking?

Holly: I think most people take what they can get. Peoples’ time is precious. We’re all busy and stretched in our modern society. So, if you find someone who is willing to meet with you, jump on it. The first mentor I had, I didn’t like the first time I heard him speak. I thought he was really critical and a little disgruntled. So, I didn’t want to have him as my mentor. Then, I talked to him in person and I found that in person, he was actually very nice. He does like to play devil’s advocate, but I learned that over time. For example, he likes to critique and criticize, but he was passionate about teaching. So, I could set aside his critiques of everything in the world and programming and theory and things like that and learn from him because he did know software and he did know what gaps I had. So, for me, since he was willing to give his time, I learned to set aside my personal preferences.

Holly: The next person I found was a personal friend of his and I met him at another event. It was just an after hours drinking. We started talking about programming. He had some strong opinions and I asked him why because I find that mentors who want to teach, they do so because they care about the subject. They care about quality and they are passionate. They want to see the next generation of developers have good skills. He was really passionate about Haskell. It was a language I knew nothing about. So, I asked him about Haskell and how it worked. I told him that I’d be interested in learning it because I didn’t know it and didn’t know if I’d ever be able to find a job with it because it’s kind of an obscure language, but at least I could learn theory from him. So, he was really excited to teach me Haskell.

Holly: So we met every week for a year. It wasn’t easy. I had to drive across town in traffic after a really long day at my job. Yet, after that, I was able to talk about Haskell in one of my job interviews. Even thought the job wasn’t in Haskell, it really impressed the hiring manager because they liked Haskell and I knew that because I had Googled the hiring manager. So, I knew to bring up Haskell, but I also knew Haskell and it got me a job in Javascript.

Holly: Through that mentor, learning about this obscure language, I also learned about other things. I learned how to  and how to ask for a good salary because the programmer was a developer team manager. So, I asked him what salary range should I be looking for as I was job hunting? He said “Well, let’s figure out what your skills are.” So, he assessed my skills and told me the range that I should be looking for and here are all of the ranges and what the next range I would want to go for. I took that information and did a Lightening talk on it at Women Who Code. I told all the ladies what all the different ranges are and what skills are needed for the different ranges. So other women used that information to help them get better jobs.

Sara: That’s cool. I really like that story. Everytime you tell that story, it’s hilarious. I think that what it also illustrates is that you are going to get things out of mentorships that you don’t necessarily know about. It sounds like the young lady that you were mentoring, G.A., knew specific things that she needed. Yet, when you were learning Haskell, you didn’t necessarily know the specific things that you needed outside this nebulous idea of software theory. You ended up getting some very practical information and skills out of that too.

Holly: Yes, because I would ask questions and I think that’s another piece of advice for a mentee. When you have your mentor’s time, treat it like money. Bring your questions to them even if it’s not on that topic. We rarely stayed on topic. I’d come and he’d be ready to teach me how to profunctor optics, or something like that and I’d change the subject by asking how to my salary. So, I would bring some other questions and he was a passionate person, so he cared about helping me. He wanted to see me succeed, so definitely make sure that your mentor wants to see you succeed. They should make you feel good about yourself. Like you said, they should praise the successes that you have.

Sara: That’s cool. I also want to talk a little more about your experience working in software. So, I also wanted to ask you about something that we’ve talked about before because we’re friends in real life. It is the one thing that I think is really important in mentorship that you were talking about with this last person, in terms of very practical things like how much salary can I get. It is also figuring out where you are. I recently had a job interview that was the worst interview of my life, not because of me,  but because of them. The Javascript assessment was a train wreck, not because of me, but because of them.

Sara: At the end of the interview, he asked me where I thought I was in my career. I told him and he was really surprised that I was self-aware enough to know where I was. I can take a lot of things away from that response, but I think that one of them is that it seems that most people don’t really know where they are at. It’s something that I think that mentorship is really helpful for.

Sara: When you don’t know anything, you think a couple of things. You think that one day you will reach a point where you know everything and that will never happen. You also think that everyone knows more than you. So, once you get to be a little more mid-career, which is where I consider myself to be, you know that you’re never going to know everything and it doesn’t scare you. That’s the real knowledge gain there. They’re not terrified that you don’t know things. You’ve also figured out enough things to have a facility to figure things out. You also have a little bit of an idea of how to get to where you need to get versus when you are starting out when there are so many things and it is so overwhelming.

Sara: So, talk to me a little about how you as a mentor and the people who have mentored you have helped you figure out where you are at, how to get to where you want to go, and maybe assessing that those judgements that we get in the workplace aren’t necessarily tied to us, but are wrapped up in company politics or favoritism or whatever the case may be?

Holly: Yes. I had a weird juxtoposition of my skills in one job and then immediately in the following job. I got hired at a data science company and I was super pumped. I had been working for a year to get hired there because I had met some of the developers at a meetup and they were so smart and talented that I wanted to work with these guys. I wanted that on-the-job mentoring that I wasn’t getting at the startup. So, I taught myself Python for a year and I got through the interview. I got a job offer and started working there. The team that I was put on was so difficult to work with. They would give me the smallest tasks to do and would never respond to my questions. So, I couldn’t even complete half the tasks because they wouldn’t even work with me.

Sara: There was shockingly no documentation anywhere.

Holly: So, it was really frustrating because this was the dream company to work for. It was downtown with really cool offices, and great culture. Some of the other teams had really great people on them. I liked them, it was just the people who I worked with didn’t believe that I could do anything. They wouldn’t work with me and I was really frustrating. There was also a lot of politics and stuff going on as well. After I had been there for about four months, they had layoffs and I got laid off. I was just so frustrated because this had been the dream job and it wasn’t a great experience and I ended up getting laid off a week before Christmas. It was miserable.

Holly: So, I went on some job interviews and, thankfully, I was able to find a job in six weeks, which is pretty fast.

Sara: That’s pretty fast.

Holly: Pretty fast. So, I started this next job that I found out there, my current job at Praxent. Immediately, they told me that I was going to lead a team on a project. I was surprised because it was on a framework that I haven’t used before, but they were confident that I could learn it. This was the guy that I talked Haskell to. So, he just believed in me and believed in my skills. So, I went from being a junior developer that no one trusted to now leading this team, learning a framework I had never learned with a database I had never used before.

Holly: We got it done and shipped our product on time. The project manager told me that the last software company that this client had worked with had been six months late. They were so amazed that we made our target date. I did work pretty hard the last several weeks…I  worked about 70 hours, but I realized through that experience that I wasn’t a junior developer and I could learn. Like you said, knowing that you don’t know something, but not being terrified about that and knowing that you can learn and figure things out.

Holly: So, I’ve been at this job now for a year and a half. I’ve learned two more frameworks that I didn’t know. I’ve learned Angular 2 and React and I’ve been on some really awesome projects. I’ve built some desktop applications. I knew nothing about desktop applications and it’s been really exciting. Like you said, to be in an evironment where they believe in you and they believe in your skill is so encouraging. I love coming to work every day. I didn’t enjoy coming to work every day at the other job because I felt like no one believed that I could do anything. They weren’t working with me. Here, we are learning a lot and it can be stressful, but I also know that they believe in me and if I have an issue, I can ask someone for help. They are not going to look down on me when I say that I don’t know because they also know that they don’t know. We are all learning together. Nobody knows everything. So, it’s a complete polar opposite of the job that I had before.

Holly: I think that finding mentors and people who can assess your skills and believe in your skills is important because you might be at that company where they are not giving you a chance. So, just go to another company. If you’re stuck at this company, just keep asking for more responsibilities. Believe in yourself that you can figure it out because you will. You will figure it out.

Sara: That’s the kind of story that blows my mind. Before we decided to do the podcast that we’re having, you and I had discussed that I had also worked for a previous company where they didn’t really give me any responsibility or think that I could do anything. Now, I also started out as the only developer at this startup and everyone is so impressed with me because I’ve been able to do all this stuff. I think that is also something that I’ve learned because I’ve been building a team and we’ve been bringing people on and we’re trying to create infrastructure and procedures and stuff. Last week, I told our first hire that I was going to set the bar for him up here because I’ve learned that if I set the bar for him up here, in two months he will tell me what the better way for him to move forward on this is. I want him to be there. I want him to be better than me versus another place where I worked where you ask a question and the response is “you don’t know that.” That’s not helping people grow. That’s not helping the company get better developers. That’s something that I really appreciate about you.

Sara: The way that Holly and I became friends was that we met at Women Who Code and I was starving for mentorship. She said we could get together and she would teach me Javascript, but we ended up just becoming friends and gossiping a lot. We also learned Javascript, though.

Holly: We had a coding brunch.

Sara: Yes, we started having a coding brunch. A lot of good things came out of that. A lot of other people were able to re-negotiate their salaries and stuff. So, group mentorship is also a thing.

Holly: So, I paid it forward and she kept inviting people to join. I thought “Oh it’s just going to be me and Sara and we’re going to attack the Javascript and eat some tacos,” and she’s like “Guess what, I invited three other people.”

Sara: Yes, that was an interesting time. I remember waking up in San Antonio over a weekend and I had to get up early because I didn’t want to miss my coding brunch.

Holly: I feel honored.

Sara: So, that’s cool. Well, I am running out of things to ask you. Is there anything else that you want to talk about or any last points that you want to make about mentorship? Tell us about your career and where to follow you if they want to learn more or if they want to ask you specific questions.

Holly: The best way to reach me is on Twitter. My handle is @HollyGlot. It’s a joke for Polly Glot. Uber nerds. Get it? Sorry, I’m a nerd at heart. You can follow me there. I’m always tweeting about things that I’m learning, things in tech, and occasionallly, political rants, but we won’t go there. You can ask me questions there. We’re also at Women Who Code at most of the events. So, check them out or at MeetUp – Women Who Code Austin. As for any last advice, just breathe. What troubles you today will not be what troubles you tomorrow. There’ll be new troubles.

Sara: That’s a promise. Also, if you guys are going to be in Austin, come to our meetups because we’d love to meet you.

Sara: Well, Holly, thank you for being on Mentoring Developers. I know this was super fun for me and I hope for our listeners as well. If anyone has any questions, feel free to follow her on Twitter. Our Women Who Code Twitter is www.codeatx.com and you can follow us on Twitter @MentoringDevs as well. So, thanks, Holly.

Holly: Thank you. I really enjoyed being on here. Good luck everyone on the inter-webs.

[convertkit form=4889308]

Important Links

• Women Who Code Austin/Meet Up
• Hack Reactor
• General Assembly Code School
• Women Who Code/Hacking Hangout

 

Thanks for Listening!

Do you have some feedback or some advice for us or our audience? Please give us a review on iTunes or Stitcher and share your thoughts.

If you found this episode useful, please go ahead and share it with your friends and family. You can do that easily using the social media buttons at the bottom of this page.

Subscribe to the show on iTunes or Stitcher (for Android users) to automatically get new episodes every Tuesday.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

Kelly began her career as a customer service representative. She spent time in a call center, seated behind one of a gazillion cubicles answering call after call in technical customer service for a travel and transportation company. While many people in this line of work are happy moving up the corporate ladder to become a call center manager or more, Kelly saw a different path for herself.

 

Kelly had a strong desire tugging at her heart strings and beckoning her toward the path of software development and the world of technology. Despite having little knowledge in the field, when Kelly saw the possibility of an opportunity open, she jumped and has never looked back or been happier. Now she’s here to tell you how she reached her destination and the struggles she faced along the way. Listen in to episode 62 to hear the interview between special guest Kelly Karsnia and Mentoring Developers co-host, Sara Ines Calderone.

Kelly’s Bio:

Kelly Karsnia is a self-taught mobile developer (iOS and Android), Director of Engineering, and an advocate for underrepresented groups in tech who lives in Austin, Texas. She works with Women Who Code Austin, Lesbians Who Tech Austin and Austin Women in Technology. She has a cute cat named Piper, loves woodworking and kayaking.

Say hello to Kelly on Twitter!

Episode Highlights and Show Notes:

Sara: Hello. My name is Sara Ines Calderon and this is Mentoring Developers. Today, I’m here with Kelly Karsnia, my friend, and also an amazing developer. She is a self-taught mobile engineer and she is here with us today to talk about her career. Thank you so much for joining us, Kelly.

Kelly: Sara, thank you. You are so sweet. Sara is amazing as well and I am delighted to be here with you.

Sara: Thanks so much. I just wanted to start off by asking you to tell us a little about yourself. I met you, was it last year?

Kelly: Yes.

Sara: It seems a lot longer than that. I met you last year at the Google I/O event in Austin, but then we met again at the Women Who Code at Austin Slack and then we became friends because you are helping me with an iOS issue that I was having with Phone Gap. Then, we became friends in real life and that’s why I feel like I’ve known you forever. So, tell us a little about yourself. I know you’re involved with a few organizations, not just Women Who Code Austin. I want to hear all about how you got into software development.

Kelly: My name is Kelly Karsnia. I’m the director of engineering at a company called Tabbed Out. It’s a mature startup here in Austin. As Sara said, I am on the board for Women Who Code Austin. I’m on the board for Lesbians Who Tech Austin. I’m also on the advisory board for Austin Women in Technology. I’m also a kayaking and woodworking enthusiast.

Sara: I’ve seen the woodworking and it’s pretty impressive for the listeners out there who don’t have a visual. That’s awesome. I’m super impressed that you keep up with all of those organizations. I’m impressed because I also know you in real life, but I think everyone who is listening will also be impressed. I hope you guys are ready.

Sara: Kelly has a really great story. She’s one of those people who, if we believe in the term “pull your self up by your bootstraps,” she’s definitely one of those folks. So, I want to hear more about how you parlayed one experience after another into your current role as Dir. of Engineering.

Kelly: I started in a call center for a social science research firm. We were doing transit and travel studies for departments of transportation and councils of government across the country. It was very low-level work, but I saw the direction in the company and started to go with it and worked my way up to corporate. At corporate, I was working in verification and working on some more dead level projects that we had and saw that the company was ramping up their IT department in the direction that I was going. I decided that was the direction I wanted to go in. I didn’t have the qualifications. My degree is in CS. I have my Associates degree in computer aided drafting and design, but I’ll tell you this, I’ve never once used it.

Kelly: So, I saw this new direction and I was fascinated by it. So, I started applying for every IT job that my company was posting at the time. The last one that I applied for, the current director of IT who had formerly been the director of the call center that I had worked at called me into her office. She asked me if I knew anyone for that position. I answered yes, me. She laughed and said you’re not going to give up, are you? I said no, absolutely not.

Kelly: From there, she created this technician position within IT so that I could be a liaison between the people that we had just brought in and IT and the rest of the company since it’s very highly specialized. There is a lot of terminology lingo and different aspects that I already knew about and could help relay to the new team. So we started there.

Kelly: As we went along, we did not have any QA for any of the software that we were creating. SO, I talked to her and took it upon myself to implement an entire QA structure for software within the company.

Sara: I think this is really interesting because I think it’s going to come up again and it’s really important for listeners who are probably also trying to advance in their careers. What words do you use? What is the conversation like when you see an opportunity and you notice there is a need and you want to address it? How do you say why not me?  What’s the verbiage that you use to have that conversation?

Kelly: When you see those opportunities and you see the need, read up on what it is you want to implement before you go and talk to anyone. You don’t have to be an expert, but make sure that you can speak intelligently on it because if you were the expert then you would already be in that role. Show them that you have been learning about these things and that you want to learn more. Show them that you were actually capable of doing those things. Go in and be confident. Then go in and have the conversation of “hey, we don’t have anyone specifically in charge of this thing. Here’s why we need it, and how to implement it, and I’m the person for this because I’m the one who’s having a conversation with you that no one else has.” To that aspect, you could say that about anything. At the same time, if you have the sincerity and conviction, it really works for you in a lot of ways.

Kelly: I’ve been called an “atta boy” before. I don’t agree with that at all. I think it’s more of an enthusiasm and a passion for learning and always doing better.

Sara: That’s cool.

Kelly: So, when you are able to show people that, and obviously you can’t do it right off the bat and roll into a new position and a week later say that you want to be director of engineering, that’s typically not going to fly. But, do the best that you can and look for those opportunities where you can be the best fit possible.

Sara: That’s really good advice. Thank you so much. I didn’t want to interrupt your story. You implemented QA from scratch at this research company.

Kelly: Right. It was a lot of learning and research on my own time. It was very time-consuming. However, it was very worth it. I really enjoyed it. It was something that I have really never thought about before. Once I really started getting into it. It fascinated me and once I started, it allowed me to see how our technology was working and really be able to give solid inputs because I had a lot of knowledge in the areas of the software that we were building. So, I really started breaking things.

Sara: In the existing infrastructure.

Kelly: In the in existing infrastructure and as a new QA. I’m not going to lie, I made some new developers cry. I’m not very proud of that. I could’ve done better on that, but that also taught me a very important learning aspect of how to interact with people. You catch more flies with honey, but not all the time. So, I was kind of hard on the developers, to say the least, and I started thinking that maybe it would be better for me to learn how to do these things myself. That’s because they didn’t always have the answers that I wanted to hear when things would break.

Sara: Do you mean like why is this broken? It’s the eternal question.

Kelly: Yes. As an engineer, I now realize that I could’ve done things better. I was talking with my developers and was like I want to understand but I know that you can’t always tell me. I really want to learn. So they set me up with some of our codes that I could play around and learn with on my own time. I didn’t even have my own environment. So I was just playing with codes and going through them and figuring out how everything worked together and using Stack Overflow and Google. I would modify something and it would break. Then I would go and figure out why it broke and how it was fixed.

Kelly: When I was doing that, I was fascinated by it, and I fell in love with writing code. Code to me is a giant puzzle and I played that in a lot of things in my life. Figuring out the puzzle and how it fits together and being able to modify the puzzle yourself is something very special to me. It gave me a new outlook on life and it also gave me a new direction in life on where I wanted to go. So that was really amazing, but I will say that there are limitations when you are learning. For example, I started out with Android because I couldn’t afford a Mac. Yet, Android allowed me to learn the basics of how we were doing mobile development.

Sara: So, you were working at this research company and you were talking to the developers and you were doing QA and decided that it would be interesting and worthwhile for you to learn how to write code. Then, you didn’t have a Mac, so you decided to start with Android. So, they were doing mobile apps? Were you doing QA for mobile apps?

Kelly: Correct. We were just starting to foray into the mobile app world. This was about seven years ago when the government research sector was a little more behind the times. So, it was kind of a tough sell.

Sara: Wow. So then you started doing Android development, which is awesome. So, what did you do then? You started doing Android, but we know that you’re a bilingual developer. What happened after you started learning Android development?

Kelly: I started working on Android and I reached a point with a simpler survey application that was pre-built out that I had been playing with and learning. We needed a modification on that. So, I went to my director who gave me my shots and believed in me and allowed me to do the QA and all the stuff. She knew that I was learning on my own. I went inside and said that we don’t need to hire a third party. I can do this. So she agreed. She trusted me and believed in me. She said that if at any point, I feel that I can’t do this, tell her and they would get someone else. Project deadlines are very important. There’s ego and then there is the reality. You always have to keep in line with reality and don’t think back because it will look bad on you if you try. Always be realistic with what you can do and what you can’t especially when you are self-taught. That’s very important.

Kelly: So, I had two weeks, and I made all of the modifications. It was the first time that I had ever seen my code go into production.

Sara: Because you QA’d it to?

Kelly: Actually, yes they did. Don’t ever do that, but they did have me QA my own code. I did ask some other devs to check it for me as well. They did, but it was more of a walking through and making sure that nothing in the service level was broken.

Sara: Wow.

Kelly: There is still a very special place in my heart for transit and travel. So from there, I expressed interest in learning iOS. They agreed and asked what I needed. They went out that day and bought me a math book. They told me that when I got up to speed on that and started feeling comfortable with it, to let them know.

Sara: That was still on your own time though?

Kelly: Yes, it was still on my own time. I had some company time to do it while I was doing QA and more Android code. It was vicious, but I loved it. I knew that the opportunity was not once-in-a-lifetime but at that time, was what I wanted. So, I put my nose to the grind again and within four months. I went to them, we were scoping something else, and I asked for my first shot at this. I built my first iOS app scratch along with an Android app from scratch at the same time.

Sara: Wow.

Kelly: It was pretty intense with the transit and travel industry making these apps, there are a lot of location service aspects involved. There are very calculated things that you have to do to be in compliance with what departments of transportation and councils of government consider acceptable data. So I was really focused on, not just from a QA aspect, but also from a data aspect, of understanding this industry on how to collect that data. They did some really interesting things that I had to explain to the Apple store, but at the end of the day they ended up being okay with it.

Sara: Wow. That’s awesome. So, then you became a fully-fledged mobile engineer.

Kelly: Yes, I was hooked at that point. It was a lot of blood, sweat, and tears, but the payoff and the way that I felt after each of these was more than worth it.

Sara: Yes. So, then you’d did do different types of contract work if I recall correctly. You worked at different companies after this place, all in mobile development, before you landed in your current position. So, do you want to tell me a little about how that went for you and how you mentored or were mentored along the way?

Kelly: Sure. Mentorship played a role in my career from the aforementioned director who gave me my shot, Miss Saundra. She was the director of IT. She had actually migrated from the director of the call center to director of IT without knowing much about IT. She was a very good director. She was always my cheerleader. She showed me that as long as I worked hard and acted with ambition, I could achieve goals that seemed far-fetched and almost fantasy. This was really great for my start in IT and I’ve carried it throughout my entire career. So, that was always very special to me. All it takes is one person.

Kelly: I’ve had mentors along the way, but we’re still in touch. Every mentor that I’ve had, I am still in touch with. They’ve boosted me to where I am now and that is invaluable.

Sara: That is so cool.

Kelly: You never forget those people.

Sara: Yeah, definitely. So, tell me a little bit about how you found these organizations that you’re involved in like Women Who Code Austin, Lesbians Who Tech Austin, and Austin Women in Technology and how those are opportunities for you to either continue to be mentored or for you to mentor others, and how you think that is important.

Kelly: Well, as you said, I initially met you at Google I/O Extended. Sara gave me her card and we were both front and center and ready to go.

Sara: I was there with Women Who Code Austin. That’s how I got there.

Kelly: I was there for my current company. They got me in and I was front and center and ready to go and I was actually getting ready to do my first live tweeting session. I was super excited. I had just gotten into Twitter and I was ready and that I meet this amazing woman, Sara, who gives me her card. And I was like oh wow, Women Who Code.

Kelly: We go through the thing and we touched base a little bit after, but were all amped up from Android and Google. I mentioned to one of my buddies at Lesbians Who Tech that I had met Sara and that I thought she was amazing. You and I got back in touch.

Sara: You were mentoring me and iOS on Slack. Why is this broken?

Kelly: It was an experience, I will say. Never be afraid to ask for help because you never know who’s going to be your salvation and it was great because Sara and I talked through this. I don’t know if I was the ultimate solution, but I gave advice on different things and I sent articles and documentation just to make sure. This probably didn’t take more than over the course of three days. It was like two hours of my time spread out.

Sara: From my perspective, honestly, even you just saying that that had happened to you before made me feel that I wasn’t stupid.

Kelly: then we were making jokes with each other about different aspects of iOS that could be better.

Sara: Now, I’m a mobile developer.

Kelly: This girl’s amazing; I mean I’m in the presence of greatness now. I am basking in this glow coming from her right now.

Sara: So, we met at Google I/O and then we were talking about Lesbians Who Tech here in Austin.

Kelly: At that time, I was just going to different meet ups and happy hours. I started being around all of these amazing women in tech who were incredibly inspirational to me with who they are and what they do to boost women in tech as a whole. So, I decided that I wanted to join these amazing women and I started really getting involved with these organizations that go beyond meet ups and happy hours. I was finding ways where I could be a benefit as a mobile developer because there’s so few of us, to begin with, and there’s even fewer between the Android and iOS specialized areas.

Kelly: So, I dug in and started to talk to more people and Sara and I reconnected and I believe you asked me if I wanted to, was it Country Girls Can Code?

Sara: probably, yeah. So, we had an event. It’s not my event Women Who Code works with women, but through Women Who Code and yoga I became connected with a really cool group here in Austin. Techs4Tex organized the event during the last two years. It’s called Country Girls Can Code and they bring rural high school girls from parts of East, Central, and South Texas to Manor, Texas for a day of coding. So, I was volunteered to help organize this event and it’s always really great to see the young ladies. It was the first time that they’ve ever built a whole thing. Most of the time they would’ve done a bit from Minecraft or a little bit of this and that but I’ve never built anything like this from scratch. So, that’s always cool.

Sara: This year we had them all make GitHub accounts and they pushed up all their code and we showed them how to use the command line a.k.a. we did the command line for them and they watched. I wish somebody would’ve done that for me.

Kelly: A.k.a., we all googled syntax, or at least I did.

Sara: Why is it broken? But yeah, so through Women Who Code and Udemy, I won a scholarship to do an iOS class. So I started doing an iOS class and my first app was a Hello World app. I thought this is a really cool tutorial. So, I asked Kelly if she wanted to teach the children iOS. So, long story short, Kelly taught the children the iOS tutorial.

Kelly: So, I led the tutorial and sorrow kept me and the young ladies on task and on a timeline because I wanted to help everybody. Sometimes, you just gotta get up there and lead.

Sara: There were 50 of them there, by the way.

Kelly: There were 52.

Sara: 52 high school girls. That’s a lot of girls.

Kelly: One of my favorite stories was this. After we got through the tutorials, there was an HTML component for the web that they were learning; we split them up into two groups. Half of them were doing HTML and CSS, and half of them were with me. Then, they switched with me and Sara. We got through that and then we allowed them enough time to come back and ask questions and finish up.

Kelly: One of these young ladies was having a tough time when she came back for the Q and A. I’ll never forget her face or the frustration on it. She said, “My code is failing, just like I am.” So, I said, “No, absolutely not. If I run code for 20 minutes and do not fail at something, I’d be like what is going on here. Xcode is not this nice to me ever.” So, is really special for me to be able to connect with her and she laughed and was like “really?” One thing that was also cool was during both of the tutorials that I did. There were build issues that I was able to highlight and show them how to work through. One of the most maddening parts of being able to teach yourself is getting frustrated with IDEs and product set up, and how to actually work through those and do all that. You look around you all the time at these companies and you don’t see the struggle on everyone’s face.

Sara: Sure.

Kelly: So, it’s important to make this struggle apparent and I feel that’s important because a part of mentoring is allowing people to understand that there are going to be frustrations and the frustrations that you have are along the lines of the same frustrations that they have. It’s okay because you can work Passed this. If you can get through this, you can get through anything.

Sara: Sure.

Kelly: That was something that was ingrained in me from the start. Keep fighting and if you don’t give up on yourself that no one else can give up on you. I mean they can, but you’ll keep going because you never gave up on yourself. There are pitfalls. There is quicksand that you’re going to hit. There’s all that but never stop. Allow yourself to have some kind of mentorship ability and even when you don’t have it, work your way up there. Even if you think that you’re not going to be a good mentor, you will probably surprise yourself.

Kelly: I had a company once told me that I wasn’t good for a job because I only had three faces.

Sara: That’s because they were judging the facial expressions you made.

Kelly: Right. They were judging the faces that I made.

Sara: Man, that’s crazy. That’s very professional. So that’s nice.

Kelly: Those were not any of my mentors.

Kelly: I think that’s a really great thing to highlight and I think you and I had conversations about this too. If you don’t decide at some point that you are going to make this happen, you are going to be a developer, you are going to be a QA, or whatever it is you are going to be, I think that inspires even mentors to take confidence in you. So, obviously, you can’t just get a mentor by conjuring one up. You have to keep working even if you don’t have those mentors in place and kind of mentor yourself or find mentors through organizations. When I met you, when we really started communicating on Slack, I was like “why is Phone Gap the worst thing ever? Will someone help me?” For those who were wondering, the answer to my problems was that it wasn’t broken in Xcode only in Phone Gap.

Kelly: Exactly, because we talked about that. You were like no, it’s just broken here.

Sara: It’s not actually broken.

Kelly: You know what; I don’t have the most robust experience in Phone Gap. But, what I was able to do since I’m self-taught and know all this; I hit Stack Overflow and Google. I researched all the knowledge that I do already have it and was able to piece some things together and send it over to you. I will say this, in terms of being an unexpected mentor and not even knowing it, I had been in the Women Who Code Slack for maybe a month or two and I had been waiting for someone to just ask a question about mobile. Finally, Sara asked the question and I’m like “I’m right here. I’m right here. What do you need?”

Sara: That is so funny.

Kelly: Will work through this together. I’m just so happy that there’s some solidarity here and something that I can provide value in because that makes me feel good as a person to spread the knowledge of what I’ve learned over time and to allow other people to understand that there are struggles that we all go through. Also, they are not the only one struggling. There are other people who have been there before them.

Sara: So, thank you. I love that. You tell the best stories. One of the things that I want to talk about now is, and this is something that we were talking about earlier, though not on the podcast, that I volunteer a lot of my time to Women Who Code Austin.

Kelly: Yes you do and thank you for that.

Sara: But you also volunteer a lot of time to Women Who Code Austin, Austin Women of Technology, and to Lesbians Who Tech Austin. What is the value of mentorship? I mean, these are advocacy organizations in one definition of what they do. So, how do you feel mentorship can change technology and change the space for women, for the LGBTQ community for people who are “underrepresented” in technology? I think, fundamentally, that it can because otherwise, we wouldn’t be volunteering all this time.

Kelly: Yeah, I agree with that. How I feel about that is that there is so much solidarity when you’re mentoring and when you’re being mentored because you have someone who is literally there and you are not alone. Whether you are there for someone else or someone else is there for you, you have at least one person either way. Neither of you is alone in that. You see this community as a whole where we are all there for each other and we all have solidarity with each other. So, when you’re having your loneliest day or that moment when your code is broken and you don’t know why, or, you are that project manager and nothing is going as well as you thought you have a community around you or people who you can talk to about this. That’s why we are mentors and mentees.

Kelly: This is the important aspect. You don’t just celebrate when something goes right. You talk to people when things go right and celebrate it. You talk to people when things go wrong and when you fix it, you can celebrate together. Mentoring not only helped me to become the person who I am today through being continually mentored, but it also helped me in furthering myself through mentoring others. When you are mentoring others, you get a much better grasp of the field around you and the people coming into your field, which is monumental.

Sara: Yeah, that makes sense.

Kelly: Right now there is a director hiring junior developers. I don’t necessarily look for people who know the lingo. I look for people who have the will to learn. I am looking for the people who have something to offer who I can work with. I am looking for the people who have the ability to just get after it and better themselves. That’s important to me because when I mentor, I see that and I know that from being mentored that is important.

Kelly: I wouldn’t be where I am today if my mentors thought because I didn’t know everything, every acronym, every single piece of tech jargon out there, that I wasn’t worthy of the job. So, that really changed me and it also allowed me to get a better understanding of not just coworkers or people in my field but friends, family, coworkers, and everyone in between. You start looking at things differently because you experience different things while working with people hearing other people’s experiences and sharing yours. I never thought I’d be on this podcast speaking intelligently about this or that anyone would care.

Sara: Yeah, they care.

Kelly: Thank you, Sara. It means the world to me. I hope you can tell that even through this podcast, the way that Sara and I lift each other up. This is not fake. This is genuine.

Sara: This is totally real.

Kelly: This is what we do with each other as friends.

Sara: It is way too late on a Tuesday to be lying.

Kelly: It is. It is way too late on a Tuesday to be lying. It’s been a long day for both of us, but we’re here and we’re doing this because we care about each other and we care about the community. It brings so much solidarity and understanding to the community. I’ll say that mentoring in general. The side you’re on doesn’t matter. It will make you a better person as long as the person you were working with on both sides of the fence is someone who is accepting of feedback and also the way that things are working around you. I’ve talked a lot about my first mentor, Saundra. I had lunch with her the other day and she still lifted me up.

Sara: That’s cool.

Kelly: I really believe in people.

Sara: Sure.

Kelly: That’s what we were able to provide to each other. There’s also knowledge transfer and there’s also teaching each other and ensuring that we all know that we can do this. We know that we can do this because we have each other’s backs. It is really vital to the industry because otherwise, you’re going to feel very alone. When I first began teaching myself how to write code, even when I began learning things in the made-up tech position, it was very intimidating, but I had people who surrounded me that reassured me. I taught them things about the company and they taught me things about tech. They didn’t treat me any different just because I didn’t know SQL at the time.

Kelly: We all have to start somewhere and I firmly believe that college is great, but it’s not for everyone. It wasn’t for me and my mentors understood that. That’s something that I tried to pass along when I come across women on an almost mentees basis who have not gone to school for CS or who have but don’t know where they want to go. I try to help them find what they actually want to do.

Sara: That’s so interesting to be in a position where you are talking to CS majors and you’re like it doesn’t matter because they don’t teach what you need to know in college.

Kelly: Right. So, all of those tutorials that you followed in all of those things; you’re going to get hit hard with curveballs left and right. You’re going to get handed code sets that don’t make any sense. You’re going to get handed feature changes that you will realize, once you look at even your own code set, that your code set doesn’t make sense. Programming and tech, in general, are tough pills to swallow sometimes. As long as you can have your community around you and you can have your base and these people who you can go to and you can be that person for other people, it’s invaluable.

Kelly: I will say this, though, I love going to my mentors, and I love talking to them, I still go to them for things occasionally. I talked to one of them several times a week. He’s a very good friend. He’s a mentor who taught me a lot about tax but also taught me how to breathe in tech. He taught me how to take a break and walk away and move around and to try to forget about it for a moment. That was also monumental. So, I talked to him quite a bit and he still helps me be able to do those things and he helps me to pass that knowledge on to other people. Sometimes you’ve just got to get away. Sometimes the fix will be right in front of you. I would literally dream of fixes before. I’m not going to lie. I’ve gotten up at 3 AM after a dream. I fixed it and it worked.

Kelly: So, a mentor is not just about how to write code. A mentor is how you handle the aspects around it. Hopefully, it’s not just going to be one mentor. Hopefully, you will find several. Then, hopefully, you will find several other people who you can be a mentor for in their life. The people who I’ve mentored in my life and the people, who I continue to mentor, continue to change my life in these positive ways. Like I’ve said before, they give me different outlooks on things.

Sara: That’s awesome. I think we’re going to wrap it up here because it’s Tuesday night and it’s late in the night.

Kelly: Yes, it is taco Tuesday.

Sara: We have both had long days, but I do want to leave our listeners with some more of your knowledge. So, I want to ask two questions, but it’s the same question. What two tips would you have for someone who is trying to be mentored or trying to learn the software? What two tips would you have for someone who’s trying to groom or mentor or bring people up in technology?

Kelly: For someone who’s trying to learn, find out what technical resources you have within your community and if you can’t make it to these things, find the Women Who Code Slack team where you can jump on and get on their even if you have zero tech experience, but you want to get into tech. Find resources like that out there.

Kelly: Obviously, if you’re going into tech, you’re going to have access to the Internet at some point. If you’re going to try to Google things, Google, the city you’re in. If you’re a woman, try to Google Women Who Code in your city and hit them up. Even if you’re not in a city that has that, I would recommend hitting up the Women Who Code Austin Slack team because it is seriously the most amazing resource for women in tech as a whole that I have ever come across. It is amazing. That’s not me doing shameless self-promotion. It really is legitimate.

Kelly: Find your community. Find what you like to do. Go to meet ups. Talk to people. Find the person who you would like to be mentored by because there are different personalities out there and there are different ways that people learn. Everyone has some learning disabilities. There are certain ways that I learned and there are certain ways that I don’t. So, full disclosure. I have adult ADD and adult ADHD and a tendency towards dyslexia. So, I have people who understand these things about me. It allows them to tailor things to my specific criteria when they’re talking with me.

Sara: it’s as though they want you to be successful.

Kelly: Yes, exactly. See, I couldn’t even find the words for that and Sara came right in because she knows because little does she know that she’s one of my mentors. So there’s that, and also pick your battles with the mentor because it’s going to be frustrating. There are going to be times when you want to cry and there are going to be times when you want to scream.

Sara: Yeah, that’s a good one. Try to be as open as you can.

Kelly: Yeah, try to be as open as you can about what’s going on. Talk to them because they are people too. This is why it’s important to pick a mentor who is good for you and who can work at your level. Someone can be the most brilliant Python developer, but if they can’t relate to you on your level, you’re not going to write very good Python because you’re going to feel like you have to venture up to them. That’s not okay and that’s not acceptable as a mentor. A mentor should always be able to speak to you on your level and if they can’t, please find a new mentor.

Kelly: Be open but understand that the mentors that you pick, a mentor should not be singling you out against your will, I’ve seen that happen before and it’s totally weird and uncomfortable, be open and honest and understand that your mentors are there to help you. If you are feeling frustrated, communicate that with them and they will help you through it.

Sara: Yeah, be nice and respectful and professional.

Kelly: Yes.

Sara: So, if you are a mentor, and I know that you are a mentor and not just to the children because you were at a hack-a-thon this last weekend and you’ve been a judge at hacker funds, what is your advice to people who are mentoring?

Kelly: This will be everything that I’ve said on the other side of the fence about what being a mentor should be. Be understanding with your mentees. They don’t know everything that’s why you are there to help them. Also, don’t be opposed to learning from your mentees because I have learned from my mentees very valuable points that I didn’t realize or didn’t know how to work with people. Be open. Be understanding. Treat them with tender loving care because we’ve all been there before and we all know how it feels. Explain what acronyms are.

Sara: Yeah, that’s really good practical advice.

Kelly: It really is.

Sara: I just have to say for everyone earlier who doesn’t know what an IDE is, it’s an integrated development environment, a.k.a. a program. It’s like Visual Studio code, Sublime, or Atom, Xcode.

Kelly: Explain the difference between a text editor and an IDE.

Sara: I agree with you. I love that because when I started working, I was like “I’m so stupid. What’s a CLI?”

Kelly: Also, if you’re just throwing words out there common to the industry, like Jenkins. The first time that I ever heard of Jenkins, I had no clue what it was.

Sara: Well, that makes sense because when I talk to people I always ask if they know what that is. If they say no then I say that’s okay because when I first started. I didn’t know what it was either and then I explain it. It’s just faster that way.

Kelly: Yes, just be careful in your explanations. Allow them to feel that the information that they get from you is digestible.

Sara: Are there any closing thoughts? I think we’re going to wrap up here, but I really appreciate it. Thanks for being on Mentoring Developers, Kelly. You’re the best.

Kelly: Yes, Sara. I would like to close with everyone out there, be awesome. Each and every one of us is doing this. If you’re doing this, you’re awesome. You want to be at that next level. Keep pushing added. The only limitation that you have in life, not the only but a major limitation that you can have in coding is thinking that you can’t. Always push for the next and never plateau. You can always be more awesome than you are. You can plateau for a little bit, but don’t forget to be awesome and don’t forget to be yourself. It’s going to be frustrating and it’s going to be hard but, I’m seriously going to say this from the bottom of my heart, I may not know any of you, but I’m proud of each and every one of you.

Sara: She totally means it. I know her.

Kelly: I’m not going to tear up right now.

Sara: No, she’s not going to tear up.

Kelly: I hope that I’ve been as amazing as Sara, and Sara I would like to thank you for having me on the podcast. You are an inspiration to me and you are one of my mentors, and this means a lot. High-five, people!

Sara: If you want to follow, Kelly, because she’s amazing, on social media, her handle is…

Kelly: @therockynash on Twitter and Rocky Nash on Facebook. You can’t miss me. I’m wearing a ‘Bring A Lesbian to Work Day’ shirt for my profile picture for Facebook.

Sara: That’s a really good picture. I know that picture.

Kelly: Sara took that picture.

Sara: And if you want to follow Mentoring Developers, I think its @MentoringDevs on Twitter. Don’t forget to subscribe to us on iTunes, and you can share us with any newbies that you may know. You can reach out to me if you know someone who would be interesting.  All of my social media is @sarachicad. Like I said, follow @mentoringdevs on Twitter or Mentoring Developers on Facebook. We’re going to wind this down, but we’ll talk to you again next week. Thank you!

 

[convertkit form=4889308]

Important Links

• Lesbians Who Tech
• Women Who Code
• Austin Women in Technology
• Google I/O Events
• Google I/O Extended
• Tabbed Out
• Stack Overflow
• GitHub
• Country Girls Can Code
• Techs4Tex

 

Thanks for Listening!

Do you have some feedback or some advice for us or our audience? Please give us a review on iTunes or Stitcher and share your thoughts.

If you found this episode useful, please go ahead and share it with your friends and family. You can do that easily using the social media buttons at the bottom of this page.

Subscribe to the show on iTunes or Stitcher (for Android users) to automatically get new episodes every Tuesday.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

Meet our next guest, Fernando Hönig. Fernando is originally from Argentina and fully understands the challenges that Spanish-speakers around the world face in the IT industry when trying to learn new information and ultimately get ahead. He has found a way to give back to the Spanish community through his AWS program and social media channels. Listen in to episode 61 while Fernando and Mentoring Developers co-host Sara Ines Calderon discuss cloud computing and AWS in the Spanish-speaking IT world.

Fernando’s Bio:

Fernando is an experienced Cloud Infrastructure Solutions Leader with over 18 years of extensive IT Architecture and Management experience in a variety of market sectors. He has an in-depth understanding of Information Technology services and technology in conjunction with their related markets and strategies.

Fernando is an accomplished professional in designing, implementing and configuring a wide variety of hosting, web, applications and systems solutions. He has proven experience in managing multiple large-scale infrastructure projects across matrix environments and multi-phased, complex migration programs.

 

Publications:

• AWS en Español (Spanish Translation)
• AWS in Spanish (English Translation)
• User Groups are the Newest Addition to the Growing Global Community
• Save Money with AWS VPC EndPoints
• How to Monitor a VPN Connection in AWS using Lambda
• Control the Cloud with Code!

 

You can find Fernando on YouTube, LinkedIn, the LinkedIn group AWS en Español, or Twitter.

Episode Highlights and Show Notes:

Sara: Why don’t you introduce yourself, tell me your name, where you work, and how you got into technology?

Fernando: All right. My name is Fernando Honig. I’m originally from Argentina, but I’ve been living in London since 2014. I have a strong infrastructure background. So I come from the infrastructure type of the IT field. I have more than 15 years of IT experience. Lately, I’ve been getting more into the cloud technologies and the cloud aspect of the IT system. I work in cloud infrastructure solutions architect for a company in London. So, that is who I am.

Sara: Cool. When we were talking earlier you told me about how you came into technology and you said that you had started when you were very young. Is that correct?

Fernando: Yes. So, back when I was 16 or 17 years old, I started back in the ages. I’m 36 now. I started two centuries ago. People were using modems and connecting to the Internet using the U.S. Robotics 56k modems to start browsing. That was the old Internet then. It was, I think, 1.0. So, I started doing that. I was going to customers and basically installing pieces of hardware. So it was a long journey when I started doing that and then I later got interested in Linux. That drove my passion about all the Linux and open source technologies then I became a DBA.

Sara: That’s awesome. So, how did you learn? You mentioned previously that it was in Argentina in the 80s and we had Internet 1.0. How did you learn how to install modems and then continue?

Fernando: It was really hard. I remember when I had to install my first Linux. I bought a magazine and installed it with some CDs. Everything was in English, so I was really lucky that I had started in English by that time. After 15 years. I can now say that I was lucky enough to have the opportunity to learn a second language and start to progress my career by having magazines and browsing the Internet and finding books by that time. Every book was in English. There was no Google at that time. There was another another search engine, but there were no self-learning that I could take.

Sara: That’s really interesting. You had mentioned that there was some stuff on the Internet in the pre-Google Internet as well. I’m assuming that you went to college in the late 90s or early 2000’s when may be a little more information was available. I know that there were some online communities at that time that were specifically talking about technology. Tell me a little bit about how you grew with the Internet when you were looking to learn new things like my SQL or the next new thing in technology. Did you start finding communities online to help support that?

Fernando: Not really. As I had mentioned, I was in Argentina and I was, not in the bigger city of Argentina. I was in a second one. It was kind of a university city. So there were a lot of people who were interested in understanding these new technologies. There were people who were just coming out of Oracle and were starting to work on MySQL. It was free, open source by that time. So you could basically go to the MySQL website and screen in the manuals and view all the changes online for every new version and install that new version and all kinds of things. It was the same thing with Linux versions. It was more like a trial and error to see if it would work or not. I remember back in the day when we had to compile your kernel with a support for the latest graph and interface. Sometimes I just try to explain things to people who were new in the IT world that it wasn’t always as easy as it is now with a working server.

Sara: So, you said that you were in a university town and there were a lot of students and people who were on the bleeding edge of technology. Were there meet-ups or online message boards or anything?

Fernando: At that time there was no Slack or Iceberg or anything like that. So, we worked together on a typical IFC and we were discussing things like the kinds of issues that we were having. So, it wasn’t a proper meetup. We were a group of friends who were all interested in technology. We were the typical geeks of the city and things like that. So, it was not like a formal meet up.

Sara: Yet, you guys were still working together to help each other out. It sounds like to me that from the very beginning, you were collaborating with people to learn these new technologies.

Fernando: Yes. It was always my passion to help somebody else get on board. That’s basically what drives me to learn things, to pass it on to somebody else and to try and connect a bridge to connect technology with people. I think that is one of the things that I’m really passionate about.

Sara: That’s cool. For those who are listening, I met Fernando on Twitter and through a Mutual Friend over at Cloud Guru. Fernando has been doing some really cool work trying to bring people who may not speak English, but who may speak Spanish as their dominant language to specifically enable them to learn more through AWS. In case people are listening and don’t know exactly what you do, could you explain quickly about what the cloud is and why being able to bring that information into Spanish is relevant? For example, you did mention that being outside of the US, you may not always be able to get manuals or textbooks or YouTube tutorials or official documentation in any other language except English. Even if you do use a Google translator or something, it’s not going to be as precise as you might need. That’s my understanding.

Fernando: Yes. The lack of documentation in other languages, not just Spanish, is gruesome. I do get that English is the universal language, but sometimes, some communities are not able to learn a second language. Basically, that is postponing this progress on their professional careers in IT. I don’t know if you know this, but 516 million people worldwide speak Spanish. There are about 57 million Spanish speakers in the US. So, it’s a lot of people. Basically what I’ve been trying to embark myself on during the last two years was that I needed to give something back to the community and try to leverage the cloud computing technology across people who speak Spanish. So, I’ve been trying to create meet up groups in Latin America and Spain and also create and translate different documentations on AWS. So, the intention is more about enabling people as the first step into developing to get cloud computing knowledge and help them grow in their career.

Sara: Sure. So, I wanted to ask you a follow-up question. When you say that you want to bring more Spanish speakers into cloud computing, is that because you haven’t run into a lot of native Spanish speakers or have you talk to people who have said that this was a barrier? What prompted that for you?

Fernando: Yes, one of the things is the language barrier. The other thing is that it is hard for companies in Spain and Latin America to find properly skilled people in cloud computing. So, it’s a two-way thing. It is companies who are trying to hire and develop the right kind of people who have the right skills and also people who want to get onto this new train, but they feel that it is passing very quickly and they struggle to catch up with everything that is happening daily. So what I am trying to do is fill that gap by injecting content in Spanish and providing people with the right training and documentation.

Sara: Sure. So, you said that you are starting some meet ups and places. Can you give me one or two examples of what that looks like? You did mention the AWS documentation that you translated. I’ve seen some of the posts that you put online and translated. I’m trying to imagine this as in I’m trying to do cloud computing. I’ve read about it online and I think its super cool. My English is okay, but it’s still hard to understand technical documentation, even if you’re an English speaker. So, that’s probably difficult. I know that I’ve done this where you just look and look online and try to find somebody who will help you. Tell me, if you will, some of the feedback that you’ve gotten from some of this work.

Fernando: Yes. So, one of the things that I’ve been trying to do is grow a LinkedIn community. We have an AWS in Spanish LinkedIn group with more than 800 people already. We just launched two or three months ago. So, it’s growing incredibly well. We are also running an online AWS meet up in Spanish. So what I’ve basically tried to do with this online meet up every month is bring people from AWS and the community from different companies who are implementing cloud solutions and AWS. So, we look at server solutions or how to put your application in the marketplace and make money with AWS. So, what I’m trying to do essentially is connect people who are lucky enough to have the experience with cloud computing and AWS with people who are just beginning this journey.

Fernando: One of the really good feedbacks that I’m receiving from people who are taking my courses or people who are participating in this LinkedIn community is quote thank you for helping us to have training on this in Spanish.” That cost less than a pizza. We cannot forget that South America and Latin America are not the richest countries in the world. So, having access to affordable training is important. For me, it’s very fulfilling. Knowing that they are using it to get a new job or gain new skills for the job that they have. So, it’s really rewarding for me.

Sara: That’s so cool. So, just to reiterate for those who are listening and want to follow up in case they’re interested, you said that you have an AWS in Spanish group on LinkedIn and you have an online meetup group for AWS in Spanish services. Is that correct?

Fernando: Yes. That’s correct and we also have it on a YouTube channel under the same name and people can go and subscribe to that. We also have all the user groups in Spanish that are uploading their meet ups and are streaming to the same channel. We had 10 or 12 videos right now. So anyone can go in and watch what people are doing, and all the different places across the globe in Spanish. That’s the most important things.

Sara: That’s awesome. I didn’t want to get back to something that we had discussed earlier. Can you explain to somebody who has just been doing web development and doesn’t really do backend services, what is cloud computing?

Fernando: It’s difficult to explain what cloud computing is because people might understand what the cloud is, but you still have servers. So, cloud computing is a way that you could rely on somebody else to do the heavy lifting on buying servers, installing servers, cabling servers, and having people to manage the physical security on your hardware so that you can just focus on the things that you are good at. So, as a developer, the good things that you have to be doing coding, making your code more secure, making your code faster, and getting your code out there as soon as possible. So that is the basic principle of it all. It’s all about getting your code out there as soon as possible.

Fernando: Cloud computing is definitely helping to have this in place. It allows you to put the core of your business in front of all of the heavy lifting and managing of servers. I think that companies who provide cloud computing are changing the way that IT is being presented to more people. So, I think that more people are able to interact with the technology because of the removal of the heavy lifting on the hardware piece.

Sara: That’s awesome. Thank you. So, I wanted to get back to what you were talking about within the meet ups. I wanted to talk a little about mentorship since you started sold young and you did have these communities and now you’re building this other community. I’m sure you’ve managed people and hired people at this point. I want to get your thoughts on mentorship in informal settings like the meetup or via formal settings like the workplace. How has mentorship helped you and how do you feel as a mentor in the workplace? How is that important to other people’s careers?

Fernando: Every role that I’ve played in my career, I have always try to look for mentorship. I’m always trying to find mentorship opportunities in every company. It’s not always specifically on technology. Sometimes you just need mentorship on other things like public speaking or how to do presentations or even how to study. Sometimes you just need somebody to help you understand the best way to use your time to study for something, as an example.

Fernando: So, sometimes, it comes down to learning how to give or receive a mentorship. Whenever I’ve always had a mentor, I’ve always tried to get the most out of it, and then I’ve tried to pass that knowledge on to somebody else. In my previous two or three roles, I was in a team lead or manager role. I try to leverage people skills and put some specific goals on how to improve their careers and how to communicate better with colleagues. It’s like being a respected player within the company. That is something that is really important when you want to collaborate and create a good culture in your company.

Fernando: The idea behind the meet-ups sometimes is having someone present in a specific docket, but also trying to find someone who can help them on getting a better result to get something done. I think that is something that the industry is lacking a lot of. Sometimes we meet people who do things rather than just talk.

Sara: That’s awesome. I’m not super familiar with all of the exact technologies that you use, but I know that Linux is a little different than AWS, for example. So, when you were trying to learn these things, how did you learn and how did you find mentorship? You said that you always try to find mentors. So, how do you find mentors? What do you look for in a mentor? Also, once you learn these things, do you just wait for someone to ask you for mentorship or do you seek it out like in the case of the AWS in Spanish?

Fernando: The cloud journey was interesting because I joined Rackspace a few years ago and I realized that this was definitely a cloud player. So trying to understand how people were moving over to cloud was an interesting learning curve. So, I try to understand the other new technologies around cloud and then had to explain that to customers and new peers there. It was a really good team back at Rackspace. Everyone was very supportive and explained things and gave examples and provided new training. After that, I was trying to understand how I could pass that knowledge on to somebody else.

Fernando: The important thing was for me meeting Ryan Kroonenburg from A Cloud Guru. His idea was that the way to teach people is to offer it is in a way that is similar to talking to people in a one on one session, only in this case, it was for thousands of people. So that is what I tried to do with the solutions architect training in Spanish. I was looking for a way to build it so that it would not resemble a product or a prototype. I wanted it to be more like having a conversation with the students. That is how I really enjoy explaining things and showing examples and answering questions. This is what helps people to better understand new technologies like this.

Fernando: Less than 10% of all people working in IT are working on the cloud. The rest are still working on physical data centers and physical servers. These are on premises and some companies even have their own data centers on promises. When you are so connected with cloud people, it’s easy to think that everyone is on the cloud. The world of technology moves so fast. Two years ago, no one was talking about the cloud. Now, everyone is talking about artificial intelligence, machine learning, and becoming server-less. Things move so fast and we don’t want to forget that not everyone is moving at that pace. We need to help people to afford that train and then guide them as best as we can.

Sara: Yes. That’s awesome. How did you find mentors? I was interested in what you were saying about how you sometimes needed a mentor to do other things like presentations or etc. How do you assess what you need? How do you find mentors? That’s something that I’ve had problems with. For example, I worked on the team as the only woman and I kept trying to look over other people, shoulders, but they were too busy. I would ask for help, but they would be too busy for that as well. So, I try to find people on Twitter and some people would offer to help, but then never respond back. I think we talk a lot about finding a mentor, but how do you find one?

Fernando: I think to become a mentor; you need to be passionate about it. Sometimes people who are really good at one thing might not make it good mentor. Mentoring is like teaching. It is like trying to explain something in your own words. I’m not going to say that it’s simple, but when you join big companies like Intel, Rackspace, or IBM, you always tend to have these mentorship programs. You find these extremely nice people who are willing to help, maybe not specific technical things, but how to reach that place to be able to learn specific technical things. The mentorship is about how to get to that place to learn something.

[convertkit form=4889308]

Important Links

• A Cloud Guru
• Rackspace
• Intel
• IBM

Thanks for Listening!

Do you have some feedback or some advice for us or our audience? Please give us a review on iTunes or Stitcher and share your thoughts.

If you found this episode useful, please go ahead and share it with your friends and family. You can do that easily using the social media buttons at the bottom of this page.

Subscribe to the show on iTunes or Stitcher (for Android users) to automatically get new episodes every Tuesday.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

Meet our next guest, Allan Kelly. Allan began his career as a software developer but quickly moved into consulting. He has authored several books on software development and shares his love of tech and how to be more efficient in software development with others in the industry. Listen in to episode 60 and hear his story.

Say hello to Allan on Twitter!

Allan’s Bio:

Allan makes digital development teams more effective and improves delivery with continuous agile approaches to reduce delay and risk while increasing value delivered. He helps teams and smaller companies including start-ups and scale-ups with advice, coaching, and training. Managers, product, and technical staff are all involved in his improvements.

 

Allan is the originator of Retrospective Dialogue Sheets and Value Poker. He is also the author of four books, including “Xanpan -team-centric Agile Software Development” and “Business Patterns for Software Developers” and more recently “Continuous Digital: An agile alternative to project”. On Twitter he is @allankellynet.

Episode Highlights and Show Notes:

Arsalan: Hi everyone. Welcome to another episode of mentoring developers. Today my guest is Allan Kelly. Allan, how are you?

Allan: I’m very well. Thank you for asking me, Arsalan.

Arsalan: I’m so happy to have you here. You are not in the US. You are in London. Is that correct?

Allan: Yes. I’m sitting here in sunny London. No rain today.

Arsalan: That is incredible. I am so sorry that I have to hold you in your home office right now instead of out there having fun on those rare sunny days in London. So the question is, who Allan is and you told me that you are an Agile coach and you coach people and teams about how to do better. You mentor people. You have so much that you have done in your life, and we really want to go into that. There is one story about your first proper programming job that you got. That was five years after you graduated, and it was supposed to be this amazing new opportunity where you do things and it didn’t go according to plan. What happened?

Allan: I had already been earning money for programming before college. When I went to college I learned how to do it properly. You know that thing when you ask users what they want and you write it all down, and you design it, and you build it, and everything’s cool? I learned all that in college and then I graduated. When I got to the real world, nobody does it like that. It’s all over the place. I do these jobs because you have to earn money, but I spent five years feeling guilty doing projects after projects. I was thinking that we don’t do these things the way we’re supposed to. I was thinking that it was all wrong because we don’t do it how I was taught in college.

Allan: I started working this job for the British railway system, and they were doing it properly. Everything was written down, and they have an ISO approval on all the rest of it. I was so happy to get this job. It was a nightmare. The documentation was as high as a five-year-old kid. I spent half my week writing documents. We got audited and we were coached on how to answer the auditor’s questions. We had these architects who came from a Cobalt background and we were writing in C++. They had no idea about the technology we were using. So, the code and the architecture were two completely different things.

Allan: One day at lunchtime, I wandered into a bookshop that was close to the office. I found this book by a guy called Jim McCarthy. He’s still around and he’s brilliant. He opened my eyes and I suddenly realized that the way I was taught in school was a bit wrong. It never works out like that. It can’t work out like that. Jim laid out how his team at Microsoft does things differently. I suddenly no longer felt alone or the odd one out. That was in the late 90s. That was the start of my journey to the thing we now call Agile. So, I got to do it properly and it just didn’t work.

Arsalan: I have a lot of listeners who are just starting out and who may not know about all these processes were talking about. There is this idea that exists in academia and a lot of other circles where you talk about with the best way is to build software reliably that will be maintainable and where the process that you follow is repeatable for high-quality software, just like you can do with other pieces of engineering. You can say do this and you will result in having a very high-quality piece of software with fewer bugs, fewer defects, and it will work as expected and everything will be great. Then we have this idealized notion of how to build software. We go into the real world and we see that has flaws. Tell me a little about the issues you faced.

Allan: We were doing software about trains and how trains move around the network. One problem we had was with a source control system, but when you check something and there’s a load of paperwork. So, you had to fill in these forms before you could check something in and you had to get a line manager to check in your code. It slowed everything down. Once your code was checked in, the form goes to the testing department who builds your code and they test it. So, one day we do this and it gets sent back to me with the book report that said that my train was doing this and it shouldn’t be doing that. I asked if they were sure. I went and talked to the testers.

Allan: We realized that what it said in the requirements department of what the train should do and what the trains actually do in real life are two different things. There’s this one station where the trains go in and come out in an odd way. According to the manual, it never happens. So I mentioned that we know that trains do this. So I was told to speak to one of the customs people. But I’m also told that I must find out what the trains do in real life, but not let on that the document says one thing when we think something else, because that’s a contract issue, and they have to escalate it.

Allan: This is a project where we are working six days a week. On the seventh day, you carry a pager back in the pager days because the testers are working seven days a week. So, were trying to do as much as we can and as fast as we can. Yet, we have all these paper forms flying around and all these conversations that don’t exist because you’re not allowed to talk honestly to your customers. There are all these barriers because we’re doing it properly. It was utterly crazy. The way you can write something down, and the way things happen in real life will never meet. The more you write it down, the more complicated it gets. The more you write it down, the lesser the people will remember if they do read it.

Arsalan: These things happen because as we discover that people don’t just turn up one day and they are enlightened software developers. They have a history. They have some baggage. In your case, there were some programmers who were perhaps coached and trained in a completely different coding paradigm. They are experienced, but they are not necessarily well-versed in this methodology and programming languages. Also, people have their quirks and software development is not an exact science, unfortunately. I believe it’s more like Ninja, Kung Fu stuff.

Allan: Yes. It’s a bit of everything, isn’t it? I believe software development is engineering. I also believe engineering requires a bit of inventiveness and a bit of art. I know there are people who argue about whether or not it’s engineering. I say were not good enough to be engineers. We had to get one haven’t quite mastered it. The thing is, most people who talk about software ring engineering don’t know much about engineering. There are lots of different types of engineering. I’m a 3^rd generation engineer. My father was an engineer. My grandfather was an engineer. They really had oil under their fingernails. They were ship engineers. At times, they built ships. They spent most of their lives making ships work.

Allan: As a kid of seven or eight, I’d been down to ships’ engine rooms. I saw ship engines over hulls. That informed me. I know that when you’re engineering things, that’s how the engine should work, but it doesn’t always work like that when there’s a bit of dirty oil in there. Or, the ship has to sail but the guys haven’t finished the maintenance. The ship has to sail…there’s a commercial imperative there. The idea that many people have about engineering and why they think software is a form of engineering is because they aren’t really informed about actual engineering. Engineering is the art of the possible. Engineering is making things work within constraints. That is absolutely what we do in software and it does require some innovation and some imagination, blue sky thinking, call it what you will. There are a lot of different things in there. I think that’s all part of the engineering mix.

 Arsalan: Right. So, it’s not clearly defined and it’s somewhere in the middle. Let’s talk about you, Allan. We want to understand who you are and where you’re coming from. Tell me a little about yourself. Let’s let our listeners understand who you are.

Allan: Who I am? I am Allan Kelly. I live here in London. I used to be a programmer. I used to put my fingers on the keyboard and write code. I still think of myself as that kind of person, although, no one has paid me to code for many years. I still have my pet projects at home, but when I work with teams and developers I see in them many of the frustrations that I had as a programmer. I reached a point a few years after I turned 30 and realized that I could make the code fly. I could make the code do what I wanted it to do. The code wasn’t a challenge for me anymore. The challenge was the way we are asked do stuff and the way we are set on teams.

Allan: Once upon a time a guy in his bedroom could write a program and he could make a lot of money. As a teenager, I was that guy. I didn’t make a lot of money. I made a little bit of money. I never had a Saturday job. I never delivered papers or anything like that. I never worked in a shop. I used to write programs in my bedroom and I used to them to TV, magazines, BBC, and people. That was how I had money as a kid.

Allan: Code is still a problem for a lot of people. What makes it so much more difficult is the way they are expected to perform, the structures that are put in, the way they are managed, the way their teams are sorted out, and the way the needs and requirements reach them. So, when I work with teams and managers, I see the problems they are having and I know those problems. I have lived that life. I want to help them with that problem. Before we can fix the problem with their code, we have to rethink how they’re going about structuring the code. It’s the structures, the organization, the culture and everything around it. When you’re setting up a code, what are you thinking about? Can you think clearly about your code? Or, are you worried about something else? It’s all about the environment that you’re in.

Allan: I still think of myself as a software engineer, but I don’t write the code directly. I influence how the code is written by helping teams and organizations do a better job. So, that’s what I’d say about myself if I’d had a few drinks at a party.

Arsalan: What was your first encounter with programming? How did you even know that was the thing to do?

Allan: I grew up in Liverpool in the 80’s. It was when home computers were just coming in. One of our neighbors bought a Tandy TSR80 from Radio Shack. I’d watch him and his dad typing in programs. I wanted some of that. So, I persuaded my mom and dad to buy me a machine. It was a ZED X81. That was what we called them here. It was a ZED80 machine with 1K of RAM, which, after a few months we got a PAC with 16K, not megabytes, K.

Arsalan: That’s kilobytes, people.

Allan: That’s kilobytes, yes.

Arsalan: And people are wondering what a kilobyte is. I haven’t heard that in a long time.

Allan: That’s like a thousandth of an MB, not a thousandth of a GB. So with this machine, I had found my thing. I was just hitting my teenage years. The machine and I used to commune. I moved up from this one K machine to a 2K machine with a 6502 processor. I spent most of my money for it. I used a little of the money and bought a book on machine code. So, I used to write 6502 assembly stuff. When I got a bit more money I could afford a Pascal compiler. As a self-taught programmer, I had go-to’s all over the place, but there were no go-to’s in Pascal. So I had to relearn how to program in a proper fashion the way you’re supposed to. That has still stuck with me.

Allan: I’ll tell you a funny story. When I was 16, like most 16-year-olds here in England, you do your first proper school exams where they get marked and recorded forevermore. I was one of those kids who did computer studies back then. We had to do a programming project as part of our assignment. One of my teachers had it in as one of the examiners. He told me a year or two later that I scored 98% and the programming assessment. Do you know what I lost 2% for? I didn’t use a go-to.

Allan: The exam board had this list of things that you had to do to demonstrate that you could program. One of the things that you had to demonstrate was that you could use the go to. Had I known that, I could’ve put a go to in there somewhere.

Arsalan: That’s a problem with computer science education because the teachers themselves are not equipped or trained. We follow these checklists of things. It happens now as well. You have to do this because it’s in the curriculum even though the rest of the world has realized that it is bad practice to do it.

Allan: Yes, so this is a really key point. It was one of my first big moments when you realized that those experts aren’t necessarily right. It’s like where I’ve mentioned before that, on a project where we were doing it properly. Doing it properly was hell. What is happening is with our education system and the people who are coming out of our education system of certain models. But because our technology is racing ahead, our technology is already invalidating some of those models. So if you go back to the traditional model that we used to develop software, we call it the waterfall because you have to get out the requirements and do the analysis and do the design and on and on. That makes perfect sense if it’s 1970. That model comes from 1970. We’ve spent the 70s and 80s perfecting that model.

Allan: Let me remind you of something. I’ve read up on this and most of your readers could read up on this as well as they want. In 1970, we had teletypes to communicate with our computers. If you had a screen, it was a green screen. We programmed our computers in Cobalt on an IBM 360 OS mainframe. The IBM state-of-the-art mainframe had 4 GB of RAM and 10 MIPS of processing power. My eight-year-old has a Raspberry Pie and it has 4500 MIPS of processing power and 1 GB of RAM. It is 2017.

Allan: That traditional software process that we’ve been taught makes sense if you’re programming IBM mainframes in 1970. In 1970, CPU cycles were really expensive. Paper and desk time were cheap. In 2017, when you’re programming your Lenox or Android in Ruby or Closure or one of these other modern languages, CPU cycles are now so amazingly cheap. That machine in your pocket has spent more cycles than Neil Armstrong going to the moon. Now that CPU cycles are so cheap, paper and dust time are expensive. It’s far cheaper and we can try out new ideas and get a quicker feedback loop. But, many of the things that are still being taught stem from an earlier age wall we’re racing ahead. The trick is to spot what those earlier lessons we keep and which we move on from.

Arsalan: Okay. That’s very wise because we are constantly going to always be learning and evaluating our successes and failures. Over time, the software industry tends to get better. We tend to understand how this works better. I think you will agree that context is also very important. What works in a very rigid scientific environment or an environment where the requirements don’t change, your requirements as a software developer per or your methodology may be very different from something else where you don’t understand the problem that you are iterating.

Arsalan: We’ve talked about Agile. You’ve referred to it a few times and mentioned that we didn’t have this term Agile before. You’d also don’t necessarily like this term because it doesn’t encompass everything. So, tell us a little about what you mean by all this.

Allan: The only thing that you can really do wrong. If you claim to be Agile, is to do things the same way that you did them three months ago. You should constantly be experimenting, innovating, and trying new stuff. Some of it is going to work and some of it is going to fail. I say that in and Agile context, but really that applies to all software development. That’s because software is always changing. By definition, when we create software, we are creating something new and innovative. If it already exists, you’re going to reuse it, take it and download it from source Forge or somewhere. If you have some code that already does it, you aren’t going to write it again. Instead, you’re going to do control C and control V. You’re going to copy it.

Allan: When we’re writing code, we are always doing something new. We are always innovative. All software development is about learning. We are learning about our tools, our languages, and our options. That’s the most obvious thing. We are also learning about the problems we are solving. Whether you are creating medical equipment or train software or iPhones, you’re learning about the problem you’re trying to solve because we don’t really understand the problem that we’re trying to solve. We think we do. But the truth is that as we are creating the solution we view the problem in a different way. The next time you’re having trouble getting email on your phone, that’s a new problem. How many people 10 or 15 years ago knew that we would get email on a phone? How many people 10 years ago knew that they needed to send 140-character message to the world?

Allan: We are constantly doing new stuff. As we are doing this new stuff, we are thinking of new ways of approaching it. We redefine the problems we are approaching and addressing. We create new problems to solve. So, the second thing that we’re learning is about the thing that we’re creating. The third way that we are learning is about the processes and actions that we are going to use to go about doing this. To some degree, we are learning about learning. For me, all of our technology and software is a multi-layered learning process and we are constantly layering.

Allan: I think that the traditional model, the thing that we call waterfall, tried to freeze learning and tell us that we’ve learned all about the problem. We have written it down. We have now studied the architecture and we have written it all down. We will now give it to a simple programmer who will code something up and when he is done, that will pass the test. We try to put in boxes and freeze it, but what we see is that those boxes feedback to one another. Over time, as we’ve gotten faster, our cycles are getting faster and faster. Our chain cycles are getting faster and faster. So those boxes are interfering with each other at a faster rate. The big thing about Agile is that Agile suggest that we have a model that incorporates learning. It’s the kind of model where we do something and see what happens, we think about it, we reflect on it, and maybe that changes what happens.

 

[convertkit form=4889308]

Important Links

• AllanKelly.net

 

Thanks for Listening!

Do you have some feedback or some advice for us or our audience? Please give us a review on iTunes or Stitcher and share your thoughts.

If you found this episode useful, please go ahead and share it with your friends and family. You can do that easily using the social media buttons at the bottom of this page.

Subscribe to the show on iTunes or Stitcher (for Android users) to automatically get new episodes every Tuesday.