Sales Engineering

At VerticalResponse, being a sales engineer means I’ll be the main technical contact for our sales team, focusing on our API and partner accounts. (A couple of definitions: an API is the way that two programs talk to each other, and a partner account at VR is one that is capable of having sub-accounts and non-VerticalResponse branding. And lots of other features that I’m learning a lot more about.) I’ll be present throughout the process: working with sales folks and their leads to figure out how we could work together, helping their developers implement whatever they’re doing, and troubleshooting what’s wrong when things break in the future.

I’m also supporting what we (somewhat confusingly) call our Enterprise API, which is simply a regular single user account that can access the API to get things done. This helps people automate things like getting their lists of email addresses from their databases into VerticalResponse and lots of other really fun things. So I’m going to be helping those people troubleshoot and learn about what they can do, too. 

As I get better and faster at troubleshooting a wide variety of codebases (PHP, C#, and other varieties of .NET-using languages, Perl, Python, and maybe once in a while, Ruby), I’ll also be working on improving our documentation and figuring out what ways our API could be better utilized by our current customers. And eventually, my predecessor (Rob) and I hope to expand my position to include more evangelism — working to raise the profile of VerticalResponse among developers.

I’m still working as a support rep part time until they identify my replacement, but I get to be an SE on Mondays and Fridays, which is awesome. AWESOME! Also great: Rob is moving into a higher-level position at VR and is super psyched to transfer as much knowledge from his head into mine as is possible given the limitations on direct brain:brain knowledge transfer. (AND he’s a great human being.)

What do you do with a BA in Art History? Get promoted to Sales Engineer!

Oberlin’s got a new director of career services, and boy howdy is he awesome. I got to meet him a few months ago when he was visiting SF to learn about the winter term internship program that I helped put together. One thing he’ll be focusing on is connecting current students with alumni for the benefit of all. Novel! I am certain some of the pain I’ve felt these past few years would have been lessened by his presence while I was at Oberlin, but I’m happy for future youngsters to benefit.

But enough regret!

I have successfully been promoted out of an entry level position! After 8.5 months as a customer support rep, on Monday I accepted a position as a Sales Engineer. I’ll be working with our sales team to add a technical perspective to potential deals and also support our current API customers. It’s going to be awesome.

So, success! You, too, can have success.

Going to my first RailsBridge was how I got my job, and I’ve met a ton of awesome people through it. It wasn’t networking, per se, but now I am more networked. You should find and get involved in an organization related to the career you pine for.

If you’re looking to break into tech but don’t know how to code, I’d totally recommend applying for support jobs. You learn a ton about your product and customers and get to practice the great art of patience.

The nice thing about doing support for a Software as as Service (SaaS) company is that it’s optional: I imagine supporting a service that everyone has, like Internet or cable, significantly lowers the bar on the base technical knowledge of the customers. Our customers definitely have varied experience levels, but all of them know at least that they need email marketing and how to get to our website.

Here are a few things I’d recommend considering as you’re applying for jobs:

• What kinds of support are you doing? A company that only does email/ticketed support has different requirements than my company, which provides email, chat, and phone support.
• What’s the customer base like? Supporting engineers is very different than supporting small business owners which is different than supporting cats.
• Does the company have a history of promoting support reps? Do they have any initiatives in place to expose reps to other aspects of the organization?
• Is there good training? I had a solid two weeks of training, and was only a little scared when I took my first call. I knew where to find the answers for things that I didn’t know yet, and that my coworkers would help me along.

One challenge I found was that live support requires very intentional scheduling. It’s a little strange to go back to having a strict schedule (“on-stage” time == sacred) coming from admin positions where my schedule was prescribed but flexible. You deal. A big upside of the gig was that for the first time, I had stats! Actual numbers to back up my performance, that I could point to and say: I AM SUCCEEDING.

If you analytical, like learning, solving problems, and human beings (and making them feel better when they are confused or saddened) support might be a good job for you.

Oh, also, would you like my job? Email me any questions, and apply here: http://jobvite.com/m?3luLkfwE. I don’t get to start being a sales engineer in earnest until my position is filled, so apply early and often.

The Vice Grip of How We Learned It First

I like to think of myself as pretty computer savvy. And then I watch other people wield their keyboards like swords, and realize how much faster and efficient I could be. I started using Macs regularly in 2003, when I found myself at a half-PC/half-Mac college. The first computer I got after college was a white MacBook.

(Which is still running. Which I am currently typing on. Its hard drive died and had to be replaced last week, but otherwise this clunker is still rocking! Also, thank god (thank Jobs?) for Time Machine.)

For about seven years, my process of launching an application was:

1. Clicking on the Finder icon to open up a Finder window
2. Clicking on Applications from the left column
3. Scrolling through the list of applications until I found what I wanted to open
4. Double clicking on the application icon to launch it

Sure, four steps isn’t the worst. But in retrospect, it was damn slow. The only exception was the way I launched a single application. In 2009, my housemate Colin showed me Caffeine, a little program that keeps your computer awake with one click (especially handy while watching shows and movies). When Colin opened up Caffeine, he hit Command + Space, started typing in the name of the application, hit enter, and it launched! Amazing! 

Rather than realizing that this quick, non-clicking, non-eyeballing-the-applications-list way to open a program existed, I just filed this away as the way to open Caffeine. So for about two years, I continued to open every other application the old (and slow and inefficient) way. 

When I started learning Ruby on Rails, I found myself sitting next to power users and watching how they manipulated their computers, and at some point realized that I could open all applications the way I open Caffeine.

More than one workshops/classes/tutorial has also explicitly recommended using Ctrl+Tab to switch between windows. I still tend to use Finder to look around for documents, at least in part because I don’t remember file names, but, you know, habit. I’m pretty bad about using tab completion in the command line, but every time I’m in there and Travis is watching, he tries to get me to do it. Baby steps. 

I’m excited to someday get into a position where I can get my hands dirty doing design research. I’ve loved the times that I’ve been a research subject, and although it’ll be hard for me not to share my tricks, I’ll bite my tongue and save them for a Railsbridge.  

Railsbridge Changed My Life

The title might be hyperbolic sounding, but going to my first Railsbridge Workshop for Women in September 2011 made a pretty major impact on where I am right now. 

Travis ran into an old college friend on CalTrain, and they got to talking about code and my efforts to learn Ruby. This friend happened to be a lady who had attended a Railsbridge workshop, and she recommended that I attend one. I was super psyched about it, but found myself on the waitlist. Luckily there were enough cancellations that I was able to make it off the waitlist and BAM! workshop.

The workshop was broken into two main sessions: a Friday night Installfest where you get your machine up and running with the approximately 13 things you need for a complete development environment, and the Saturday learning day, where you create a little voting app (topics can be submitted and then voted on) from start to finish. 

At the time, the Installfest instructions were kept on a wiki, and for some reason, a person had ripped out the current instructions and replaced them with similar, but not really functional, instructions. This was discovered about an hour and a half into the installfest; luckily, someone found a version of the good instructions and order was restored. But the troubleshooting required was really intense and there were lots of kind people typing things I didn’t know into my computer, discussing whether RVM was really necessary, and in the end the I went home, installed, around 11:30pm — about five hours, start to finish. I was tired and a bit confused about what had just happened, but also really impressed by how everyone had stayed positive and focused despite the setbacks. It reminded me a bit of late evenings of putting together a musical in high school. Everyone gets tired, but you’re working on something you love, so the fatigue just makes things kind of funnier, not frustrating. 

The Saturday session was an order of magnitude clearer than the Installfest. There was an opening presentation by one of the organizers going over some RoR basics and the day’s schedule, a quick pitch by the sponsors that they are always hiring developers, and then we got to learning. My class had five students, one teacher, and two TAs. The teacher led the way through the curriculum, while the TAs helped troubleshoot when someone ran into an error and added occassional general clarification. 

We played some silly name-games that involved hearing everyone’s name at least 20 times, which was awesome. We also introduced ourselves more generally, and I mentioned that I was trying to get a job in tech. During one of the breaks, a woman in my group, Natalie, mentioned that her company was hiring support reps, and even though it’s definitely entry-level, that I might apply because they like to promote people from support. 

That lovely lady is now my manager at VerticalResponse, and we’ve both attended more Railsbridge events, and we’re going to host a workshop at work sometime this year! (The only delay is that we only moved into this building in August, and the open space doesn’t have any outlets. Which doesn’t really work for the Installfest, which even with much-improved instructions can go on for four or five hours, depending on what time people show up.) 

It’s hard to explain how wonderful the Railsbridge community is. The Ruby community tends to be really welcoming in and of itself, and then Railsbridge takes that and puts an anti-sexist and pro-diversity spin on it. Its people are incredibly non-judgemental and encouraging. The two women who started it all are still very involved, but they no longer have to organize and teach at every workshop — a group of core volunteers helps support each pair of organizers and makes sure the curriculum and install instructions stay up to date, and a big group of people comes out to teach or TA when they can. Since that first workshop I’ve attended another as a student, volunteered as babysitter and generally helpful person at another, and just organized the March workshop. So now I just need to TA a workshop, then teach, and then I’ll have done it all!

I ♥ Product

Last week was a busy one for free product events. On Thursday evening, I attended a talk by Marty Cagan at BranchOut (co-sponsored by ModCloth, a company that makes me wish I were more adventurous with my clothing). On Saturday, some work pals and I (actually, my team lead & manager (we were some sort of Support triumverate)) travelled down to San Jose for Product Camp, a one-day unconference all about product management. 

STRANGERS: NOT SO BAD!

Going to the Cagan event alone was excellent, because there were about 45 minutes at the beginning of the 2 hour event in which nothing was happening. I grabbed some cookies and some wine, and started talking to another person who was standing around awkwardly. (My opening line: “How did you get here?” It’s a good test for how literal a person is.) I brought up Railsbridge, and this topic attracted the attention of several other people because RAILS! We talked a little bit about what we all do professionally, but more about Rails and how the RoR community in SF is totally awesome and everyone should love Railsbridge.

PRESENTING QUOTES

Cagan structured his presentation around quotes from astronomically successful product people: Jobs, Bezos, Zuckerberg, etc. It was a great conceit; he backed up what he thought was most important about product management with pithy things said by famous people. I was convinced. 

ENGINEERS: THE BEST, OR THE VERY BEST?

One of the things that interests me in thinking about product management is when engineers are involved and when they aren’t. Engineers are expensive. Their specialized knowledge and ability to product awesome code makes me think that a lot of organizations are reticent to plunge them too often into the research side of development. And while Cagan put forth his opinion that UX is harder to get right than code, he also emphasized that engineers are excellent problem solvers, and should always always always be on the product discovery team with a product person and a UX designer. He seemed to be fighting the idea that having a developer in the conversation at the discovery stage would be somehow limiting, that it would somehow get too practical, too fast. Rather, he argued that devs are actually awesome at coming up with creative solutions. Instead of thinking that something would be impossible and dismiss it out of hand (as non-technical folks often do) a developer can consider the technologies and what she can do with them. So secret product weapon: developers!!!

A FEW THINGS MARTY CAGAN CARES ABOUT

Testing. Running regular A/B tests will show you that most of your awesome ideas don’t really make any revenue impact. So you throw ’em away. Your tests can either be qualitative or quantitative: usually qualitative if all you’ve got is enough of a veneer to try it out with some real people, quantitative if you’ve got a live production prototype — code that isn’t production-value, but can be released to a segment of your users. A lot decisions can be made by just testing something rather than debating it endlessly. This may or may not have been an actual quote, but it’s in my notes: “The job isn’t to be right the first time, it’s to get to right really fast.”

UX is really, really important. And UX isn’t just usability — it’s that, and the visual design (which creates the emotional impact) and everything that the user experiences (sorry) with the product. The word Gestalt was used.

JUST DO IT?

To illustrate the important of testing and data, Cagan told an anecdote about the implementation for Amazon’s in-cart suggestion feature. His delivery was excellent; I found the story as told by the person who actually made the feature, and it’s a good one (albeit a bit drier than Cagan’s rendition).

One of the things that I love about product from what I’ve learned so far is that a focus on revenue is critical to success. You can’t (well, shouldn’t) just add a feature because it’s cool. It needs to add value to the customer’s experience and you need to be able to prove it. Not that I’m solely interested in maximum profit (I should go into derivatives-something if I change my mind, right?), but rather the fact that you should be able to do right by the customer while earning your rent. I like the idea of making neat stuff, but making stuff that other people will actually pay for seems like an awesome (and terrifying) challenge. 

Introducing lilliechilen.com: fewer cats, one goat

BACKSTORY

In the glorious days of 2008, I decided it was time to buy lilliechilen.com and make myself a website. I didn’t know too much about anything (still don’t), but I knew I needed to use CSS. And that I needed to get the files for the site to my hosting service. I stumbled through well enough: I signed up with NearlyFreeSpeech.net, modified the CSS from my friend Solon’s super-minimalist website, and decided not to put any real content up, instead featuring my favorite miniature Australian shepherd, Harper.

A few months later, the site went through its first major growth spurt. I had adopted a couple of beautiful cats and they were perfect for continuing the joke that was lilliechilen.com. The site stayed that way for almost two years exactly. And on Sunday, March 4, 2012, the new, improved, and ultraprofessionalish lilliechilen.com was born.

THINGS LEARNED

Travis told me about Subtle Patterns and Twitter Bootstrap: the lazy lady’s ticket to an awesome looking site. I’m definitely not using Bootstrap’s grid system to its full potential, but the joy of seeing something I made actually (a)live on the internet is addictive, and I’ve got plans for expansion and improvement.

I reacquainted myself with my hosting service and FTP clients for Mac (went with Cyberduck for its lack of upfront cost). One happy surprise was finding the original creation dates for the first two iterations of lilliechilen.com upon connecting to my host — my archive page is much better for being able to reference the dates of transformation.

MAKING GOOD CHOICES

I wanted the make all the links a greenish teal color but Travis convinced me that I should respect people’s expectations of link color (and I realized this was especially true since links aren’t underlined by default in Bootstrap’s CSS). Well, Travis told me it was a bad idea, then I did it anyway, and then I decided he was right. I want more accent colors, but not until I figure out how to do so in a UX-friendly/aesthetically satisfying way. 

Things were, of course, broken in IE (I was developing in Chrome on a Mac) and when Travis reported this to me (from his PC) I responded by lazily adding a note in the footer that just said “Don’t use IE”. Having standards, Travis did a bit of research and made my site compatible with IE in just three lines with a script called HTML5 Shiv that forces IE to recognize HTML5 and thus render my site in all its glory. 

WRITING IS HARD 

I probably spent a good hour of the afternoon trying to write an all-purpose medium-length biography of myself. Something in between a professional bio and My Life Story. I was trying to image the different people that might end up at my website, and how I’d want to explain myself. In the end, it’s mostly about job stuff. Thankfully, according to Google Analytics, my bio page is the least popular section with a scant 5% of my traffic.

Blazing Cloud’s Ruby for Beginners

February 16th was the sixth and final installment in the Ruby class I took at Blazing Cloud, Sarah Allen’s dev shop & palace of learning. Brian Jenkins was the teacher, and his excitement for the subject matter — specifically breaking down very abstract concepts into something more concrete — made for an awesome class. 

I’ve been a student at a few Railsbridge workshops, so I already had something of an introduction to Ruby from that. But Brian broke it down much further in the first class, starting with hardware. It was awesome; I had always thought of the CPU as some kind of magic box that did stuff and storage as … another kind of magic box. Because I’m silly, here is a snippet of my notes:

WHAT IS A COMPUTER
Physically:
State (noun) v Behavior (verb)

CPU (cook eggs. heat sink = important)
—>engine. does stuff.

Memory

Storage o_O
—>Disks & Platters
—>coil! magnet! hematite!

Part of making programming concepts tangible was making them tactile. Literally. Brian taught us what an array does through arts & crafts. First, we made some objects by writing things on scraps of paper. Then we taped those objects to rulers: the end was array[0], one inch was array[1], etc. And since just one array is kind of boring, we wanted another, and made it reference an object in the first array … so it did! It got a little complicated to hold, but made for an excellent visual to grasp the concepts.

The class lost a few members after the first couple weeks (some moved up to the Ruby for Programmers class, some probably moved to Portland), but those who stayed developed a great rapport. During our mid-class ten minute break, we ate snacks and chatted. We talked about Burning Man, boring meetings we’d attended, bad & good start up ideas, and how we got there. (Mostly figuratively, although parking strategies did come up once.)

Chris Pine’s Learn to Program was the class text, although we didn’t use it in class at all. Brian’s lectures were aligned with the content we were working on in the book, but there was enough to get through in the 2 hours of class each week that we didn’t spend any time going over the homework. (In addition to the lack of time, quite a few students couldn’t do the homework as the syllabus outlined. I was one week behind for the entire class, but with the carrot of not watching The Wire until I finished the book, I was only 11 days late with the final set of problems.)

The problems at the end of each chapter started off easy as pie and got predictably more difficult. Since Travis (my partner-in-crime (I mean boyfriend)) codes and has been learning Ruby along with me over the past year, he was an invaluable resource in nudging/hinting me through some of the harder problems. (Converting numbers to roman numerals was memorably difficult.) This week I committed all of my exercises to GitHub for easy access and future embarrassment. 

Now what? I’m going to build something awesome. And organize the March Railsbridge at Pivotal Labs! (Date and lots of enthusiastic cheerleading for Railsbridge forthcoming.) And tell all my lady friends who might not think programming is fun or possible for them that it is, in fact, both, and there are a lot of organizations & companies who want to them (us!) to succeed.

ruby on rails: learning things so far

Instead of learning codes, I’ll just blog about learning codes. Pretty effective for not learning codes. Here are the resources I’ve used so far in learning Ruby on Rails, some more directly related to coding than others:

• My Johson O’Connor results: In which I found out that my love of logic and aptitude for pattern-recognition might make me a decent programmer, or at least capable of learning about it. This is a fun short read on the actual testing—it hasn’t changed dramatically since 1995 from what I can tell. I was decent at putting together squiggly blocks, and pretty awesome at putting pins in a board. Status: helpful.
• RailsBridge Open Workshops: This summer, Travis ran into a college acquaintance on CalTrain who mentioned an upcoming workshop for women to learn RoR. So I signed up, and discovered the absolute joy that is RailsBridge and the SF Rails community. These folks are encouraging, approachable, and smart. We were divided into groups based on experience level and went through a curriculum to build a Reddit-style upboat/downboat machine. I’ve now been to two of their monthly workshops, and plan on going back as a volunteer in January. Status: <3
• Beginning Ruby from Novice to Professional: Given to me by the delightful Jonah Bloch-Johnson. It’s mostly a textbook with some do-along-with-me examples, but no go-do-it problems/challenges. I’ve lost track of it a few times, but have generally found the in-depth explanations to be helpful. Status: still working on it.
• How To Learn Ruby the Hard Way: A translation of Zed Shaw’s Python text. Interesting but aggressive approach that I abandoned after talking to a few of my Ruby developer friends and hearing their assertions that some of what I was learning was far from idiomatic. It was good just to type in the assignments to get used to looking through code for typos, but some of it (complicated topic? just google it!) seemed like harder way than necessary. Status: abandoned.
• Ruby Koans: Wonderful, super fun way of going through Ruby and finding out how much you don’t know. easier when you know more. good to pair with an explanatory text. Status: hiatus with inevitable return
• The SF Ruby Meetup Group: I mostly just look at the things that are happening and watch the listserv go by. Happy to be watching and absorbing information. Status: fly on the wall.
• My friends: Posting on Facebook that I was thinking of learning to code produced many helpful suggestions. Travis Grathwell has been about five steps ahead of me as I’ve been learning, and has pushed me along, answered questions, and listened to me sigh endlessly as I concentrate. Status: awesome.

Dispelling Untruths

In July, I paid a bunch of money to be told what I’m good at and what I’m bad at. Turns out I have great rhythm and melodic memory, but my fine pitch distinction is low-to-average. I also have excellent finger dexterity? News to me. I’m good at strategy and coming up with a lot of different ways to solve a given problem. I knew that on some level before, but it’s fun to have a piece of paper that says it. I’m also better at mentally manipulating 3D objects than I would have guessed. 

The best part of all this, though, was the computer’s assertion that—based on my aptitudes—I would be most satisfied and challenged as a doctor or a scientist. The human walking me through my results told me to take this with a grain of salt, because the computer doesn’t take into account *how* good you are at something, just whether you’re in the range of “real good”. I was right at the cusp of real good in terms of visualizing 3D objects and at the tip-top when it came to strategic thinking. But since the computer doesn’t take that difference into account, it told me I should get a job where I’m using my visualization and strategy skills equally. 

Doctoring? Sciencing? I’ve been a self-identified Humanities person as long as I can remember. I started talking and reading damn early, and when my folks tried to get me skipped ahead a grade (first or second, maybe?) it was all-systems-go, except my math scores. I just wasn’t that good at math, so the school recommended against it and I stayed. 

I’m not sure when I first heard this story, but I do know that language has never been hard, and math has always required a bit more effort. I realize now that a few tests that I took when I was 6 or 7 shouldn’t have scared me away from pursuing math and science. I should also recognize that I was getting all of our culture’s delightful messages that as a female person, I should be better at the soft stuff, anyway. 

I love the internet and I love understanding how things work. Learning to code would be a natural next step, but in my mind, programming == engineering == math == no way. But a set of graphs saying that I can do logic, that I’m not amazing at arithmetic but I’m great at seeing patterns in numbers, has done wonders for my confidence. 

So I’m learning to code.

******************************************

NB: I would actually recommend this testing if you’re feeling lost in your career, and you’re not sure what would make you happier at work. The Johnson O’Connor Research Foundation’s whole MO is that everyone’s happier at work when they are using their natural abilities and not fighting their weaknesses or doing things that are too easy. 

Shame, Shmame: Not Doing What You Were Trained To Do (And Still Loving The Place That Trained You.)

I am helping plan the first ever all-Conservatory reunion at Oberlin. Next June, a few weeks after the regular reunion & commencement weekend, Con alumi will overtake campus and use every rehearsal and performance space they can get their hands on. There will be concerts, talks, a pick-up orchestra, sight-reading, and lots of parties and picnics. It seems like a major impetus for the reunion is acknowledging that the Con experience has some fundamental differences from the College experience, and maybe we should celebrate Con alumni separately (and include everyone who studied music at Oberlin … not just people who got a Con degree). Historically, fewer Con alumni have donated money to Oberlin or attended reunions compared to College alums, and David Stull is pushing hard to change that and make our alumni community stronger.

One of the challenges of the event that I’ve been thinking about a lot is convincing Con alumni, regardless of their current pursuits, that they should come back. 

PERSONAL, ANECDOTAL ASIDE

I found that in private lessons, my specific plans for the future were better left unsaid. There wasn’t a good reason to acknowledge to my teacher that the lifestyle professional singing demands (at least what I learned about it from visiting artists) appalled me. Dropping the Con never seemed like an option, though. I loved the musical work I did and I also thought I would go into arts administration and that a BM in performance would still be a professional asset.

But now I’m getting into tech, and even though my musical education probably developed my professional skill set in ways I don’t appreciate, I feel like a failed Connie. Singing is now a hobby that I love, but it now directly competes with reading comics, climbing rock walls, and going to bars. Admitting that sometimes I put reading comic books ahead of music makes me a little sad.

BACK TO THE TOPIC AT HAND

So I know why I wouldn’t want to come back to Oberlin. I don’t look forward to explaining repeatedly that I didn’t want to even try to go for a career in singing but that I’m also happy singing unprofessionally. But that dread is far outweighed by my desire to hear about what everyone else has been up to, and also from other people who figured out how to make music a side-act in their lives and still be happy with it.

The big guns at Oberlin know that this not-being-a-musician-thing will be a sticking point for a lot of alumni. They’re putting a lot of thought into framing the event as a celebration for all Con alumni, regardless of current profession. It will be a challenge, though: for some folks, there will be a lot of disappointment and shame to cut through. It’s a challenge that’s smaller for a lot of College alumni, I think, since the College doesn’t emphasize specific career paths but general learning, whereas Con students have specific career ideas to live up to (and later realize are generally unrealistic and many more career paths exist than they considered). 

I’m glad, though, to be prompted to examine my feelings of failure. I hope two big things:

1. The reunion will help me (and other alumni) realize how many of us aren’t pursuing music the way we thought we might (and we are also not failures).
2. That more alumni realize that our time together at Oberlin made us better and more awesome people no matter what we do. 

…and a third: that the reunion is a blast.