lillielillie

Lillie Chilen is a silly person living at the foot of Bernal Hill in San Francisco. She thinks every view from Bernal is wonderful in its own way, but her favorite is westward toward Sutro Tower. Her technical degree was in classical singing, but now she's a web developer. You can tell her what you think on Twitter, where she goes by @lilliealbert.

[lillielillie]

thinking about becoming a programmer? find a community & get helping.

I recently recieved an inquiry about my move from liberal arts grad to software developer. Here is that story, related advice, and some stray opinions about programming.

My Special Snowflake Backstory

In college, I studied classical singing and art history. I learned to write, to collaborate, to think critically, and that I didn't want to be an opera singer or an academic. For a few years after graduation, I paid the rent with admin jobs that were variously boring and horrifying.

I ended up in a customer support position at a tech company, and leveraged the Ruby I'd been learning in my free time into a Sales Engineer position, helping people who used my company's API. After doing that for a while, I quit, did Dev Bootcamp, got a paid engineering internship at Omada Health, then got hired as a full-time software engineer when the internship ended.

So that's how I got to be a programmer. Here are some of the things that helped me get here:

One Billion Buckets of Privilege

The circumstances that made my career switch possible include being a cis, currently able-bodied, rich, white person. I had the money to get a skills assessment that challenged my assumptions that I couldn't program computers. My tech support gig left me with enough energy to learn Ruby after work. Hugely, I borrowed money from my now-husband to pay for Dev Bootcamp, and he covered my rent while I didn't have an income. I have a degree from a fancy college. The intersections of my privilege are numerous and I have benefitted from them immeasurably.

(First time thinking about privilege? Read this.)

So there are a lot of things that I didn't have to do at all that helped me get a job.

There are also a few things that I would recommend doing if you can, most of which do require the privilege of time and energy.

A few hopefully-actionable recommendations

Join a community

There are a lot of great communities for programmers. Look for the local user group for your language of choice, or for an organization that has a common technology and goal. For me, attending RailsBridge was a life-changing choice, and the RailsBridge community was integral in my career as a developer.

(This also means picking a language that you can find a community around. If your town has a more active Python user group than Ruby user group, or you have a few friends who know JavaScript, pick the one your friends are learning.)

Take on a project in that community, stat

After attending my first workshop, I volunteered to help overhaul the RailsBridge website, then organized a workshop, and later became a leader of the SF chapter of RailsBridge. Most of this work was totally unrelated to learning Ruby or Rails, but it allowed me to meet a lot of people currently working with Rails, and gave me opportunities to prove myself and my work ethic outside of the context of a job interview.

There are skills you have that can make the community you've joined stronger, better, more exciting, or more functional. You can learn to organize events, or write blog posts, or work on documentation for new people. Brainstorm with other people what would make your community more awesome, and do it.

Maybe go to a bootcamp??

I have a friend who got a paid Ruby internship without going to Bootcamp. So: you can totally get a programming job without doing a bootcamp! That being said, attending a good bootcamp does jumpstart your programming education. I already knew a lot of the things we covered at Dev Bootcamp, but having that nine weeks to ONLY THINK ABOUT PROGRAMMING was really useful.

But bootcamps aren't guaranteed jobs, and the actually-getting-hired thing is a real challenge, especially as bootcamps and their grads have proliferated. But since you've already joined a community and gotten involved, you've hopefully made connections and established how awesome you are with several people who can help you land the right position.

Don't give up (unless you for real hate debugging after getting pretty comfy with your language of choice)

Early on in learning to program, my now-husband would get frustrated with me because when I was having a hard time with a coding problem, I would get verrrrrry sleepy and close the computer for a nap. One might have thought that this would mean I would fail at becoming a programmer, but look at me now! If you get tired or frustrated or sad while you're learning to program, it does not mean that you are going to fail. This shit is tough.

But, programming is mostly figuring out what's broken. So if after you've been learning for a while, if you get no joy from fixing a busted program, this career might not be for you, and that's totally fine!!! (You have to learn to debug before you can properly know if you hate it, though, so don't give up too quickly.)

Some Other Recommendations

If you're beginning to learn Ruby, buy the second edition of Chris Pine's Learn to Program. Now read it and do every single one of the end-of-chapter exercises.

Join codenewbie.org for an online community of learners who are not jerks, especially if you are having trouble finding a local community.

Start teaching other people about programming as soon as possible. Teaching (even if you don't feel 100% ready for it) is an incredibly efficient way to establish what you do and don't know about a thing, and helping people feels super nice!

[lillielillie]

How to do Dev Bootcamp as a feminist

Here are some tips for feminists going into Dev Bootcamp (DBC). Some are likely also applicable to other programming bootcamps, and tech in general.

Be wary of investing too much in the culture

Tech has been documented as a hostile environment to people that are not cishet white men. DBC is not an exception, in the least.

There are lots of things about Dev Bootcamp that are exceptional. The level of honesty on the part of the staff, for one. The effort going into teaching people just enough to get them started as professional developers. The earnest desire to change the culture of tech by teaching students how to be better people.

As a student at DBC, you will probably be told that the students there are responsible for its culture, which is kind of fair — you far outnumber the staff, and your behavior signals what is acceptable to the students who arrive after you. But when you are working on a challenge and hear something utterly depressing, I am here to tell you: you are not responsible for Dev Bootcamp's culture. You can not undo the dudebro-i-ness of the other people at DBC. You cannot undo the world.

Don't open up too much

You'll be spending A LOT of time at Dev Bootcamp. You'll be pairing with every single one of your classmates, and working on group projects. You'll get to know these people.

You'll also be encouraged to be deeply emotionally honest. You're spending so much time together, and it will be tempting to give in and share a very real part of yourself with your classmates.

But you should be careful. Not all of these people love you and not all of them care about your feelings. Dev Bootcamp itself is a major risk, but the second risk of trusting a group of strangers is one that you should give careful consideration. You might be in an emotional place where it is totally cool and helpful. But honor yourself and what will serve you — not your classmates or the dynamic of your group, and certainly not Dev Bootcamp the business.

Find your people

There will be gems. There will be people who are lovely, respectful, and kind. Once you've identified those people, try not to worry about the others. In my experience, the staff are some of the most fascinating, thoughtful people at DBC. They tend to be a bit stretched, so hopefully you'll find students you connect with. They will be so helpful.

Accept that many people will suck, and move on

Like much of the world, you will be surrounded by people who have never considered what privileges they might have. At DBC, your classmates will be working their asses off to learn how to program. Not all will react gracefully to being told that what they have accomplished so far in life is not purely a function of the effort they have expended and their unique brilliance.

DBC will explicitly introduce them to privilege, and some of them will be jerks about it. As a person who already knows what privilege is and is trying to bring more good into the world, watching people grapple with, reject, and deride social justice might break your heart.

I'm not sure how to avoid that heartbreak, really. Try not to care, I guess. Try not to be so invested in these people that their failures affect your learning. Remember: you are there to learn to code.

You can't fix Dev Bootcamp, and you can't fix tech. You can exist in it, you can grow in it, and you can change it, little by little. But since you're only at DBC for 9 short weeks, I suggest accepting it in its broken state, and focusing on programming instead. The staff can try to teach people to be empathetic. Your time is better spent elsewhere.

[lillielillie]

Thank you, Melissa McEwan

I’ve been reading the blog Shakesville for a few years. Every once in a while, I think about emailing its founder and blogmistress, Melissa McEwan, to tell her how important it’s been for me as a person. But rather than privately expressing my gratitude, it’s time for some bellowing-from-the-rooftops style gratitude.

Dear Melissa,

Thank you. Thank you times a billion. Thank you for being a strong advocate for all kinds of marginalized people, and doing it on the Internet, a place with so much possibility for good and for evil.

I don’t think I’ll ever be able to fully appreciate the work you put into running a safe place on the Internet, but I’m going to try. Your work has helped me grow so much as a person, and has helped me see so many way in which this world can be so much better.

I somehow got to feminism in a slightly roundabout way. I went to Oberlin College, where I learned about intersectionality and social justice and a lot of other things. But I somehow made it past graduation without self-identifying as a feminist. (Past-me apparently didn’t have access to a dictionary.)

And then, one day day a friend sent me a link to a Daily Dose of Cute featuring an adorably splayed and upside-down Dudley. I started wandering about the site, read through the Feminism 101 and the Shaxicon, and it all just clicked. Thus began the active phase of my becoming a feminist, and several years later, I’m still learning so much from you and the Shakesville community.

Your pragmatism and hope and sarcasm and total refusal to accept the shitty status quo is just fucking inspiring. Thank you.

Thankyouthankyouthankyouthankyou. Thank you from the bottom of my heart.

<3,

Lillie

Don't know Shakesville yet? Feminism 101 is a great place to start, even if you're an expert-level feminist already.

[lillielillie]

Gaslighters can be just so nice about it

You know how humans always think they can spot the people out to get them? That thieves are always wearing face masks and carrying bags with dollar signs on them? I’m a little more wise than that. I survey the world with a healthy amount of cynicism.

So when I think about people who totally derail conversations social justice stuff, I mostly picture assholes on the internet. Or the real life version, which could even take a little planning, with different people taking different approaches:

(MRA stands for Men's Rights Advocate. They hate feminism.)

Scene One

Huddling outside a tech event, two men are planning their strategy.

MRA #1: “Okay, I’ll take the first punch with a straw man argument. She’ll use up a lot of her energy fighting my excellent point that if we help women get jobs specifically, we’ll have to work on increasing every minority, including evangelical Christians missing two or more fingers!”

MRA #2: “Great! Once she’s super pissed about that, I’ll start in with the tone argument. It’ll be easy to point out how hard it is for reasonable people to have a conversation with an angry person.”

MRA #1: “Perfect, and I’ll finish it up with some gaslighting — I’ll bring up something she said in the course of the argument and explain how she must have totally misunderstood the point I was making, and how she obviously doesn’t understand a big part of the issue at hand.”

End Scene

Buuuuuuuut, it turns out these huddles don’t actually happen. (I mean, they might on real MRA message boards, but I’m not usually conversing with actual MRAs. Hopefully.)

What happens instead, is something like this:

Scene Two

A group of new friends meet up for a beer after work

Lillie: It’s frustrating that people who are so logical (like engineers) can look at the lack of diversity in tech and think that it isn’t because of a structurally oppressive system — do they really think that people of color just don’t like to code?

Friend with great intentions: Well, it’s really hard to realize when you’ve worked really hard in your life, and someone tells you that you’ve gotten a lot of it for free. And the people telling you that you got it for free aren’t being very nice about it.

Lillie: But being part of a system that’s broken doesn’t make you an evil person — it just means you got there in part from your status as a [white-, cis-, straight-, male-, abled-] person. Right?

Friend with great intentions: But it’s still so hard, and people aren’t understanding enough of that fact. Teaching yourself is really hard.

Lillie: ...

End Scene

Turns out that sometimes thieves wear suits, and sometimes derailers are your friends.

I obviously don’t know exactly why people do these things. Perhaps it's just that growing is hard, confronting and realizing your own privilege is hard, and talking about how social justice folks could Do It Better is a fuckton easier than thinking about your own life. Derailing a tough conversation is much more natural for a lot of people than actually having it.

Julie Pagano had some great tweets on just this topic this morning:

Another thing some people don’t get is that you can say terrible awful things in a nice tone of voice and make the other person look crazy.

— Julie the Wizandrist (@juliepagano) November 10, 2013

Suggestions

So what does a well-intentioned friend do?

People hate this answer so much for some reason, but it's really the honest, god-damn truth: read some blog posts. Or books. Just read about this stuff and become incrementally more educated about it. (Shanley Kane recently made a reading list for managers, and it is totally relevant to managers and non-managers alike.)

You can also learn more about derailment tactics over at the delightful Derailing for Dummies.

And one final reading suggestion — if you're looking for something totally brilliant and sad to read right now, I suggest Melissa McEwan's The Terrible Bargain We Have Regretfully Struck.

Edited to add (11/10/13, ~5:14pm):

I think something I failed to express here was that derailing is something that we should all be aware of because it's so easy to do. I want more people to have the vocabulary so that they can notice when their conversations have gone off track, and try to get them back to wherever they were. And if you find yourself having derailed a conversation, it's not a big deal! Just help get things back on track, and figure out why you didn't want to talk about the subject at hand in the first place :D

[lillielillie]

opinions including pair programming is super awesome and also solo struggle programming is beneficial, too

Ben Orenstein gave a talked at GoGaRuCo 2013 called Frequently Asked Questions. He's a dev at thoughtbot and also works on their Learn program, where he mentors new programmers. Naturally, he's heard plenty of FAQs doing that.

The first question he talked about was "How do I get better at programming?" His first suggested tactics were:

Pair program

Program by yourself

I super <3 pair programming. Omada pairs as close to 100% of the time as makes sense, which is super rad. I learn from my coworkers constantly and I spend more time actively working at this job than any I've ever had before (and not because I'm some kind of reformed slouch). The focus and accountability that pairing engenders can't be overstated. (Although I do sometimes wish I could take more Twitter breaks. Because I'm terrible.)

One thing I do miss, though, is pairing with people closer to my skill level. Mr. Orenstein straight up said that although we can learn a ton from pairing with folks who are better than us, we should't underestimate the amount we learn from pairing with people who know as much as us, or less. At Dev Bootcamp, I was around the level of my cohort-mates with room for variation than kept things interesting. At Omada, though, I just know a lot less than everyone else. And although Austin does a great job of making me drive, we wouldn't get anything done if 100% of the time were spent with me driving (AKA stumbling about the codebase).

So the thing that I need right now, I think, is to make some dates with coders who are around the same level as me, so we can struggle through problems together. Which should be extra fun for how much less anxiety-laden it is to admit confusion when your pair is probably as confused as you.

(Of course, admitting that you don't know something is another skill Mr. Orenstein encouraged us all to get really good at. He made the VERY VERY excellent point that the short term benefits of appearing to know something are definitely way less than the long term benefits of actually understanding the topic at hand.)

I can feel my weak JavaScript muscles growing weaker, and know that there are some sweet Active Record querying techniques that I need to learn. Plus a ton of things about Rails. And so there's Improvement Tactic Two: program alone. Struggle through problems. Do things the hard way.

I'm working on feeling more independent as a programmer. Since most of my friends are Rubyists, it's really easy for me to get help when I don't understand something. Which has left me less than ideally independent. Figuring out things about the Omada app with Austin's strategic guidance has helped me feeling more capable of finding my own way through a problem.

So my job for money is to pair with folks who really know what's up. And my other job is to pair with people who know about as much as I do, or less. And my other other job is to code by myself.

(I'm typing this while on a plane headed toward Ruby DCamp. I am always my most ambitious while trapped inside a tube of metal flying through the sky; I'm free to dream up all kinds of amazing things I want to work on. Reality is so far away.)

[lillielillie]

I positively impacted someone's perceptions of reality! WOW!

I love GoGaRuCo. It was my first tech conference and as a single-track Ruby conference that care about diversity of humans and talks, it's my favorite.

Remember that scene where the Grinch's heart goes from 3 sizes too small to breaking the heartsizeometer? That pretty much happened to me on the first day this year.

They had lovely posters packed in REALLY big poster tubes (about six inches in diameter; four inches bigger than necessary) that they were giving out at registration. The dude who handed me mine looked familiar, and then I saw him again standing near the wall during one of the first few talks. I asked my friend if she know who he was, because I couldn't place him. But I was sure I knew him from more than just GoGaRuCo 2012.

He walked over to my lunch table about halfway through the meal, and I placed him. We'd spoken at breakfast the first day of the conference last year, and again later in the conference, as he pointed out.

Then he straight up told me that the discussion we'd had last year had changed the way he thought about the world and thanked me soooo much for taking the time to talk to him about it.

What? Really? What? What?

We'd talked about privilege and diversity and why diversity is good and how hard it can be to realize how much you get for free when you are a privileged person and it had all stuck with him. He chewed on it and learned more and thinks about the world in a totally different way than he did a year ago. One thing that especially stuck with him was Peggy McIntosh's Invisible Knapsack metaphor — that every kind of privileged position can be learned about by considering all the ways the world does you favors simply for being a member of that class.

Actually, If you haven't read her piece, abandon this right away and go check it out:

Peggy McIntosh's White Privilege: Unpacking the Invisible Knapsack

Barry Deutsch collected a Male Privilege Knapsack that is really great, too.

So we chatted a bit more about privilege and life and what it's like for him to have a new daughter (every storybook protagonist is a boy! GAH!). And about how he'd successfully introduced his wife to some of these concepts, and that they can be total feminists and also have "traditional" gender roles (she at home, he working outside the house) because the two ARE NOT MUTUALLY EXCLUSIVE.

HOW CAN THINGS BE SO AWESOME SOMETIMES?

And he thanked me three more times for having those initially conversations with me, and asked me if I knew if Carina Zona would be around, because he wanted to thank her, too, for what they'd talked about in the same vein.

All of this was pretty overwhelming. What can you say beyond "Wow!"?

I forget just how powerful gratitude is, and I'm thinking now about the people who have expanded the way I look at the world, and how much I should thank them like this gentleman thanked me. (In brief, I am largely a feminist today because of Melissa McEwan & her blog Shakesville. More thanks later!)

eeee! yay! happiness! woooo! !!!!!!!!!!!

[lillielillie]

Two weeks in at Omada

I've been an engineering intern at Omada Health for two weeks, and although I'm still panicking over what I don't know at least a few times a day, the intensity of that panic is slowly leveling off.

Omada makes a site called Prevent, which helps people who are pre-diabetic learn to eat better and become more physically active, which has the side-effect of weight loss, which in turn helps them avoid actually developing type 2 diabetes. Although I'm generally not a fan of dieting, since I think fat people are totally rad as-is, Omada's business model is not predatory. It doesn't capitalize on shame or yo-yo dieting; it’s designed for actual lifestyle change toward a specific health-based goal. Which is not evil. Yay!

My relationship with Omada began with a tweet from a RailsBridge friend: Austin asking if I wanted to practice interviewing since Dev Bootcamp was over. Of course I wanted to! And then we chatted on the phone, he told me about Omada, and I realized that I actually wanted to work there. It was the best trick ever. I had some more interviews, they went well, and a 3-month internship offer was made and accepted.

The development team at Omada practices extreme programming, which in practice means agile + pair programming + TDD. I'm sure there's more nuance to it found in its Wikipedia article, but those three things affect my life the most. Since I haven't ever developed software in a non-agile way, I don't know that pain, and pairing full-time at Dev Bootcamp means I'm somewhat comfortable with that already. TDD? Despite having known what it is for a while, I haven't ever done it. So while I'm pairing with someone, I'll first wander over into the app/ directory and start writing some code, and they'll gently push me back into the spec/ directory to write some tests first. I feel a little like a puppy being taught to sit, and it's great. (They are nice people.)

Pairing with people who know way more than me about coding AND way more than me about this particular software has been harder than I expected. I've been quite allergic to the keyboard, and have regressed a bit on the “thinking out loud” front. At Dev Bootcamp, I was generally within a few clicks of my pair's skill level, so the potential embarrassment of explaining what I didn't understand felt much, much lower. Even with what I imagine are more conservative expectations for me as an intern, and with the kindness and geniality of the Omada dev team, I still manage an impressive Fear of Sounding Stupid (the other FOSS?).

One highlight of my internship so far has been pairing with Austin, who is also my manager and the VP of Engineering at Omada. He has an amazing way of turning into a combination of a bridge troll and Morpheus when we're pairing. First, he asks how I would do something (SSH in a particular box; write a particular test) as the first of several riddles, and then gives me hints as I stumble toward a solution. At some point while I stumble, he will SO dramatically say "What if I told you ... (something vague but eventually meaningful)". And then I poke around there, and eventually get us to some kind of reasonable solution. It's really challenging, fun, and extremely effective at teaching me things.

I had breakfast last week with Anna-Marie Panlilio, a DBC Chicago grad who is now in the Bay Area and is seeking gainful employment as a developer. We got on the topic of where the gaps in our knowledge were — what I would do given another 9 weeks of intense study time. Although algorithms, data structures, and CS fundamentals are things I want to learn eventually, two weeks at Omada has taught me that I really need to keep working on the emotional intelligence piece that DBC tried to impart on us. Honestly, the amount I can learn is most restricted by my own secret belief that I don’t know what I’m doing. Or perhaps more accurately, the belief that I won’t be able to figure out enough of what I’m doing to justify the vast swaths of time spent confused. Confusion about code is totally fine. Confusion about whether or not I am mentally capable of figuring out what the hell is going on is less productive.

Luckily, I get to go to work every day and write code. Which is totally neat, and along with self-awareness and maybe a little bit of meditation, the perfect antidote to any fear, uncertainty, and doubt I have about being a developer.

[lillielillie]

shortcut portrait no. 1: Orion & command + L

Part 1 in a series on people and shortcuts that are awesome.

the shortcut

In web browsers, you can select the address bar using command + l.

(Disclaimer: I didn't test this in IE, or on a PC.)

the person

Orion Montoya is a programmer and lexicographer and generally a damn fine human being. We first met while I was a support rep at VerticalResponse. Every new hire has to sit with a support rep for an hour during their first few weeks to learn about the customers and the product. Afton the HR Person recognized that Orion and I were probably the biggest hipsters in the office, and paired Orion with me for his support shadowing. The phone lines were pretty dead, so we talked about the internet and explored how the jQuery 3D icon carousel worked on the VR home page. Then we ran into each other at the nearby food trucks, and became super workfriends (fast enough that coworkers were confused about whether we were friends prior).

Unrelated: Orion and I are on the same haircut schedule. We met up for lunch on Monday, for the first time since May, I think. My first question for him was when he'd gotten his haircut (Saturday). I had just gotten a haircut last week. We both go about four months between haircuts, allowing our respective hairstyles to get unpleasantly shaggy before getting a haircut and looking reasonable again.

the story

I wanted to be able to move through my tabs in Chrome without clicking on them, so I mapped (for some reason) command + k to move to the next tab to the left, and command + l to move to the next tab to the right. One day Orion came over to help me out of what was probably some kind of Git mess, and was confused that command + l didn't select the address bar in Chrome. I told him about remapping it, and he explained to me the joy of command + l. I now almost never click on the address bar, thanks to Orion and my silly choice of remapping.

(I later learned to use command + curly brackets to cycle through tabs.)

(Update: I originally posted this saying command + square brackets, which is apparently forward and back in your history for that tab O_O)

what is this?

Last night I was working on some code, and was very tired. I kept forgetting where I wanted to go, so I was just hitting command + l repeatedly, as though it was jumpstart my brain. It reminded of the dark ages before I know about that shortcut, and how Orion taught it to me. I realized that a lot of the shortcuts I know were taught to me by different people at different times, and that is how this series was born.

[lillielillie]

Who Doesn't Love Overly Ambitious Unemployment Project Lists!?

Unemployment is such an enticing time for every mode of self-improvement I've been idly considering. Some of the things I would like to do:

get at least 30 minutes of cardio at least 5 times per week

stop eating total crap - maybe cut out all processed sugar?

meditate every day, learn more about buddhism

spend very little money

Basically, change every bad habit I have! And add good ones!

So some of those might happen. But what's really exciting are the 1,000,000 competing projects I want to work on:

Item 1: Apply for Jobs

Obviously the most important part of unemployment. I've been unemployed twice before (once when I first moved to SF and then after I worked at Oberlin for four months and moved back to SF), and one of the things that feels the most different is that I can actually increase my employability every single day by writing more and better code. Which is pretty damn exciting.

Item 2: Make Job Application Management Tool

I pitched two final project ideas at Dev Bootcamp, but neither of them got picked. So I'm building them myself! The first one is a job search management tool (working title: Snapplicant). The interaction I want very badly is to be able to click a bookmarklet and have it create a new prospective job for you in the app. The challenge here is that every company in the world has different conventions for their job description markup, which means I'm going to have to settle for some user interaction, at least initially.

(I'm thinking you click the bookmarklet, it asks you to click the job title, and then the JavaScript shows you what it thinks is the description details for that job. And then saves them once you approve / edit.)

Item 3: LillieChilen.com Overhaul

I've been wanting to learn about static site generators like Jekyll and Middleman, and having spent some time on CSS with my final project, have decided that my current visual design is not great enough. So a back and front end overhaul is in store.

Item 4: Remember Bridge Troll?

For about six months earlier this year, I managed an open source software projects called Bridge Troll. I have a lot of catching up to do on that project, and am psyched to write more code for it.

Item 5: DBC Final Project Refactoring

Some of the code we wrote for our app wasn't the best code in the world, and we sure as hell didn't write half enough tests. So I'd like to first fill out our test suite (unit and integration) and then do some serious refactoring.

So basically all the things! Wish me luck!

[lillielillie]

Exhausted by the wrong things: moving on from DBC

I finished Dev Bootcamp on Friday. The real work was over Thursday, when we wrapped up our final project and presented it to our classmates and a few employers who dropped in for the presentations. (I'll tell you all about final projects another day.)

DBC has a new-ish invention called Phase Four. After you're done with your nine weeks of DBC proper, you can stick around for another three. In exchange for TAing for 15-20 hours per week, you'll be taught some things, and can be in the space as much as you want. There's a lot less structure during phase four — folks are applying for job and going to interviews, cleaning up their resumes and websites, and sometimes continuing work on their final projects.

All in all, phase four is a really good deal: you get to review phases one through three by TAing, it's a nice place to work for the first three weeks of your job search, and you don't have to say goodbye to everyone quite so suddenly.

Despite all these things, I'm not doing phase four.

The short explanation is that I've been far too concerned with the culture of DBC over the last nine weeks, and that has taken an emotional toll that has not helped me as a student of web development.

Don't get me wrong — I've learned truly ridiculous amounts about computers.

But DBC isn't a place where I feel relaxed enough to really focus on code.

My two main experiences in tech prior to DBC were RailsBridge and working on the sales team at VerticalResponse. RailsBridge is obviously a self-selecting community of awesome (especially for a woman), and VerticalResponse is a company led by a woman and is full of people who are very comfortable (for the most part) with considering themselve adults. DBC lacked both of these things, and I did a poor job of properly steeling myself for the experience.

Of course I didn't go in expecting DBC to be a feminist paradise. But the first three weeks included so much emphasis on treating each other well that it was hard not to have my hopes raised.

DBC has a thing it calls Engineering Empathy (EE for short). For my cohort, this meant primarily that every week during the first phase we had an hour on a Tuesday morning to learn about relating more effectively and honestly as humans. We were getting closer as people as a result, and although those hours could bring up some REALLY painful feelings, it was changing the way we treated each other for the better.

And then it stopped.

We went into phase two. We weren't "having our hands held" any more. And with this explicit emphasis on personal responsibility came an implicit message that the feelings stuff from phase one was over, too. (And it was over — explicitly — as well.)

It was really hard the next six weeks. Every time I argued that we should treat eachother better as humans, and not just value each other as technical beings, every time someone would talk about what a waste of time EE was, every subtle sexist and racist and ableist comment that I heard, I mourned the loss of EE. I mourned for the amazing habits that began to take hold, but were quickly forgotten in piles of technologies.

(At times, I wished we hadn't had those three weeks of EE. What if I had never thought that we could be challenged to be better people? But I was still personally better for it, so no dice.)

They're working on it. I've heard that now each cohort has five sessions of EE, so it continues well into phase two. They're also having monthly all-school EE. They are really trying.

But it's not there yet. And it's time for me to take a break from that fight, and write some fucking Javascript.

[lillielillie]

The ROI on Soft Skills

Oh, Dev Bootcamp.

There is an activity where students teach other students what they’ve learned in a given phase at DBC, and I fought hard today to include “soft skills” as a category that should be taught to the incoming Phase Two students. So hard as to walk up to the white board and write it back on when the moderator erased it after a few people said that it wasn’t important. It stayed that time, one non-technical topic out of nine.

My colleagues at Dev Bootcamp fall into several categories when it comes to learning things that aren’t purely technical, like how to communicate with your peers, how to empathize, or how to relate to your phase teachers. Things one might call soft skills.

Many (most?) of us are pretty stressed out about learning all the technical things we need to know in order work as effective web developers.

Some of us think that we do a more than adequate job of listening/communicating/empathizing already.

Some of us don’t think that spending time getting better at listening, communicating, or empathizing effectively will pay off compared to spending that time understanding web sockets or ActiveRecord associations or one million other technical things.

Some of us would like to get better at those soft skills, but just don’t feel we have the time.

Some of us are actively working on these skills.

But if the point is to become the most effective developer possible, I imagine the return on investment on good interpersonal skills to be quite high.

The staff at DBC are explicitly trying to run a program that does address both the technical and human skills, to various degrees of success.

But no matter how many times the staff emphasizes that being a great developer goes beyond just knowing the code, the students that vocally dismiss human skills are telegraphing to their peers and younger cohorts that those skills aren’t as important, and that that work is lesser.

And that is what makes me most sad.

Cross posted at Yet Another Dev Bootcamp Blog.

[lillielillie]

I went to RailsConf! (Two months ago.)

I wrote this nice blog post right after RailsConf and then forgot about it. Whoops!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

RailsConf did a really cool thing this year and offered "Opportunity Scholarships" for new and underrepresented people in the Rails community. I got one of these! I didn't have to pay for a ticket and I was paired with an established RailsConf-goer who could introduce me to fun people and give me the lay of the land. (We also got to sit in the front at the keynotes and were often given good advice on Twitter using the #rcguides hashtag.)

It was really quite lovely. With Dev Bootcamp looming, I'm a bit crazed trying to get as many RailsBridge things done as possible before my 9-week sabatical. So there were a few times that I took a break from chatting and talk-going to write a blog post or reorder the event on the RailsBridge website. But those things were fun, too :D

And here are some thoughts on some of the talks I went to:

Keynote Sparring FTW

So DHH had the keynote Monday morning, and explained the new features in Rails 4 and how he uses caching and JavaScript to make zippy apps. I understood what he was saying, generally! Which was great. And got a much better idea of what the 37signals Russian Doll pattern is.

Tuesday morning, the keynote was Yehuda Katz. And he basically said that JavaScript used to suck a lot, and it sucks a lot less now, and that we should stop writing ad hoc JavaScript and embrace that we will be writing a lot of JavaScript. JavaScript JavaScript JavaScript. It was pretty fun to watch him offer a direct alternative to making a zippy app than the Russian Doll pattern, and although I'm new to all this stuff, he seemed relatively restrained. But still, some digs. Hilarious digs.

And then, the final keynote was Aaron Patterson, who offered a delightful amount of mocking of everything, followed by a great look into how the Rails security team works, how recent expoits happened and were resolved, and how he loves open source. (When I went to Waza a few months ago, I went to a talk about managing open source projects instead of Aaron's talk, and now I understand why the adjacent room was completely dying for the first 10 minutes of that time slot.) Aaron's talk probably had the most stuff that I didn't understand of all the keynotes, in part because he didn't define all of his acronyms about security, but I was able to follow along relatively well nonetheless.

(Oh, and @rands gave his Stabiles and Volatiles talk again and it was still annoyingly reductive and excusing of assholes. There are stable assholes, too, and nice volatiles!)

Sessions: often about request routing and testing!

I feel like I have a decent handle on how a request gets routed from the browser to Rails and back, but it turns out I didn't know quite a few things. Like Rack and middleware. And while I don't totally understand how Rack works, I have a much better idea of how it connects the Rails app to the webserver. There were actually two talks about routing and how a request travels through an app, and seeing both of them was super great.

The other big theme was testing. I watched a talk I didn't much get behind about testing that argued that all unit tests are too brittle to have any use, and should be thrown out if they are created in the process of TDD. This was right after a totally brilliant talk by Sandi Metz about how our unit tests are too brittle, and we need to be writing about half as many tests (and she taught us, very clearly, which tests we should be writing). So I understood pretty clearly the need to have selective tests for the right things, but Sandi's argument seemed far more based in logic and not just being mad at tests. (That presenter was advocating for integration tests only.) Also, Sandi one a Ruby Hero award! I was sad that Sarah Mei didn't get one, but maybe next year.

I also attended a session on front end testing, and got a nice explanation of a lot of the tests that we have for Bridge Troll. Although I knew on some level that Phantom.js was involved (since it'd been causing trouble with our Travis CI server), I didn't know really how the various parts (Capybara, Phantom.js, and Poltergeist) fit together. And now I (kind of) do!

No One Will Teach You But You

Zach Brigg's talk is probably the one that will have the most lasting affect on how I learn programming. It sounds silly, but there was one big lesson that I'm surprised is as surprising as it is.

When you Google something, write it down. Then review it.

Yeah. That makes sense. Otherwise, when you google some syntax that you know you've used before, but you just can't remember, you'll reread the same Stack Overflow entries and blog posts that you've read three times before.

Other Odds & Ends

I learned about DevOps and Puppet. I learned about the strategies of a start up that's attempting to practice some kind of agile design. I was adopted by the amazing crew at Thoughtbot for an evening of dinner and drinks, and heard about a ton of amazing tech groups / programs / initiatives for women and girls (and also got to see New Relic's totally gorgeous Portland office). Actual human faces replaced Twitter icon in some cases, and I got to tell people all about RailsBridge and my upcoming Dev Bootcamp adventure.

I only thought about turning 1/3 of the things I heard into RailsBridge workshops!

Oh yeah, that NPR story

I woke up on Monday morning to two emails, both from acquiantances telling me they'd heard me on NPR! I'd been interviewed by Laura Sydell a few weeks prior for a piece she'd be doing about Sarah Allen and women in tech. We'd had a 30 minute in-person chat at VerticalResponse, and I'd only said about 20 things that I was terrified that she would put into the piece. Thankfully nothing she said was a total lie. (Except the part about me getting hired as a programmer after attending a RailsBridge worskhop. That is in no way true.) There were a lot of Facebook and Twitter posts about it, and a few people that I'd met the night before saw me the in the hallway and had to exclaim about my famousness. It was pretty silly. If you haven't listened to it, it's a legitimately nice piece of radio about Sarah and tech and RailsBridge.

[lillielillie]

I'm a dude. Can I organize a RailsBridge workshop?

When talking with people about making more RailsBridge workshops happen, I'm often asked by men: shouldn't a woman be in charge? Shouldn't a woman be the event leader? Isn't it weird?

My emphatic response: PLEASE ORGANIZE A WORKSHOP.

Organizing a workshop doesn't take technical skill. The emailing, arranging, and logistics-handling required of a RailsBridge organizer is mostly behind-the-scenes and without much glory. And I hate the idea of women doing all the logistical heavy-lifting while men show up and teach Rails. (Of course, I love that anyone shows up to teach Rails. Of course.)

If RailsBridge were a woman-identified-only event, this would be a different story. But the room is already quite diverse with all the teachers; having men as organizers will certainly not reduce women's position at the workshop. Male organizers also helps us challenge bullshit gender stereotypes, like the idea that women are inherently better nurturers. We need to all challenge this idea not just with discussions and blog posts, but with the roles we take in these events and organizations.

So gentlemen, dudes, guys, and men: please organize a workshop. Please assist a woman who's already organizing one. Take those logistical things off her plate (if she wants to share them) so that she can be a technical presence at a workshop. (Perhaps you can recruit a woman to present the technical portion of the opening presentation while you cover the other parts.)

Often the best teachers and TAs are those who have been learning this stuff recently, who can really empathize with the students. But if that technical woman is busy dividing up classes and ordering lunch, she's not going to be able to teach and be a technical role model to the students in the room.

If you're worried about how to be a good ally (and even if you're not), I highly, highly, highly recommend Melissa McEwan's piece on allyship. But first, if you feel weird about the word privilege, I recommend first reading John Scalzi's Straight White Male: The Lowest Difficulty Setting There Is, which is a totally brilliant video game-based introduction to the concept of privilege.

Email [email protected] with your interest in helping. It's good, satisfying work, and we need your help.

A Post-Publishing Thought / Update:

I should say explicitly that there should be strong technical female leadership in the room; it would not be good to have 100% male-identified volunteers. And if a woman wants to organize a workshop, that is totally and completely awesome. Organizing being non-technical work doesn't diminish its importance, at all. At all. At all. (That was one at all for every workshop I've organized.)

[lillielillie]

Brief Recap & Select Learnings from Employment Times at VerticalResponse

I gave notice at VerticalResponse last week. My last day will be May 9th, 2013.

On Monday, May 13th, I'll be joining about 17 other humans to spend 9 weeks furiously learning all things web development at DevBootcamp. My cohort's nickname is the Red Admirals, which I've learned is a common butterfly in California.

More on that soon. First: reflection time!

Unemployed --> Employed

I started working at VerticalResponse in October 2011 after meeting a VR tech support manager at my very first RailsBridge. She was in my class of Advanced Beginners and gave me her card at lunch. I was applying to product management positions, but was woefully underqualified for them. So I gave customer support a try.

It was hard, but really gratifying. There was so much to learn about the system, the customers, and email. It turns out writing HTML for email is easy if you're able to mentally time travel to about 8 years in the past. Forget all modern CSS rules, and you're pretty much there. (Editor's note: this is only half true, there are lots of other places to get tripped up.)

Our customers' technology comfort levels range from not knowing what a browser is to web developers trying to figure out why Gmail is doing this funny thing to their inline CSS. I had a great time teaching people a little more about their computer and the web at large, and helping the advanced folks troubleshoot the insanity that is email rendering in Microsoft Outlook. (Which uses Word to render HTML, rather than IE. WORD!)

After about six or seven months, I'd figured out the product and was able to easily exceed the required numbers of calls / chats / emails per day. While people were on the whole totally reasonable, things shifted so that when a call was challenging it wasn't because it was technically interesting, but rather because there was an angry human who needed to vent. (Less fun than weird CSS.) While I didn't achieve my goal of becoming a totally zen support rep, I did get better at diffusing tense conversations.

A Promotion

And then there was an opening on the sales team as the Sales Engineer! Since I'd been learning to code since before starting in support, I was able to get that promotion and found myself facing an entirely new slate of technical challenges. For the past year I've explained our API to prospective partners, worked with client developers to troubleshoot their code, improved the documentation, and slowly taught the sales team as much about the Internet and technology and I could.

All customers (including those who will be using the API) are shepherded through the sales process by our amazing inside sales team. So I haven't had too much pre-sales communication beyond the occasional tech call to confirm that the client developer understands what our API can do and that it's a good fit. It's probably more accurate to call me a developer support engineer than a sales engineer, but I'm not too worried about it at this point.

Farewell

It's time for me to dive into development and take a break from troubleshooting other people's code. I'm sure I'll still have plenty of errors to find and fix, but they'll be bugs in things I'm actually building! (At least until I get a job and get to fix other people's bugs. And write code!)

My path from admin work to software and hopefully soon a gig as a real-life developer has been winding but wonderful.

Here are some other important things I learned at VerticalResponse:

How to work on remote servers

How a compiled language works

How a SOAP API works in C#/.NET, Java, PHP, and Ruby.

Some random stuff about DNS

What a self-signed SSL certificate is and how we use them.

Many things about how emails render in the browser and desktop email clients

What email deliverability is (and that it's a real word)

Almost everything about the VerticalResponse web app

Almost everything about the VerticalResponse API

What to ask a dev when troubleshooting their weird API issue

The importance of good error messages

To appreciate the customers who provide gobs of info up-front when they have an issue

What a WSDL is and how to say it out loud (wiz-dul)

A little more about Vim than I knew before

How to use DbVisualizer to look at the API logs

How to get the XML of a SOAP request & response

That SOAP is not very popular with Ruby devs

That tabbed-completion in an IDE is real, real helpful

To go slow when explaining highly technical concepts to my co-workers

That my enthusiasm about technology can be infectious

That I really love my team

I'm going to miss some people, but I'm confident that my future includes lunch dates with those folks, and maybe even co-worker-hood again at various other San Francisco tech companies.

[lillielillie]

Computer Empathy Needed

I'm very bad at thinking like a computer. I will write lots of lines of extra code to make the code mirror how I think about the thing working. I really, really want the solution in my brain to work on the computer. I work less hard to challenge my initial design choices for a solution.

But then I look at other people's code, and realize that I should befriend the computer and learn to think a little more like it does.

Two Challenging Challenges

Two recent Ruby exercises were particularly challenging for me. The first was creating a factorial method, and the second was creating a Reverse Polish Notation calculator (but just addition, subtraction, and multiplication).

My personal rules for Ruby exercises:

Google is okay, for specific sub-tasks that I think that I should be able to accomplish with Ruby but don't know the syntax.

Google is not okay for looking for actual answers.

Same goes for Wikipedia. If pseudo-code appears, the windows closes.

If I'm totally perplexed by the output of a command, and I've been struggling for a while, I can ask a programmer if I'm losing my mind.

Try to use the Ruby documentation as much as possible, then use blog posts / Stack Overflow.

If I think my solution is terrible, I can describe it to a programmer to see how horrified they look, and course-correct from there.

Factorial!

Implementing factorial was fun. My first idea was to loop over the number - 1 and add each result to an array, and then just multiply all the elements in the array together.

But I didn't know enumerable#inject yet, and decided that was probably a silly way to do it.

So I went back to thinking about loops, and making something that will multiply a number times itself minus one until it gets to one. Here's what I ended up with:

https://gist.github.com/lilliealbert/5356538

Which is not terrible! I've been told by people who know more programming than me that this is not a bad way to do this, that it could be optimized a bit more, but that not using explicit recursion here is okay. Ideally I would have made this choice because I knew it would be better than recursion — not because I didn't think of using recursion at all.

Do This Math: 70 10 4 + 5 * -

The second eye-opener was implementing a Reverse Polish Notation (RPN) calculator. RPN is a way of writing arithmetic with the operator after the numbers, instead of between. It was created after Polish Notation (where the operators are first) for the sake of computers, since the first calculators couldn't deal with precedence.

The way I think of RPN:

I look through the operation until I get to an operator.

Then I grab the prior two numbers and put the operator between them.

The resulting number then replaces the two numbers and the operator

Start over! Look through till I see an operator, go back two numbers and apply it, replace the numbers and operator with the result.

The problem above, then, looks like this in my brain:

70 10 4 + 5 * -

70 (10 + 4) 5 * -

70 14 5 * -

70 (14 * 5) -

70 70 -

0

I even read an analogy that you take the numbers, put them in a stack, and then when you get to an operator, pop off the last two items and apply it. THEY USED THE WORD POP.

(For the non-technical: there is a method in Ruby called pop. This makes me not using it a little confusing.)

But I had it in my head that you find the operator, then go back two numbers, and then apply. So this is the code that I ended up with:

https://gist.github.com/lilliealbert/5347902

I made the Ruby equivalent of what was happening in my brain, instead of using the totally reasonable methods available to me.

Goals

I'm going to learn to think more like a computer.

Step one: I'm going to stop implementing my mental model just because I want to, especially when there are large blinking neon signs (like array#pop) pointing me toward a more idiomatic solution.

[lillielillie]

How I Meta-Organize in San Francisco

This month marked the first anniversary of my joining Rachel Myers as a RailsBridge meta-organizer. After I organized a workshop in March 2012, she asked me at the afterparty if I wanted to help her make workshops happen each month by finding organizers and venues. Drunk on the power of having successfully helped 60 humans learn Rails (and several delicious beers), I agreed.

Over the last year, we've ramped up from having an average of one workshop per month, to three workshops every two months, to two workshops per month. This is mostly due to ever-present demand and the growing number of curricula written by awesome volunteers. We do an Intro to Rails workshop every month, and then other workshops on a rotating basis. We are super lucky to have a lot of companies willing to support RailsBridge by opening their office doors and buying dinner, breakfast, and lunch for our students and volunteers.

What a meta-organizer does

My workflow with Rachel has evolved over the year. At first, there was a lot of copying of eachother on emails to organizers and venues, and keeping lots of things (potential organizers, potential venues) in our inboxes and in our heads. Since we do not have a hive mind, though, I made a spreadsheet where we could list out our prospective organizers / venues, the status of each upcoming workshop, and which of us was responsible for making sure that worskhop took place.

With that spreadsheet in place, the planning part of the meta-organizing role is mostly straightforward:

At least once per quarter, get together to brainstorm and send emails.

Comb through the past volunteer and organizer lists to see who might be willing to organize again or for the first time.

Look through our list of companies who have previously offered to host or that we have contacts at and decide who to ask.

Send out a bunch of emails to potential organizers and venues.

Follow up with those who have questions or are up for it.

Connect volunteers and venues to pick a date for their workshop.

(This process gets way simpler when people volunteer to organize; often these folks are also volunteering their company to host. This is particularly awesome for Rachel and me, because we get to skip straight to supporting the organizers.)

It often takes a month or so of emails back and forth to firm up a date for a workshop that's a couple months out. But once dates are chosen and venues confirmed, we are mostly around to support organizers and their mentors. We assign most organizers mentors, even if they've organized before, since it can be nice to have someone else to bounce ideas off of, and Rachel and I aren't always available. We often have a kick-off meetup with the organizers at the venue or a cafe to go over the general details and answer any questions they have.

Challenges

Not surprisingly, the biggest challenges that I've had as a meta-organizer have been around communication. Sometimes it's between the venue and the organizers, or the organizers with eachother, or some other group of people. One of the big projects I worked on last year was overhauling the Organizer Cookbook, in the hopes that it would help our organizers become more independent. It's worked! But sometimes people don't read it. It's pretty long, so I don't blame anyone for being a little overwhelmed by it. Project for 2013: make a high-level intro to organizing that is factual and fun.

I'm a pretty detail-oriented person, but I try not be anyone's boss about exactly how to make their workshop happen. I have about a million opinions about organizing and what works best, but workshops tend to be okay (actually, great) without perfectionism. Rachel is a much more relaxed person than me, so it's good that we work together. We've got the good cop / bad cop thing down to a T. (She is both totally positive and totally realistic in a way that regularly blows my mind.)

The other main challenge to being a meta-organizer is the onslaught of exciting information. Since we're pretty visible in the RailsBridge community, people often direct their questions and ideas to us, which is amazing! And also can be totally overwhelming when you're also trying to make workshops happen, have a full-time job, and in my case, build Bridge Troll. It can be hard to always follow up on the cool things people throw our way, and another of my goals this year is to recruit more community manager and geographic outreach people, so new organizers in other cities have a clear path to making a workshop happen.

What's Next?

Do you know anyone who loves diversity in tech and humans and spreadsheets? I'd really love to hear about them. I might have communicated this already, but I'm really busy, and I'd love to have more leaders in this amazing community.

For the less spreadsheet-inclined, we need help in about a million different ways, especially writers to help us communicate what we're doing and talkers to help mentor and encourage our organizers.

Email me at lillie dot chilen at gmail dot com with any nominations, questions, or silly cat gifs.

(Cross-posted at the RailsBridge blog.)

[lillielillie]

Hartl Tutorial, part 1

I've finally gotten around to doing Michael Hartl's Rails tutorial. It's great. The tutorial has you build a little Twitter clone from the ground up. I'm on chapter seven out of eleven, so something like half way through (the chapters appear to be getting increasingly dense), but I've already picked up some really handy information.

TDD

TDD stands for Test Driven Development, a way of writing software in which you write tests for code that you haven't written yet, watch them fail, write your code, then smile because all the dots on the screen are green instead of capital Fs. (And then later on, change something that accidentally breaks something else, and know EXACTLY what is breaking, because you have tests!)

There are a lot of different languages and frameworks and styles of tests, depending on the technologies you're working with. I've written mostly Rspec unit tests so far, going back and forth between writing tests, making them pass, then cleaning up the code and making it better. My very first RailsBridge workshop featured tests written in Cucumber, but I haven't really done any testing since then. A few weeks ago Travis introduced me to Zeus vis a vis Bridge Troll, and that makes my tests themselves run a lot faster, since it's always waiting to run something instead of having to boot up every time I tell the tests to go. If you're curious about testing, Wikipedia seems handy.

Actually using my text editor's power

Hartl provides some great optional setup instructions for Sublime Text 2, and getting testing set up within my editor alone was a huge help. I had some trial and error (and a lot of googling) to get Zeus working from within Sublime Text, but now it's working great. (Except for the times that I add gems and forget to kick the Zeus server. In those cases I look very very carefully at my code for a while before remembering that its just that Zeus doesn't know about the new gem yet.)

I'm still using my mouse to click around between the various files, but pairing a little bit with Michael Glass over the weekend and working with Travis (he uses RubyMine) is showing me the benefits of getting the navigation keyboard shortcuts down to muscle memory. I'm actually thinking about getting a subscription to ShortcutFoo to build up those brain muscles.

Other Stuff

I feel pretty comfortable with the MVC paradigm and the role of models, views, and controllers, but it's been good to review them in detail. Hartl explicitly says that the tutorial is an introduction to web development in Ruby on Rails, so he's not teaching Rails exclusively. So he covers fun stuff like Bootstrap and Sass.

Also partials. Partials are great. And Gravatar's use of the md5 algorithm to hash your email address to connect it to the image they have for you. You run the person's email address through the md5 function and the hash that results is that person's using this URL: http://www.gravatar.com/avatar/HASH. Which is really neat.

Now, onto actually getting users a sign up page! And tweets!