Episode 24 : Sarah Mei (second interview)

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. 

Podcast: Play in new window | Download