Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Spotify | RSS | More

Jess’s Bio:

Jess Chadwick is a software developer and technologist with over fifteen years of development experience ranging from embedded devices in start-ups to enterprise-scale solutions in Fortune 25s. He is an ASPInsider and a magazine and book author with O’Reilly publishing, as well as several courses on Lynda.com including Up and Running with ASP.NET 5. Jess is actively involved in the development community, regularly speaking at user groups and conferences as well as co-lead of the NJDOTNET Central New Jersey .NET user group.

Episode Highlights and Show Notes:

Arsalan: Today we have Jess Chadwick with us. Jess, how are you?

Jess: I’m doing alright and glad to be here.

Arsalan: I’m really happy that you’re here because you’re very experienced. You have done a lot of work and would like to learn about you and from you, but first I’d like to ask you to describe yourself.

Jess: I call myself a web developer and technologist. I know I’m flat out stealing that from Scott Hanselman because that’s how he describes himself. But, honestly, the first time I heard that from Hanselman, it described me. I’m a web developer by trade by day, but I’m also a technologist. I’m very much into using technology and it just so happens that web development is my current passion.  It’s how I’ve been making my living for the past almost 20 years now. I’m also pretty big into the community as well. I also consider myself a community leader and I like to give technical presentations. I like to give back to the community.

Arsalan: Do you code every day?

Jess: I do code every day. I work at a big enterprise. I’m not really aloud to say where exactly I work on a podcast, but you can look me up on LinkedIn. It’s on there. My title is manager, but I was hired to be a very hands-on technical manager. So I am coding every day. When I began with this organization, they were looking to move into the client side world and they wanted to do it right. When I came onboard they basically asked me if I wanted to be on the production team or the infrastructure team, building frameworks that the rest of the product teams use.

Jess: I chose the production team because I wanted to be on the front lines putting out code and dealing with real world problems. So, I spend a significant amount of time writing code daily that goes into production. Then, at night I come home and write some more code. But that’s more of those to-do apps. So I dip my toes in both. I use my nights to exercise the new technologies. I’m in a big enterprise and I don’t necessarily always get the chance to use the latest and greatest. So, I stay on top of things at night with the pet projects that I have.

Arsalan: I hear you and obviously you don’t have a family so that works out, right?

Jess: No, I put family first. When I was looking for a job the commute was the number one thing because then I could get home and see my family as often as possible. I have two young girls, ages two and half and almost six. So, they go to bed relatively early. My wife is a teacher. So, she goes to bed relatively early too. But, I am a night owl. So, I stay up until 2:00 and sometimes 3:00 in the morning. I can work pretty well on between 4 and 6 hours of sleep. It’s because I love this stuff that I can put in the extra time. I make it a priority to spend time with family and also take time out for myself as well.

Arsalan: I think you are my twin. I also have two girls. They are ages 5 and 1 and a half and my wife is a professor, so she’s also a teacher. Do you remember your first encounter with programming?

Jess: Vaguely. I remember coding all the time as a teenager. I can’t really pinpoint the first time that I really started coding, but I do remember that my dad was a developer when I was young. He began as a construction worker and a cabinet maker, but then picked up some books and got into developing. So, in addition to learning how to program, he also learned how to read. So, he learned by diving into books. So, all these books were just lying around. I saw a Basic book sitting around one day. I picked it up and started reading it. The next year I was coding the Choose Your Own Adventure games on Basic.

Arsalan: Did you use GW Basic, by chance?

Jess: Yes, GW Basic

Arsalan: That’s what I used to start. You are my twin.

Jess: Yes, definitely. I started out with games, just as all the kids start, I think. I don’t remember the first line of code I ever wrote and I also don’t remember the first experience specifically. But, I do remember this awesome feeling the very first time I finally got an application to run and the computer to do something. I was hooked from then on and it’s never stopped since then. I still get that feeling today almost 20 years later when I succeed at doing something.

Arsalan: That’s really good, I can definitely relate to that. I think that if you lose that spark and passion, then perhaps it’s time to stop coding, and there’s a need for managers too. Did you study computer programming or computer technology?

Jess: I did go to college for a little while. I went to Drexel University in Pennsylvania. It’s not ivy league or anything, but it’s a pretty good school in the region.  That’s why I went there and I knew I wanted to learn tech. I never considered myself really big into math and the truly deep analytical thinking, so I wanted to stay away from computer science. It was way too technical for me. So I chose information systems. It’s about dealing with and finding information. So, one of the classes I had was how to use Google. I also had computer classes, but they weren’t big into computer science, which is why I chose the major.

Jess: One of the reasons I went to Drexel is that they do coops. So, they get you in the workforce as early as possible. The summer after my second year I was in the workplace and I was a junior developer making junior developer money, which was $40,000 a year. So, I was think that I was making real money, so why continue on with college? I love learning and that’s really the only reason I continued going. What really got me was that I would start going to classes and realize that I had taught myself what I was learning then the previous year. It always seemed like I was one year ahead of what they were teaching until I eventually switched my major to finance.  I decided that since I was paying for the degree, I might as well get something out of it and learn something. I went for another year or two and then I just dropped out because I was already in the workforce and making money, and I loved what I was doing. So, I went through some college, but I didn’t actually finish. But, so far it hasn’t been a problem for me.

Arsalan: So, has anyone ever asked you in any of your interviews about your college education?

Jess: I’ve been asked about my background and education at pretty much every interview I’ve ever had. It’s a pretty standard question, at least on the application, even if it doesn’t come up at the interview. I always put down “some college” and the GPA. I don’t lie. I’m not trying to be subversive or anything. I’m just trying to say that I did go to college, I just didn’t finish. It’s only been a problem twice in the interviews that I’ve been on. Once, I didn’t even get to the phone interview phase. But, quite frankly, I don’t want to work for a company that values degrees over experience because by that time I was far more than a mid-level developer. I had a lot of experience and definitely qualified for the job, but the company just wrote me off because of the degree issue. The second time was actually the job that I’m in right now. Since it was an enterprise, there was a required background check for everyone and it just came up and then the conversation came up. I was told that it wasn’t an issue for the position that I’m in now, but it could become a problem later on as I move up the ranks.

Arsalan: I already know what you’re going to say, but I want people to know the pros and cons of getting a degree. There are so many people that I’ve worked with and I’ve worked under, who are my superiors and who don’t have computer science degrees. In some cases, they don’t have any degrees and in day to day work, it never comes up. I know that people can get jobs. There are certain companies who will filter you out, but other companies won’t. There’s also the perception that if you don’t have a degree that you will make less money than someone who does. I want to get your opinion on this.

Jess: I can’t really answer that because when I was in college doing the coop I entered the workforce as a junior developer and I was paid as a junior developer. I went directly into a junior role and was expected to do junior tasks. So, for me personally, compensation has never been an issue. I was always compensated based on my experience and skill level. Even in the role I am in now when the conversation came up about me not having graduated, it was still completely separate from the compensation discussion. From what I’ve seen, which is not much, it hasn’t affected others around me either.

Jess: I agree with you. A lot of the folks I’ve dealt with haven’t had degrees and many of them who have had degrees have had them in a field other than computer science. One of my managers a while ago had a degree in medieval history or ancient history, something like that. That was his degree because that’s what he was interested in. I’m not criticizing it. But how does your degree make you a better developer or even a better manager? It doesn’t. It was a degree and it was a check box that he could mark off to say that he went to college and graduated. That’s it.

Arsalan: Do you think that people without degrees have to come up with other ways of proving their credentials? The obvious answer is that if you can Opensource your projects and put them on GitHub or something then that is one avenue, but it is not available to everyone because the work is proprietary. Is there a way that people should compensate for something?

Jess: I don’t think so. It’s funny because I have this conversation with my wife all the time because she comes from a family who are very big on education. So, the conversation has come up a couple of times already in the family. They all respect me, but I think the fact that I don’t have a degree is held against me a little bit. I always say that it’s not the education. I love learning and knowledge. It’s just that I no longer saw the value in going to college and getting a degree. I wasn’t learning the things I wanted to learn and it wasn’t benefiting me personally or professionally. So, why bother? I found other avenues to learn things.

Jess: As far as advice for new developers coming in and wondering whether or not you should get a degree, I’m not going to answer that because that’s a personal decision and it involves a lot of variables and things. What I can say is that it hasn’t been a problem for me that I don’t have one. What I can say is as a hiring manager, as a team lead and a coach, what I look for coming in is intelligence and passion. I look for analytical thinking and I don’t care what your degree or background is. When I interview, I look at your resume and I pick out buzz words and I will ask you to tell me about that. I want to have a conversation to hear how analytical you are about problems.

Jess: Where I’m at right now, we’re big on Angular. We’re writing Angular applications. So, that involves a lot of JavaScript, HTML, and frontend knowledge. I’m also bringing on some junior developers. So, junior or senior doesn’t matter. When you come in the door, I don’t care if you know Angular. I care if you are familiar with JavaScript, but I care even more if you are really passionate about web development and if you’re intelligent enough to pick it up. I can gauge passion and intelligence pretty well in half an hour. What’s really important is when I ask a question during the interview and you don’t know the answer, what will your answer be? Do you make up the answer? I know the answer to the questions that I ask you

Thanks for Listening

Do you have some feedback or some advice for us or our audience? Please give us a review on iTunes, Spotify, Google Podcasts, 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 also listen directly and give your feedback on the website.

You can subscribe to Mentoring Developers via iTunes, Stitcher Radio, Spotify, or Google Podcasts. 

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Spotify | RSS | More

Kevin’s Bio:

Kevin Mack is a developer, designer, and consultant. His area of focus is on creating user interfaces and experiences for large-scaling websites. Kevin is also a co-founder and co-organizer of The Columbus Web Group where he actively participates in growing and educating the community centered around design, development, best practices and standards for the web. You can find him on Twitter (@nicetransition), LinkedIn, YouTube, CodePen,  or GitHub.

 

Episode Highlights and Show Notes:

Arsalan: Today we have Kevin Mack on mentoring developers. I really wanted to have you on the podcast because your different perspective. You do a lot of mentoring and teaching, and you focus on a lot of different interfaces and user experiences. So, this should be a nice and unique interview for our listeners. But, before we get into that, I’d like to you to explain to us who you are. Who is Kevin Mack?

Kevin: have a pretty crazy background. I’ve been developing since 1995, but really grew up around art. My mom was an art director at the Washington Post and she always said that I could draw before I could talk. So I grew up around art and started development around twenty years ago and sort of married the two together. So my whole life has been involved with arts, computers, and bringing people together. I love community organizations and just meeting new people and getting involved in new organizations.

Arsalan: is it fair to say that you described yourself as a programmer or software engineer?

Kevin: I focus on building interfaces and I focus on building interfaces and what I do falls between a designer and a developer. I’ve learned a bunch of languages over the years, but primarily I focus on the front end code and the HTMLs, CSS, and JavaScript. On a day-to-day basis, 90% of the code that I’m writing is in CSS and HTML. So I do sometimes call myself a developer, but I’m a UI, UX.

Arsalan: Do you remember your first encounter with programming?

Kevin: Yes, for sure. It’s kind of a funny story. My buddy and I wanted to make websites. We wanted to record clips, post them and share them so that we could have some kind of reference to them later. So started building websites and doing these really silly recordings and posting them up there along with some early day blogs before they were called blogs. I remember watching how the page was rendering and taking some of those concepts in my head. In 1995, there wasn’t all that much to do. I remember all these tables stacking next to each other. Back then you used tables to set up the grids for the layouts of your pages and no one really knew what they were doing. I was just really fascinated.

Kevin: When it really evolved later on to CSS, I remember thinking how cool x values were. The day that I started learning HTML was the day that I got hooked. That’s when I decided that I really wanted to be a developer.

Arsalan: So you were focused on user interfaces and user experiences. You code in HTML and CSS, which are the technologies or programming languages that you need to know if you want to develop a website and hand code it. You also dabble in design. Do you spend a lot of time in Photoshop?

Kevin: Over the past years I have, but recently we’ve switched over to Sketch. It’s an awesome program. The way that you design in Sketch is more closely related to the output and the output being in line with the web browsers. It’s aligned better with today’s technologies and the web browsers, but I do spend a fair amount of time in Photoshop. We always design the content first and how the content is cascading throughout the pages and then from there getting some high-level sketches out there, and then creating an element collage by indexing all components that eventually make up the design that people are going to be interacting with. From there, we put out some high-level page concepts to help ensure that the development team and design team are on the same page. I do use Photoshop and Sketch, but there are a lot of other steps that have to happen first before I can get there.

Arsalan: That’s good. I didn’t know about Sketch. Thank you for informing me. Did you study any of this at school at any level?

Kevin: Not really. It was all myself and my buddies reaching out and trying to learn and taking on a bunch of contract work and making a lot of websites for my friend’s parents when I was in high school.

Arsalan: So, do you have trouble keeping your skills up to date? How you keep your skills up to date when things change?

Kevin:  On the design side there are some visual trends that happen and we’ve kind of stabilized, but experiences have really evolved. So, when a new technology comes out we have to know how we’re going to design and create the experience that is right for these new capabilities that our users are expecting when they’re coming to our sites and apps. It’s keeping up with the devices and the trends that are going on and ensuring that we’re aligning to the capabilities of the browser. Then, it kind of directly aligns with the front end side as well.

Kevin: I spend a fair amount of time each week reading about the latest CSS. Level four CSS is going to be coming out here soon. A lot of specs and drafts are out there. I’m subscribed to a lot of specs and drafts and we’ll contribute to them.  I’m constantly going out there are reading. I subscribe to a lot of blogs. One of my favorites is CSS Weekly, Javascript Weekly. I also get this monthly one called JSter.Net. My friends and I also run a Facebook group called RAD. It stands for Really Awesome Developers. It includes some of the best developers and smartest minds from a technology standpoint. It’s a closed group, but we admit anyone in it if they’re interested. I probably spend 10 to 20 hours a week keeping up on things.

Arsalan: So, someone listening to this might think, Oh my God. You just listed ten different things. If you just spend two hours each week on each one of them, that’s 20 hours a week. Unless you are spending some of the time on them as part of your job, someone might wonder how you can do that. Do you not sleep at all? Or, maybe that’s your entertainment?

Kevin: I’m a pretty social person and I think I have a social life. But, a lot of my friends are within the industry and even when we go out, we say we’re not going to talk about technology or work, but we end up doing it anyway. I think that to be really good at your job today, I think employers expect you to be up on the latest trends. I’m not going to speak to every single company out there, but a lot of the research and keeping up with things go hand in hand with my day to day work.

Kevin: I’m also a consultant. I work at a tech company that’s called Cardinal Solutions and I’m a consultant who does UI and UX. For us to really be considered a quality consultant, our clients are expecting us to know the history of the web, the latest trends, and what’s coming in the future. So, I can use some of my time on my job to do that because there’s a lot of overlap there. It is little pockets of time here and there. When I get home and am cooking dinner, I’m also reading something while I’m waiting for dinner to finish cooking. It is what I love so it also serves as part of my entertainment. I’d rather read up on the latest trends than watch a movie.

Arsalan:  I think this is really admirable to have this much dedication. I knew you had this much dedication, but I wanted people to hear you say it yourself because it’s hard for some people to imagine living like this, but you’ve got the bug, and you’re enjoying it and reaping the rewards. I really wanted to congratulate you because you are doing something that a lot of us are not able to do.

Arsalan: You’ve talked about a lot of your jobs. You have a job right now as a consultant for a consulting company. Before that, you worked for agencies and you probably had several jobs in your career. Do you remember how you got your first job as a designer or a software engineer?

Kevin: During my earlier days it was just people in my class who knew that I did computers and one parent would tell another parent and they would come and talk to me. That’s how I got my first job. It was doing independent work for people in my class.

 

Important Links

• Sketch
• CSS Weekly
• Javascript Weekly
• JSter.Net
• Cardinal Solutions

Thanks for Listening!

Do you have some feedback or some advice for us or our audience? Please give us a review on iTunes, Spotify, Google Podcasts, 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 also listen directly and give your feedback on the website.

You can subscribe to Mentoring Developers via iTunes, Stitcher Radio, Spotify, or Google Podcasts. 

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Spotify | RSS | More

Edward’s Bio:

Edward Stull works as a user experience (UX) designer and researcher in Columbus, Ohio. He has held positions in large traditional agencies, mid-size system integration firms, small design studios, as well as a one-person consulting practice. He has worn many hats during his career. Thus, his background grants an uncommon perspective into how various teams understand, practice, and sell UX. When Edward is not working, he is usually hiking.

Episode Highlights and Show Notes:

Arsalan: today I have the pleasure of interest introducing you to a user experience guru. He has written a book and is in the process of writing a book in an audio format as well about user experience. Usually I asked my guess about themselves first, but I think I’m going to change it up a little and ask him about user experience first. What is this user experience, Ed?

Ed: That’s a great question and the challenges all of us to try to make an adequate explanation of it. User experience as a whole is just the result of using any product or service. Second to that is user experience design. That’s the professional application of trying to create effective user experiences. That often becomes a combination of taking what a user wants to do and what a business wants to do and trying to find ways of reconciling that so that you have a good user experience resulting from that.

Arsalan: Now that we have that out of the way, let me introduce you. Your name is Edward Stull and you are a consultant and you do user experience design. How do you describe yourself?

Ed: Well, you know, I think you just did a great job with it. When I introduce myself, I usually tell people that I am a user experience designer and researcher. About half of my work is the actual design, where I’m trying to generate sometimes documents, but often it is brainstorming and trying to help teams solve software and sometimes digital marketing issues. The other half is a combination of primary and secondary research. It’s not as robust as a traditional academic role, but a lot of times I do a combination of usability research, accessibility research, and third-party research.

Ed: I spend a lot of time going through research reports, as well as secondary and tertiary research sources to be able to be able to support any types of decisions were doing concerning software with evidence.

Arsalan: So, are you doing this research as part of a billable work project for a client or just to keep up to date?

Ed: I would say that at least the way I was defining it the first time is that it tends to be a paid engagement. Not all projects require research and there’s not always the case where you have to do a large research study. Sometimes it’s a matter of just doing the due diligence and realizing what audience you are speaking to or, say, a client’s business and the sector they operate in. That could just end up being research. There is also a lot of research just to keep yourself marketable. It’s just the state of the nation in terms of what’s going on from a UX and information architecture perspective.

Arsalan: Besides user design and experience you’ve also dabbled in programming. Can you tell us a little bit about your experiences in programming, what you’ve done so far, and how you got started with that?

Ed: I think I would completely under pressure audience with my knowledge of programming. But, it makes me a better user experience designer. My knowledge is primarily based on scripting languages and things like HTML and client side work. My work with iPhone apps has helped me a lot. It has really helped me understand that type of structure thinking has really helped me to understand system based design, being a lot more cognizant of the fact of any type of user experience, design or deliverables that I’m doing. It has really helped me to be more cognizant of the people who I’m working with and has helped me to better collaborate with developers hand-in-hand, or work with anyone who’s going to receive the product that I’m designing. It is something that makes me better at what I’m doing.

Arsalan: So, you have done a whole lot of different things. My feeling is that you have not studied computer programming and a formal environment. You’ve probably also not studied user experience in a formal environment. I’m saying that because I don’t know if anyone is actually teaching that. So, what was your education like?

Ed: I actually went to school thinking I was going to be a painter. I ended up graduating with an advertising degree. Then, I was a creative director for a while. I kind of migrated into doing user experience close to fifteen years ago or so when it was more commonly called IA work or information architecture. User experience has essentially evolved out of that, as well as a few other disciplines.

Arsalan: although your education wasn’t directly related to what you’re doing right now, do you think your education was helpful?

Ed: I think most people find themselves in a career at some time wondering if there formal education helped. There are adjacencies with what I’ve learned. For instance, the research perspective helped because I had some wonderful copywriting instructors. Although that may not sound like it’s related, it did help in terms of the structure thinking that it required. To be able to really ferret out and say what is the data that you’re working with and then trying to arrange or rearrange that in some new way. If that happens to be written prose for copywriting or formal research projects or information architecture with UA and UX design. These things come off of a common origin even though the results are often different.

Arsalan: I think I’m really excited to have you here tonight because you are a user experience expert and I have my opinions on user experience. It’s very general. It’s nothing very specific. I’ve read parts of your book and I am completely overwhelmed and I don’t think I could talk to about user experience. My idea of user experience is the quality of interactions that a user goes through that results in a satisfactory outcome and that’s very subjective.

Arsalan: In my worldview, every user interaction should result in a happy customer. It should result in a customer who is able to achieve the goal that he or she set out to do when using the application and that should be done in a way that’s compliant.

Arsalan: In my world, if your application is slow and it forces the user to change their behavior in their activities just to work with your application that is a bad user experience. I know that some people have no clue about user experience and they may even think that it has something to do with user interfaces, which it is in a way. UI and UX have one thing in common and that is you. From my point of view, I should know how to create a good user experience for my users. We need more people to go into user experience and design. That’s why I had you on, to inspire some people. Hopefully, a lot of our listeners can think about it, read your book, and perhaps start working as user experience designers, and perhaps you can mentor them.

Ed: I think your explanation of it was very spot on. Everything that you said was exactly correct, but I would add that the user experience is not only giving the user what they want but also reconciling them with the goals of the business. It’s important to also make the application fast performing. A well-performing application, even poorly designed, is far better than a poorly performing application, well designed.

Ed: What I often tell people to do is to imagine an iPhone app or an android app that you are using and it just has one button on it that says ‘give me a dollar’. Everyone in the world would click that button to see what it does, thinking it must be fantastic. Now, every business in the world would love to have that button read ‘give us a dollar’ so that every user who hits that button is going to essentially give the business a dollar. Neither one of those cases is going to be worthwhile. If every time you hit the button, you got a dollar from the business, that business would go out of business pretty quickly. If every time you hit that button you gave a dollar and got nothing in return. Then as a user you were not being paid off. So, there has to be some way of reconciling this kind of value.

Arsalan: I think we may have to have you come back to this podcast a couple of times to really dig deep into the psyche of what we need to have in our head to really produce good user experiences. I think that this is a very deep topic. How you keep your skills up to date? You do a ton of reading and research and you’re dabbling in program development for iPhones and android apps among other things. You have a busy life. How do you keep your skills up to date?

Ed: honestly, I’m really not all that unique in trying to keep these things up to date. I do probably have a little more time available to me as a consultant. I’m probably lynda.com’s biggest user. There are many great sources, but that is just endlessly fascinating to me that you can listen to tutorials and screencasts and pick up anything to gain a functional knowledge of things. It’s nothing that would be professionally viable, but it’s enough for me to kind of gauge and learns a few things. That then spawns me to Google the heck out of stuff. If I run into something and I don’t know what it is, then I might go over to Stackoverflow or something. It’s almost like task-based learning.

Ed: you had mentioned something like that in one of your recent podcast with Derek Bailey, I believe. You mentioned just-in-time learning. A lot of that stuff resonates with me too. I love reading a book from cover to cover, but I often find that if I need to build something in a development language that I don’t have a whole lot of personal experience with, this kind of learning helps me to take care of a particular task.

Arsalan: That’s a really good point. And as you mentioned, the just-in-time learning idea is that you only learned the thing that you need right now. You don’t learn for the sake of learning. I’ve done both. I love to learn for the sake of learning because I’m so curious. I just want to know. But, I know that it takes a toll on my own time and sanity. Sometimes I just learn as I need to learn. If I’m building a particular website and I need authentication for that, I learned how to do authentication.

Ed: I think there are some people who are inherently more curious than others. You really do run into a situation where there just isn’t enough time to learn everything that you want. What I often try to do is triage it in a way. There are things that I have to do to keep my lights on as a consultant. All of that stuff is kind of like a first level priority. The second is kind of what we’ve talked about with trying to solve different tasks. But, the third level is where I will pick something up that perhaps I’m weak at, but am interested in.

Ed: If you are just learning things to kind of keep your lights on, then it can be exhaustive. Some people are better at it than me. I think there’s this way where you can find these various levels of learning where you’re like okay this is the type of learning that’s keeping me gainfully employed, this is the stuff I need to do, and these are the things that are interesting to me that don’t necessarily contribute to the first two levels. It’s a lot easier to keep the momentum going, if you make it a regular habit.

Arsalan: That’s an excellent point. You have to schedule this learning. It’s not just going to happen. If someone says “in my free time I will learn to ask,” then there is a very strong possibility that you will never have free time. If free time means that I am not doing anything, then I don’t have any free time because I am always doing something, even if it’s just watching TV. But if I put it in my schedule, like if I say one hour before I go to bed, I am going to do this thing that becomes a task for me. It is not part of my free time anymore. It’s work.

Arsalan: If you treat learning like work, then, over time you will accumulate all of this learning that seems impossible. Imagine doing that for a whole month. Say you do one hour a day for thirty days. Now you have thirty hours of learning.

Arsalan: While you do have to learn some things, as you said to keep the lights on, you also have to learn some things to broaden your horizons. You also need to learn what to learn. Let’s take web development as an example. Every six months to a year. The technology landscape changes all the time. New languages and frameworks and tools come out. It’s a never ending ride. So, how do I know what I should learn?

Important Links

• Lynda
• Stackoverflow

Thanks for Listening!

Do you have some feedback or some advice for us or our audience? Please give us a review on iTunes, Spotify, Google Podcasts, 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 also listen directly and give your feedback on the website.

You can subscribe to Mentoring Developers via iTunes, Stitcher Radio, Spotify, or Google Podcasts. 

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Spotify | RSS | More

Sarah’s Bio:

Sarah is a Ruby and JavaScript developer based in San Francisco, California. As the Chief Consultant at DevMynd Software, she spends most of her time pairing with her clients’ developers, helping level up their team. Her particular areas of interest are Object-Oriented Programming, service refactorings, growing teams, and inter-developer dynamics.

She has written about my experiences pair programming and also her approach to testing but her most popular article, by a huge margin, is about the dangers of shiny new technology.

Sarah is writing a book with Sandi Metz about how to refactor Rails applications towards happiness and she can be found on Twitter, GitHub, and LinkedIn.

Episode Highlights and Show Notes:

Arsalan: Today we are going to talk to Sarah Mei once again. Sarah was here for an interview earlier. If you missed it, go ahead and check it out. This will be the 2^nd part of the interview. Could you please describe yourself?

Sarah: I am a software developer. That’s how I see myself. Although, I believe it’s been a year or 2 since I’ve done full-time coding. These days I do roughly half time coding and the rest of the time I spend doing other things like writing, blogging, working on talks, or doing conference work. I’ve been doing programming since around 1996. So, this year will be my 20^th anniversary.

Arsalan: We should celebrate. We should have you on the 20th-anniversary special.

Sarah: Yeah, that would be awesome. So, I’ve been a developer for most of that time. I made a couple of brief forays into management, but most of the time. I’ve done coding. In the last 10 years or so, I’ve also added a bunch of community work to what I do. These days I do a lot of work with conferences and I also do a lot of work with Rails Bridge, which I cofounded in 2009. That’s what I do and that’s who I see myself as. I’m always interested in hearing what how other people view me.

Arsalan: You’ve done so much work and so many things over the course of your career. It’s hard to describe you as a person who does a single thing. I see with someone who’s inspirational. You have opinions in your letting people know that. People need to know that this is how you can be someone who is successful and conscientious and social. For all of the new developers out there, Sarah is a good role model.

Arsalan: So, do you remember your 1^st encounter with programming?

Sarah: I do. It was quite a while before I started programming. We had an Apple IIC computer with an old greenlight monitor. It came with the book of programs and basic that you could type in. There was no explanation. It was just look at the book and type that into the computer. I did one of them and it was vaguely interesting. But, there was no way to save the program. I would’ve had to type that whole thing in all over again. So, I was like “Really? Why am I doing this?” I try to type in another one, but I must have made a mistake somewhere because it didn’t work so I just gave up. I think I was around 10 or 11 at that point. That was the last time that I looked at programming until college.

Arsalan: Why did you pick it up in college?

Sarah: It was accidental. I went in as a structural engineering major. I thought I wanted to build bridges and things like that. I had a weird schedule because I was trying to take language classes and other things at the same time. So, I was looking for electives that would fit into my schedule. There was a programming elective that fit into my schedule so I took that. It was a class called Numerical Methods in Fortran. This was not a programming class that many of the students were taking because Fortran was an old programming language from the 1960s and we were already in the 1990s. It was about doing mathematical calculations, but I loved it. I found it amazing.

Sarah: So, I went and talked to the professor about it and he said, “Well, if you like Fortran than wait until you try a real programming language.” So I took another programming class in C and he was right. C was way more interesting than Fortran. From there I ended up switching my major and going into the computer side of things. I had this feeling that I wanted to build things which is why I went into structural engineering. But, computer programming gives me that same sense and more often. It was addictive.

Arsalan: Were you doing programs to solve real-world problems? Or were you just playing around with the API making Hello World type of programs?

Sarah: A lot of it was stuff that was not super useful to the real world. It was like a command line calculator. What kept me going was that I could see that this was something that was going to be useful in the future. I was going to be able to do things with this, but I had to struggle through the part that was kind of boring in order to get to the place where I could do something useful. I felt that I could make a difference with the world through programming in a much more concrete way. That’s what I liked about it. I motivated through what you can make with it.

Arsalan: It’s the creating something that doesn’t exist and that you are solving a problem. All creative people enjoy that. So, a painter is not necessarily someone who enjoys the brushstrokes, but rather creating the final product. That was the number 1 reason for me wanting to be a software developer. It was because I wanted to do something and make something.

Arsalan: So, you started coding, you got into college and started getting really serious with this. I’m assuming that you graduated with a computer science degree.

Sarah: That’s right; I ended up with the computer science degree.

Arsalan: After that, did you have any trouble getting a job?

Sarah: I came out of school in the late 90s when the.com boom was still going. It wasn’t as crazy as it had been, but it also hadn’t popped yet either. Most of my friends got jobs rather quickly. But I hadn’t been in the programming world so I didn’t know how to get a job in the industry. Most of the programmers that I knew had been programming for a long time, so they knew what to do, but I didn’t.

Sarah: I thought about staying in academia, but I realize that a lot of them didn’t realize how programming was made. They know how computers work and so that’s how I learned. They know the parts that make up the computer and what you can do with it in a general sense, but they really don’t know how a group of people build a specific piece of software. That’s just not what they do. So, I felt that was the biggest gap in my knowledge. It occurred to me that knowing how to build stuff in the group was one of the most important skills to understand in order to make something useful.

Sarah: I went with the biggest company that came to the career center, which turned out to be Microsoft. So I moved to Seattle. I stayed there for a couple of years and worked in Redmond. Most of what I discovered there was how I did not want to make it in the future. Ever since then I have worked at smaller companies. One of the things that I personally discovered was that the bigger the company you are at the more removed, you are from the front lines.

Sarah: The thing is the code you write or the product that you work on or the feature that you add, there’s no way to really trace that back to the company’s success. I found that unsatisfying because it felt like I was writing code, but throwing it into the void. People are using it, but I don’t know if it’s useful. I can’t tell how much my contribution is mattering to the company. At the time Microsoft was still burning products onto discs that needed to be shipped somewhere else. So, they practiced an extreme waterfall method of software development. I didn’t know any better because I had never worked anywhere else as a software developer. I think my time there was useful because it gave me a sense of what the spectrum was like, and were I wanted to be.

Arsalan: This is a problem that we deal with when we’re dealing with large companies or corporations. It’s that doing anything other than waterfall style programming becomes difficult and we need to get buy-in from the management who does not want to cede control.

Sarah: Any company that is at the level where management does not know everybody is going to have this kind of problem to some degree. When you get up to these higher levels, they really do have so many people that they tend to think of them as interchangeable cogs.

Arsalan: That’s a problem that large teams always have. Management likes to have control over product delivery and they think they have control. They think that big design up front is going to give them more control when just the opposite happens.

Sarah: It gives them the illusion of control without actually giving them the actual control.

Arsalan: So, let’s describe waterfall strategy because a lot of people out there may not know what that it is.

Sarah: Absolutely. When software was just getting started as a commercially viable product in the 60s and 70s, most of the stuff they were building was line operations. They were things like payroll systems and those kinds of things. They thought about software the same way that the thought about hardware, which was that you needed to specify up front everything that you needed the software to do. They would have a phase at the beginning of the product that did not involve the developers at all but rather involved those who were involved in the business aspect of it. They would imagine everything they wanted the software to do. They would negotiate what they wanted and what they could have. At no point is the technical staff involved in this yet. They often specify it down to very minute details. They do all this without ever seeing anything actually working. Once they’ve specified everything they think they want the software to do, then they give it to the software designers or architects who would design a software system that could do this thing. They would do all that without ever writing any code or touching any computer. Then, it would be turned over to the developers to implement that design.

Sarah: The reason they called this type of developing “waterfall” is because you can think of it as a kind of waterfall that goes down in a cascading series of pools. So it starts in the top pool which is product design, and then when it moves down to the next pool that software design, and then down to the next pool is software development. When it’s done there, it moves down to the next pool which is software testing. Over the years, they figured out that there were shortcomings with this model. The real shortcoming is that the feedback loops are very long. So, if they make a mistake somewhere in the 1^st stage, it may not be obvious until they have working code. At that point, it’s very expensive to fix because they’ve gone through all of these other stages in the meantime.

Sarah: We don’t want a process that reduces mistakes, but rather is resilient to mistakes because we are going to make mistakes. So when we’re talking about the waterfall method we’re talking about creating software that may take only a day rather than a couple of years based on the methodology. When you’re using this method, you’re betting against human frailty and it’s never a good idea to bet against red human frailty because people are messy, inconsistent, and they make mistakes. We need to make sure that our software doesn’t assume an idealized perfect person because that is only going to lead to disappointment.

Arsalan: Software by nature evolves. The things that you can hold in your hand ‘do not evolve. Say for example you’re building a television that’s not going to evolve over time. Once it’s done, it’s done, and people usually understand that. The designs are usually simple. Since software is somewhere on the ether, people have this idea that software is constantly changeable. That’s one problem. The other problem is since they haven’t seen anything like it, they kind of take an existing one and change it a little. Another benefit is that you are not depending on someone doing a huge 200-page write-up that describes a thing; because there’s no way that we’ll ever be accurate.

Sarah: Exactly. Usually what happens when you have these documents is they make assumptions very early in the process and then they write the entire document based on those assumptions. For example, they might build this entire software system under the assumption that the users will be familiar with accounting software when in fact they find out that this needs to be designed for those who may be new users of accounting software. That means that they’ve just invalidated all that work and you end up wasting a lot of people’s time. It’s very frustrating.

Arsalan: I want to talk to you about some of the topics you’ve written about in the last few years. One of them is pair programming. Can you describe to the audience what pair programming is, what’s good about it, and what’s bad?

Sarah: Absolutely. Pair programming is something that sounds like it would never work. It is two people sitting in front of the same computer with two keyboards and two mice and both are working on the same piece of code. If you are used to programming by yourself, this might sound crazy. In reality, it’s like having a conversation and some code gets written incidentally, but you always have someone to talk to about all the decisions you’re making about code. So, when we implement a feature we make thousands of tiny decisions about things like where the code should go, how it should be implemented, which algorithm to use, which method in the standard library does what is needed, or does a new one need to be written. Each of those decisions gets looked at by two people at once. It’s almost like synchronist code review.

Sarah: In the worst case, this can be a very daunting, intimidating, negative experience because people are coming in without the entire context in which the code was written. They will make comments that will feel very personal.

Sarah: At best, it takes longer than if you’re pairing because the person has to acquire the context in order to review the code effectively. So, usually what happens is a couple of people may look at it very perfunctorily and either okay it or don’t okay it. As a result, a lot of code is never reviewed by more than one person. You may think that if you’re the only one who knows your code that you have job security.  While there is a certain level of truth to that, at least in the past, a lot of people are discovering now that having a piece of code that only one of your developers knows anything about is a huge risk for the business. If that person leaves, you have to spend a lot of time and effort figuring out what that code was doing. That’s less likely to be the case when more than one person has looked at that same piece of code.

Sarah: I look at pair programming as a way to reduce the risk of un-reviewed code and as a way to disseminate knowledge across teams and to intercross people in a way that is extremely effective. Having someone sit and pair with you is an amazing way to learn a new skill.

Sarah: Back in 2010, I had not done any front end at that time. I had done some table layouts and some HTML. My Javascript skills involved changing the code and seeing if it worked. That’s where I was. So, my front end development skills were very rudimentary at that time. I tried to look at CSS a couple of times back then, but I just didn’t get it. So, I started working at Pivotal and the first week I was there, I paired on some front end, CSS, and HTML stuff with someone who really knew what they were doing. By the end of the first two weeks that I was there, I went in and completely redesigned my entire personal home page. I redid all of it in CSS. I had tried to learn CSS for years, but I just couldn’t quite get it on my own. But, after two weeks of pairing I felt almost like an expert. Of course, there’s always a lot more to learn, though. It was an amazing way to learn stuff very quickly. That’s what I really liked about Pivotal. Being there meant that I was basically able to learn all the super powers of all the people around me. I absorbed all the things that they could do and they absorbed all the things that I could do. It leads to an extremely high functioning team.

Sarah: I would add that pair programming is a skill. It’s not something that you can just suddenly do and be good at it. There are a lot of ways to do it that will make it less effective than it should be. It’s difficult to imagine what it’s like to do it well without actually having a pair that knows what they’re doing and is skilled at specifically ‘pairing’ and who can ensure that both people benefit as much as possible from the experience.

Arsalan: There are a couple of questions that come to my mind for someone who’s trying to implement pair programming in their organization. They might have these questions as well. Do you pair two equally experienced people or should it be one senior and one junior? It seems to me that the senior-junior relationship would be very beneficial. Let’s say you have one person who’s really good at the front end stuff and someone else who’s really good at the back end stuff. If you pair the two together, hopefully you will learn from each other and gain a different perspective. Or, could it be that it doesn’t matter and you can just pair anyone?

Sarah: You do have to be thoughtful about it. I think that the benefits of a senior-junior pairing are more obvious than pairing people of equal experience. I often tell new developers to find a place where they will be pairing with more senior people. With that said, once you have a team that’s pair programming, it’s important to vary the relative skill levels of the people involved. Generally speaking, I switched pairs each day. So, I would work with one person one day and someone else the next. Depending on the size of the team, that means that I worked with three to five people in a week.

Sarah: That means that when I am paired with someone more junior than I am, instead of engaging the pairing skills, it also engages the teaching skills. I then have to think about how much I ‘drive’ or how much I am typing versus how much the other person is typing because often the best way for junior developers to learn how to do something is by doing it themselves. There’s a fine line between getting the work done and ensuring the person you’re pairing is learning.

Sarah: When I am paired with someone at my own experience level, it’s a completely different feeling of pairing. Many times we can go extremely fast, much faster than I would go on my own. I think that is the ideal case on a product team – to get everyone to that point, where a pair can produce more in one day than two individuals working separately on different things. That is fun because you can tell you’re going really fast and producing high quality code at the same time and finishing a lot of stuff. That is the promise of pair programming and it is what many people love about it.

Sarah: The teaching is very important, but you also need to make sure that your senior developers are not always teaching and that your junior developers are not always in the ‘learning’ role. If you have a situation where someone is always the ‘teacher’ and someone else is always the ‘learner’ that can lead to some very negative dynamics. It’s important for everyone to get a chance to pair with different experience levels and have the chance to be ‘teacher’ one time and ‘learner’ another by mixing things up.

Arsalan: That makes sense. I think I would personally emphasize quality over quantity. At some point you will produce more code than two individual developers by themselves. I think that the real benefit that you really get out of this system is the higher quality and fewer bugs. You can totally avoid sloppy mistakes because it’s hard for two people to make obvious mistakes.

Sarah: Exactly. There are two aspects to that. If I try to suggest something and I say it out loud, once I say it aloud I can already tell it’s a bad idea. The difference between talking about something and thinking about something involves a different set of neuropathways when you vocalize an idea than when you are just thinking about an idea. That means that when you vocalize something that seems like a great idea in your head, you may suddenly say to yourself “No, let’s not do that. That’s a bad idea.”

Sarah: The other part of it is like you said. If I am paired with someone who has complementary, but not overlapping, skills and experience, and I suggest something. They might say that it’s not a good idea because they tried it before themselves and this happened. So, we have the union of our experience to draw on. One of the reasons it gives us this speed is because we tend to Google fewer things. The union of our knowledge is much greater than our knowledge individually.

Arsalan: Yes, and generally one of the pair is going to know a trick, maybe even for Googling. I have done a lot of Googling in my time and I have gotten really good at Googling for very specific things. If you get used to searching for one thing over and over, you eventually get very good at going through the search results. There are very few downsides to pair programming, I think, except that you need two people. If you can only afford one person, you’re probably not going to do pair programming.

Sarah: Yes, and it also requires a certain amount of faith on the part of your product organization or your product person if they’re not a developer. That’s because you’re telling them that while you could be working on two different things at once, you’re only going to work on one thing at a time. They then have to trust that is going to give them a better outcome than if they had two people working on different things separately. It can be a hard sell for that reason, especially to folks who aren’t programmers. But, it’s good to talk about it in terms of the quality aspect of it. Short-cuts that you might take if you’re tired and it’s at the end of the day, you might not take when someone else is watching you. So, I think it’s a good way to supplement my own self-discipline when it comes to doing the right thing, whatever that may be.

Arsalan: Yes, sometimes that’s what you have to do, but when you’re working as a pair, chances are you will write better quality code that will do as advertised. So, time flies and it’s so much fun talking to you, but I do have a few more questions before we let you go.

Arsalan: I want to talk about conferences because you organize conferences and I know that you deal with a lot of people who want to present at conferences. My personal opinion is that if you are a new developer you should not think that you are unqualified to present at a conference. You may be plenty qualified for a very specific topic and there may be plenty of people who could benefit from your niche topic. Perhaps they are a few months or a few years behind you on experience. Do you agree with this statement?

Sarah: Yes, absolutely.

Arsalan: So, let’s talk about conference proposals. You wrote about why some conference proposals got accepted, how to put them together, and what some of the things that people are doing wrong. We don’t have time to go over all the details, but if you could give us a quick summary of how a new person, who perhaps has a couple of years’ experience, could put together a conference proposal that has a better chance of success.

Sarah: First, I’ll say that often the best teacher for a concept, for someone who’s new, is a person who has learned it recently. Many times there were conference talks that I’ve been to that were intended for beginners, but they were taught by someone who was so far removed from being a beginner that the speaker was unable to put themselves back into that mindset. So, they explained things to people who were new couldn’t follow.

Sarah: This is not just a problem that is limited to tech. You see this problem everywhere. So, I think that new developers are often in a great position to explain concepts or anything that they found confusing the first time they looked at it because there are likely to be a bunch of people who found it to be confusing in exactly the same way. I couldn’t do that because I no longer remember what it’s like to be new because you get used to things after a while. So, having someone who can make that context explicit because they’re closer to that place is really valuable.

Sarah: I think a lot of people struggle with having a topic to talk about. I find that coming up with a topic that will be interesting is often the hardest part. So, I tell new developers that if they had come to the conference last year, what talk would you have wanted to see? So, they can kind of go through the thought process and kind of think about what topics they might have been confused about last year. So, if you would have wanted to see that talk last year, I can guarantee you that there will be someone who would want to see it this year. In fact, there are probably more people who want to see it this year than last year. So idea generation is one aspect of it.

Sarah: The second aspect of it is thinking about how you put together an abstract, which is like a little paragraph on what your talk is going to be about. That’s usually what goes in the program of a conference because people will be looking at the program to decide which talks to attend. So, you need to see the topic that you’ll be talking about in the abstract’s paragraph.

Sarah: In a conference proposal there are also usually just a few lines that don’t get put into the program, but are just there for you to talk to the conference proposal reviewers about your talk. This is where you can give them extra information about your talk that you don’t have space for in the abstract because the abstract is usually quite small.

Sarah: So, the biggest tip that I think people often miss is that you want your reader, or the person attending the conference, to be able to understand what they’ll be able to do when they walk out of your talk that they couldn’t do when they walked in. So, write the title and the abstract in the point of view of what the attendee will gain from listening to your talk.

Sarah: lot of the conference proposals that I review will be written in terms of the speaker. So, they may say things like “In this talk I will present three different ways to find objects in Active Record.” To be perfectly honest, the people who are at these conferences don’t care about you as a speaker. What they care about is them. So, a much more effective way to say something like that would be “In this talk you will learn three different ways to find objects in Active Record which will allow you to ……” So, what you really need to do is be really explicit and say here’s what you can expect to do, here’s why you should come and why you should want to learn about this.

Sarah: A lot of people miss that because you’ll see things like “In this talk we’ll learn about Swift” and you’re thinking “Okay, but why would I want to learn about Swift? What am I going to get out of it?” So, this works on the reviewers also because they need to know why people would want to attend that talk. The reviewers are really trying to put together a program that will make people want to buy tickets, show up, or be excited about the sponsors, or whatever. So, they’re not trying to build a program around a certain area of topics, but rather a program that people will read about and be excited about seeing. I think that’s the secret right there. You’re writing for two different audiences: the reviewers and the attendees, but the same point of view works with both and the point of view is “what will an attendee be able to do if they see your talk that they can’t do right now?”

Arsalan: So, I think one way of looking at it would be to imagine yourself in the shoes of the audience and see what pain they’re having right now. So you need people to care about the topic because if nobody cares, then it’s probably not a good topic and you should think about something else.

Sarah: Right and I think that people will be more or less interested in the topic depending on how you talk about it as well. So, for example, who cares about Active Record? Well, maybe they don’t care because they don’t really understand what it means. So, if you’re like “Hey, have you ever wanted to be able to a query of 8 million rows in less than a quarter of a second? If so, you should learn about Active Record and how it makes its sequel statements.

Arsalan: Perhaps all of us should learn copywriting skills before we write proposals.

Sarah: Well, it certainly helps to improve them. I think as developers writing is not something that we often focus on when we’re in school. It’s different now because we’re having a lot of people coming into the industry who have been doing other things before. So, a lot of them do have great writing skills, but it’s not something that our schooling tends to focus on. I think that doing conference talks is a good way to work on that in addition to blog posts and so on.

Arsalan: So there’s the conference proposal, but there’s another thing, which is to establish yourself as someone who can deliver. You have to have some kind of profile that people can look at you and decide whether or not they think you can handle a task. How do you recommend that someone goes about that?

Sarah: So, it’s kind of like a chicken and an egg problem. You need to prove that you can do a conference talk, but in order to do that, you need to do a conference talk.

Arsalan: Or something else. Anything that shows that you can deliver, that you have the knowledge and the skills. You can’t really show that you have the speaking skills until you speak, but at least you can show that you have the knowledge. It’s hard to do it when you’re starting out.

Sarah: I would say that the main thing that was helpful for me and others as well is that I would first write a blog post about the topic that I wanted to do the talk on. You might think that people would no longer be interested in the talk because they can just go read the blog post, but that is actually never the case. Some people will never read a blog, but they’ll watch the heck out of a conference video and other people will never watch conference videos, but they will read anything. Just because your information is in one medium doesn’t mean you can’t put it into another one. If you can write a pretty coherent blog post, that’s a pretty good signal that you at least have some English composition skills and you can write an essay that holds together and construct a narrative and keep it going throughout the body of a blog post. That’s a good way to show that you can construct a narrative for a conference talk and keep it going the entire time that I’m doing the talk. So, having a blog post of the same topic is often very helpful.

Sarah: I also think it’s very helpful to have a video clip, even if it’s just a few minutes that you put up on YouTube or something, of you talking about something technical. It could even be the proposal topic. What that will do is let the reviewers know that you can put together an English sentence and say it aloud. So, having a video that covers three or four minutes on a topic and why you’re excited about it, even if it’s not scripted, the reviewers will see that as a benefit and it validates your ability to coherently put together and speak about your topic. Having the video and blog post on the same topic vastly reduces the risk that the reviewers will see when considering your proposal.

Arsalan: Absolutely. What do you think about sending the same proposal to several different conferences? For example, submitting a proposal to a conference that has a lesser bar and practicing there a couple of times before moving on to a larger conference. Or, is that frowned upon?

Sarah: I think that varies, but big conferences tend to have a different attendee base than smaller conferences. Part of the work that I do is that I am on the board of the nonprofit that runs RubyConf and RailsConf, which are the 2 largest Ruby conferences in the world. So, the people who go to those are much different than the ones who go to the more regional Ruby conferences like Burlington Ruby, which is located in Vermont and draws an average of around 100 people. A lot of the people who attend the larger conferences usually have a conference budget for work and they can go to one of these conferences per year and they usually pick one of these larger conferences like RubyConf, ClojureConf , or JSConf. So, they are very unlikely to have seen your talk before. If you have a video of you doing it’s, even if it’s just for a meet up from your hometown that can also be a great way to reduce the perceived risk on the part of the conference organizer in choosing your talk. I think it’s pretty expected that you would at least submit your talk proposal to a bunch of different conferences.

Sarah: It does pay to be persistent. When I was 1^st starting out, I would put in around 10 different conference proposals and would get back maybe one acceptance. It’s almost like a numbers game. You’ve got to find a conference that will take a chance on you then you can build up this corpus and show that you can do this. Some of the best talks that we’ve had at both RubyConf and RailsConf have been new speakers. We took a chance on them because the content seemed really compelling, and the speakers seem to really know what they were doing.

Arsalan: Were they more junior level people or were they more seasoned?

Sarah: Most of our new speakers are more junior level people, but we do get some new speakers who are more senior level. Most of our new speakers are also new developers and we’ve gotten great feedback on a lot of those talks.

Arsalan: So, this is the advice from Sarah Mei. Go speak at conferences. Do pair programming. Put yourself out there and write blog posts. Don’t worry about getting people who are being critical, because they will be. Sometimes people may say hurtful things. That’s okay. They may point out that you’re making a grievous mistake, which you will and that’s okay. Through this experience, you will learn how to express yourself, promote yourself and building a brand for yourself, and build a brand for yourself. What do you think about that, Sarah?

Sarah: the way I think about conferences for me is I always thought about it as job security. Once I left Microsoft and was working at smaller companies, in theory, my job security went down because I was working at smaller companies and they may go out of business at any time or they may lose some funding or lay people off. So, once I had kids, I needed to make sure that I had a stable income. I didn’t want to go back to a large company.

Sarah: So, the way that I manufactured job security was by doing conference talks and blog posts and so on. I think that having a strong support network is important. Being able to log off and interact with your family and friends is also important. My goal was to be able to get a job quickly using the network of people that I have built up, and that has certainly happened for me. Having that security allows me to take more risks in my work life. If I needed freelance work to tide me over, I could get that tomorrow and that has been very powerful to me.

Arsalan: There is job security. In that sense and you will be to pick a path for yourself. In our field, there is no tenure like there is in other fields. But, you have the ability to work for any company for as long as you want to or move around if you want. You could work from home. You could do a contract. I don’t think in the history of humanity, there has ever been a career that has been so flexible, so fulfilling, so rewarding in terms of fulfilling your need for creativity while giving you lots of money.

Sarah: I think that there have been versions of that over the years. A lot of times when I think about what I do, it’s almost the modern equivalent of being a machinist because of their ability to find a job regardless of where they are living. Programming to me feels like the digital equivalent to machining because you are building machines to build other machines. It is a very in demand, flexible and well-paying job. You can definitely raise a family on it for sure.

Arsalan: It was such a pleasure having you here, Sarah, and talking to again. It’s so hard to stop. We are already well over our time, but it looks like we just have so much to talk about. Hopefully, we will have you back on again soon to talk about some of the other things that I had wanted to talk to you about.

Sarah: It was my pleasure.

Arsalan: Before we go, is there anything that you want to say to new developers to inspire them for 2016?

Sarah: I’m not sure if this is what you had in mind, but the important thing when you are working on a problem and you can’t seem to work it out is to think about what you can build with that. Once you work through the problem. It can be really difficult to keep your eye on the ball. It was for me. As an industry, we are learning so much from all these people who are coming in from different directions. So, I’m really excited to see what we’re going to build in the next 10 years.

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

Sarah: Probably the most effective way to get in touch with me is on Twitter. My email tends to be something that’s difficult to keep up with, but I do manage to keep up with my Twitter: @sarahmei.

Arsalan: It was a pleasure talking to you once again and we’ll see you later.

 

Important Links

• Microsoft
• RailsBridge
• RubyConf
• RailsConf
• BurlingtonRuby
• ClojureConf
• JSConf

Thanks for Listening!

Do you have some feedback or some advice for us or our audience? Please give us a review on iTunes, Spotify, Google Podcasts, 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 also listen directly and give your feedback on the website.

You can subscribe to Mentoring Developers via iTunes, Stitcher Radio, Spotify, or Google Podcasts.