Welcome to the fourth in a series of posts highlighting women developers. I’m trying to get a better understanding of the under-representation of women in STEM fields, so I’ve been reaching out to our community. What I’m finding is that women are out there, coding away, and I want to share their stories and advice.
Masha Thomas has always enjoyed breaking things, which makes programming a perfect career for her. She started developing on Force.com before Apex Code and Visualforce, when coding S-Controls was all the rage (Michael Farrington, you know what she’s talking about). Today, she is quietly coding away at 2U in New York City and doesn’t see herself as a “woman developer”. I am honored that she is letting me share her story.
When did you learn to code? What do you love about it?
I went to college in Seattle so I was surrounded by tech. I was interested in coding all through college, and I got my first job around the dotcom bubble (~2003). I enjoy breaking things, to see how they work, and then putting them back together. That’s why I got into development. I like to see the way stuff works. And, it’s a profession that inspires me to always be learning. You can be a developer for a very long time: it never gets old, you’re always learning new stuff. If I’m at a job where I stop learning then I know it’s time to go somewhere else.
Have you always been interested in breaking things?
Yes, but I wasn’t a destructive child. I’ve always been interested in the way things work. And it’s always been natural for me that if I had something, I would try to take it apart. My dad is an engineer, so I’ve always been exposed to technology. I think it’s the puzzle-solving nature of it, having to keep trying something until it fits. That’s what makes it a good fit for me.
How long have you been developing with Force.com?
What other programming languages do you use?
I’ve used a variety of languages: Java, .NET, PHP at one point. The gamut. I do mainly backend web development, but lately been working on the front end, too. I like working across the stack. Currently, I work primarily with Python and CoffeeScript on the front end and my interaction with the Salesforce Platform is mostly through the REST API or sometimes the Metadata API. I’ve also done a lot of Apex development to call out to other systems from the Salesforce Platform.
As technology changes, people’s language of choice changes. New languages come about. That’s why being a developer is a fun job, you are always learning something new. It becomes more about having the concepts of software development, rather than knowing the ins and outs of a specific language.
How was the learning curve for Apex Code?
I think if you have a Java background, it is not a steep learning curve from an object-oriented concepts and syntax standpoint, but there are a lot of quirks with the Saleforce Platform itself that you need to learn: working within the governor limits, not relying on your own CPU and disk, and compiling your code in the cloud.
Also, Apex is a closed language, which is more challenging because you don’t have access to the libraries you would have available in Java. It has grown a lot over the years. In the beginning, I had to write a lot of my own code because of that – it’s made me a better developer. You do have the ability to do some powerful things without having to write a lot of code. For example, the database support is pretty sweet, it’s built into the Apex language. In other environments you have to keep the database connection open and build that in yourself.
What tips do you share with newbies when they are coming up to speed in Apex Code?
There’s a book that’s really helpful: Dan Appleman’s book, Advanced Programming for Apex, it is good for investigating the platform. Also, there’s a blog that I follow, Force201, that always has great posts, and I recommend the From Java to Apex post to newbies.
For me, the most important thing has been getting Force.com code to follow the same practices as code in any other application: version control, Continuous Integration, being able to deploy through Jenkins, or a service like that. Since it is not entirely in-house it becomes a black hole sometimes. Another challenge is to keep the stuff admins are doing and developers are doing in sync.
You’ve worked a lot with Force.com integrations. Do you have some best practices to share?
If you are going to make web service callouts when something happens to an object in the Salesforce Platform, you have to use a trigger, but you can’t make web service callouts from a trigger, so you have to use a trigger that calls an asynchronous (@future) class. So, go that route immediately. Also, keep in mind that you can only have 10 requests at once. Those are the types of things that took me a while to figure out. You can get something working, but then when you test with more data it breaks because you hit limits. One way to get around the 10-at-a-time is to bundle your requests in the future method, to pass everything using one web request, as long as the receiving end API can handle it.
Did you attend Dreamforce ’13? If so, what was your favorite thing?
I did. I went this year and once before in 2008. It’s grown incredibly. The DevZone was was huge – it was pretty overwhelming!
I got a lot out of the breakout sessions. I went to a lot of sessions on Continuous Integration, which is a topic I am always interested in. And a cool thing is that one of the guys who presented now works here (KC Shafer, presented Introduction to Release Engineering on the Salesforce Platform). Some I went to purely out of curiosity: for example, the HBase @ Salesforce session. I took pretty detailed notes, and took down the names of the presenters and followed them on Twitter or GitHub. I have gone back and read through my notes, it was really helpful.
The other thing I liked was seeing what other people are doing, comparing it to what we’re doing. The ideas that you get from that get your brain thinking.
I’ve met many admins who are interested in learning to code. What is your advice to them?
If you don’t have a programming background, the first thing is learning how to think like a developer. The languages always change, so the concepts are what’s most important.
How you do that depends on your learning style. If it were me I would want to try it myself first: get a Developer Edition org set up, try writing the trigger myself, and then show it to someone else when I get stuck. I would also recommend doing a search on the Developer Boards and seeing if someone is trying to do something similar, and maybe has code samples out there that you can tweak.
What is it like being a woman in this field?
At my current position we have a few women developers, which is more women developers than I’ve worked with in the past. I don’t feel a difference, though. For my whole career, I’ve always been the only female developer. Maybe I’m just used to it. In most positions, I’ve enjoyed the people I’ve worked with so it hasn’t particularly bothered me. I think it depends on the industry. It was more uncomfortable in some old-school places during my internships, but if you are in newer industries or tech companies, it’s a better feeling.
I don’t know how I feel about the term “woman developer.” One of my teammates said, “Well you are a woman and you are a developer. You have a different perspective on it I’m sure, just from that being a fact.” I guess that’s probably true, but I’ve never thought about it that way.
Do you have kids? Do they code? What is your advice to parents of young children who express an interest in technology?
I don’t have kids, but I know there’s a computer science high school in Manhattan. I always think it’s really interesting – kids having access to computer science that young. A guy from work invited my team to see the demos of things they had made, and I was really impressed. So, if your kid likes to break things, don’t get mad at them, there might be a very good reason for that.
This conversation with Masha really made me stop and think about WHY raising the visibility of women in tech matters to me and my team. Is it because we believe that a more diverse workforce makes better products? Or because we believe more women should be developers because it’s a great job? Or because we believe that the next great breakthrough might be locked away in the head of someone who doesn’t “look like a developer”? Yes, yes, and yes.
But there’s more. A complex set of unconscious biases puts barriers in the path for women and people of color when it comes to technology jobs. One small way we can remove those barriers is to recognize people who are already in these roles, and then encourage people who aren’t to check it out. Each person I’ve interviewed remembered that one person who exposed them to programming: whether at age 7 or 12 or in college. If we each look around in our circles, at work or school, and create that opportunity for someone, and not just for someone who “fits” the stereotype of a programmer, we can change the ratio.