Discussion of software apprenticeships at All Girl Hack Night

At the March meeting of All Girl Hack Night, a startup founder Diana Griffin and two women developers -- Tricia and Autumn -- talked about software development apprenticeships they did at Diana's startup, GirlsGuild.

A startup's decision to take apprentices

GirlsGuild is a startup that matches women makers (they didn't want to call them "masters", as that might sound too intimidating) with apprentices who want to learn a skill or a craft: leatherworking, chocolate making, graphic design, or many more. So it is only natural that its founders wondered how the notion of apprenticeship would extend to software development. In the software world it is also known as eating your own dog food. Having only recently learned programming, GirlsGuild founders Diana and Cheyenne built GirlsGuild web app themselves, with the help of more experienced Ruby on Rails developers. So they also wanted to give back and teach other women what they knew of programming.

Thus they announced apprenticeship positions. They view them as different from internship. They expected that apprentices were completely new to programming, and that they might not know much at all.

In Tricia's case, it turned out to be true. She went into apprenticeship to gain experience she couldn't gain otherwise.

Reasons to become an apprentice

A beginner developer who wants to get a job in the industry must demonstrate some kind of credentials or programming ability to potential employers; if you don't have computer science education, that can be tricky. It is a chicken-and-egg problem, getting experience without already having experience. That's where unpaid work, such as an internship, can give a foot in the door to a beginner programmer.

And that's why when Tricia heard about an apprenticeship opportunity with GirlsGuild, she applied. It helped that she knew Autumn, who was already working there as an apprentice. Up until that point, she had taken some Java courses at the Austin Community College, but had no programming experience in the industry. Without it, or a degree in computer science, she didn't see how she could ever get a job as a software developer.

At first she worried that GirlsGuild won't accept her, but she was determined to come back again and again, and become impossible to get rid of.

Left to right: Tricia, Diana Griffin (cofounder of GirlsGuild), and Autumn at the All Girl Hack Night discussion of software apprenticeships. More pictures from All Girl Hack Night events are in my photo gallery.

Autumn admitted that she worried about that too, even though she is an experienced software engineer, and her reasons for going through an apprenticeship were different. She was working in a well-established organization with a large team of developers; as typical for a large institution, it had complex processes and procedures in place for everything, such as testing, doing code reviews, and deploying to production. Autumn, however, wanted to experience working in a startup, where processes are minimal, red tape almost nonexistent, developers have very close interaction with business owners, and large influence in the product.

Neither of them needed to worry about not being admitted to an apprenticeship, because GirlsGuild was happy for every helping hand they could get.

Structure of an apprenticeship

GirlsGuild founders Cheyenne and Diana got together with Tricia and Autumn for 3-4 hours a week. At first they walked them through the code, examining various use cases, a la "When a user clicks this button, here is what code gets executed in the background". They gave Tricia and Autumn full freedom of bugs and issues to work on. They were happy to have anyone to work on them, even beginners. (I didn't ask if they were ever concerned that a beginner would inadvertently make the product worse, e.g. by fixing a bug's symptoms rather than the underlying cause, and making it more difficult to fix the cause afterwards.)

Meetings with Diana and Cheyenne was just a small part of the time both apprentices invested in their work. The meetings took only 3-4 hours a week, but Tricia and Autumn spent much more time than that studying the code on their own. To every meeting they came prepared to implement what they learned. And after a while they didn't need constant hand-holding from Diana. They would work independently and only come to her if they got stuck.

Making it easier for a startup to foster apprentices

It helped that ever since its beginning, GirlsGuild kept a detailed list of code issues in Github. It also helped that they didn't have any other deadlines to meet except self-imposed ones; there weren't any investors breathing down their neck to implement features faster. GirlsGuild, as I understood, is funded entirely by the owners, both of who have full-time jobs outside of GirlsGuild. This gives them a lot of freedom to implement features at their own pace.

Another thing that helped was that their users were so forgiving. There weren't too many users to begin with, and they didn't tend to get upset by errors. Plus, error messages were quite funny, said Tricia, so that went a long way to give the users enjoyable experience even when the application didn't work right. They had a simple, direct process of fixing user-reported bugs: the user would call them, and they would get on fixing the bug right away.

Comparing apprenticeships to other ways of gaining programming experience

The audience wanted to know how apprenticeships compared with other ways to learn programming. Was it a better or worse way than, say, taking self-paced courses at Codecademy? College courses? What about intense development bootcamps, such as MakerSquare?

According to Tricia, who had previously taken some programming courses at Austin Community College, an apprenticeship teaches you very different skills than an academic course. Most programming classes, in her view, might teach you concepts of programming, but not how to write an application from scratch. What's more, they won't teach you other crucial aspects of being a software engineer, such as how to collaborate with other engineers, or use tools (e.g. Github) effectively. So, for a taste of real-life software engineering, apprenticeships are invaluable.

It so happened that towards the end of her apprenticeship, Tricia entered the full-time Makersquare development bootcamp, and Autumn took Makersquare part time courses in the middle of her apprenticeship. So they could not really compare the experience they gained from it to the experience gained from the apprenticeship, but they both thought they would have been much more valuable to GirlsGuild if they had come to it after Makersquare. Diana assured that they were very useful anyway, and that if they had come to GirlsGuild after MakerSquare, they would have been leading the apprenticeships!

Tricia says most prospective employers valued her apprenticeship almost as much as an experience at a paid job, because it showed that she could take a project, persevere, and complete it.

Build Something Awesome… but what?

"Build Something Awesome with OpenStack and the Open Cloud" hackathon could have lived up to its name, if only someone knew what kindof awesome things one could build with OpenStack. Or could explain it to developers. But I'm getting ahead of myself.

Maddy (left), our unofficial team lead and Python expert, and Anna. More pictures from the 2013 OpenStack Hackathon are in my photo gallery.

The September 14th, 2013 OpenStack hackathon was the first hackathon I ever attended. It was organized and sponsored by Rackspace, creator of the OpenStack project. I didn't know much about it, so I assumed that it was just yet another API that lets you build applications. The hackathon event page did not hint at what kinds of applications you could build with it. So I was surprised when it turned out that for the kind of application my team wanted to build, OpenStack kind of… got in the way.

The hackathon started with a 2-hour presentation by Rackspace's developer advocate. He guided us through a tutorial on how to create a DevStack server on Rackspace. DevStack, by the way, he said, is not the same as OpenStack, but the distinction was lost on me. This was by far not the most subtle point that was lost on me.

Left to right: Paige, Jess, Maddy (our unofficial team lead and Python expert), and Christine. More pictures from the 2013 OpenStack Hackathon are in my photo gallery.

After the presentation our team of five, all female developers, rolled up our sleeves to start building the application proposed by one of our members. I investigated the server created during the walkthrough, looking for the directory where Apache keeps HTML files and web scripts. That's where I thought I would place a web application (at the beginning, just a Python script) that we were writing. I saw there was an index.html in the /var/www directory, but its contents were not the one that were displayed when you pointed your browser to this server's root URL. So I went to the presenter and asked why that was. He said, better don't try to use Apache on that devstack server; it's configured in a special way, and if you want to run an ordinary Apache web server, you'd be fighting it all the way. You should create a basic Linux server on Rackspace, not a Devstack server, and install Apache on it. I tried asking him what could we do with this Devstack server, if not write web applications. He said it was mostly for learning. Learning OpenStack. Well, that still didn't answer my question what I could do with OpenStack, but oh well, maybe I should have found out beforehand? It's not like it was any secret that this hackathon was for building things with OpenStack: it was in the name of the hackathon. But I wasn't the only person who went there with assumptions that I could build web applications with it.

Other lessons from this hackathon were more interesting, and came from my attempt to find out what can be accomplished during a hackathon. More about it in the next blog post.

"Computer Chess" movie: come for the 80s tech nostalgia, stay for the weirdness

The movie "Computer Chess" passed largely unnoticed in the big theaters (it didn't even play in Austin), but I greatly enjoyed this mockumentary about a computer chess tournament in the early 1980s. At first I didn't think that it would have much value beyond nostalgic or historical. A nostalgia trip for those who were computer nerds in the eighties, I thought it might be educational for someone like me, who never saw a PC up close until the early 90s. It must have been harder to be passionate about computing in the days when computers didn't fit in your pocket; the really devoted computer scientists, such as the ones portrayed in this movie, put their machines on dollies and wheeled them from room to room when they wanted to play them against one another.

But what drew me in for historical value made me stay for the character study.

At first, the players seem pretty ordinary college students as they get together in a hotel room in the evening and "debate" big questions, such as plausibility of artificial intelligence, or the nature of consciousness, with all the banality of a young person discovering those questions for the first time and not yet having done their intellectual homework. But as the tournament progresses and their programs start to go astray, their personalities blossom into bouquets of quirks.

The movie juxtaposes the players with an "officially" weird group of people: the attendees of a wacky couples retreat that goes on in the hotel the same weekend. Barking at each other like dogs is just one of the ways the New Age'y couples attain some kind of transcendence and deepen their connection. Ostensibly, the computer chess tournament and the retreat could not be more different, but soon they become more similar than one could guess. As it turns out, smart people who are deeply absorbed in, even obsessed with their work, quickly veer into outlandish beliefs. A tired, overwhelmed, razor-focused-on-one-thing human mind is unwilling to accept natural explanations when things don't go the way it wants. The movie does not ridicule anyone: human weirdnesses are portrayed in a loving, non-judgmental manner. It merely observes as the two polar opposites -- computer geniuses and New Age'y quacks -- move closer together. It's fitting that the final match between a human chess master and the computer takes place side-by-side with the woo-woo practice in an accidentally double-booked conference room.

Speaking of conference rooms: this movie has a feel of the lowest-budget-movie-ever. It takes place entirely in a nondescript Ramada Inn. Who would have thought that you could shoot a movie in Austin, and not even have Austin cityscape anywhere in the backdrop? On behalf of my adopted city I might be a little offended. :-)

Some hackathons result in demos, some in questions

After finding out that the Devstack server we created during the walkthrough is not suitable for hosting web applications, I created a "plain" Rackspace server, installed Apache on it, and we proceeded to create a barebones web application. One of my goals was to get a clear idea how much progress a group of people could make on an application in a hackathon. The answer is, since we only got started after lunch (the first half of the day was taken up by the Devstack tutorial), and had until 4 pm to go: not much. But we got a little done.

Dana Bauer, Developer and Community Advocate at Rackspace, one of the organizers of the hackathon. She and another Rackspace employee helped us greatly with the registration glitches. At the end she encouraged people to give demos, or, lacking a demo, to stand up and speak about what they did, accomplished, or learned during the hackathon. Though Dana gave people Legos for speaking, very few people (including two from our team) came up to speak. Only one person (Kesten, see below) gave a demo. More pictures from the 2013 OpenStack Hackathon are in my photo gallery.

I am no front-end developer, but nobody else in our team clamored for that role. In a strange coincidence, the other 4 women on our team came either from PyLadies (Python was their language of choice) or from scientific computing background, or the intersection of both. So I assigned the front-end developer role to myself, fully realizing that a web-page hand-coded by me would look rather... homemade. I needed some HTML and CSS templates that would make my creation look at least somewhat professional. Specifically, I needed a web form. I spent a good couple of hours looking for HTML/CSS templates for forms, and most sites were misleading: either they promised free templates, but every template you picked required you to sign up for a fee; some websites promised form templates, but instead of providing the HTML/CSS code they let you create and host a form in their domain, which wasn't what I wanted. After a long search I was able to find a form where I could tease out its HTML/CSS code. Interestingly, throughout my numerous Google searches, Bootstrap didn't show up even once. But when I mentioned my predicament to the people at the hackathon and on Facebook, two of them recommended Bootstrap. Indeed, Bootstrap has form templates. Face-to-face interaction can still be more useful than Google.

The one and only product demo at the hackathon was given by Kesten Broughton, who created a 2D altitude chart as an addon for Google Maps "get directions" service using the Python beta API. His program was called Picycle, and was intended as a service for bicyclists who want to choose an optimal route, either minimizing or maximizing (if they want a good workout) the hills along the route. More pictures from the 2013 OpenStack Hackathon are in my photo gallery.

It took me 3 hours to put together a basic -- extremely basic -- front end to our application. There was no even a question of hooking it up to the backend. There was no time to write even a primitive web service that the front-end could call and display some results. One person in our group, more experienced with Python, finally got Twitter authentication to work in Python. This allowed her to query Twitter API programmatically by making requests from her Python code. Other of our members were just starting out with programming in general (in some cases switching from other professions), so I don't know what they did during that time. Perhaps they were going through Codecademy courses.

To our credit, other teams did not seem to fare better. Only one of the hackathon attendees had even a minimal product at the end to give a demo of, and he admitted he had been working on that product for 2 weeks already. His name was Kesten Broughton, and he created a 2D altitude chart as an addon for Google Maps "get directions" service using the Python beta API. His program was called picycle, and was intended as a service for bicyclists who want to choose an optimal route, either minimizing or maximizing (if they want a good workout) the hills along the route.

The lesson to be learned here is that to participate meaningfully in a hackathon requires quite a bit of preparation. If All Girl Hack Night is going to have a hackathon (I've been threatening to organize one, but always felt woefully unprepared), we would need to prepare in advance. For example, some us will have to be team leads who will have studied the API's of our choice (the APIs will also have to be decided ahead of time), and will be able to guide the teams so they could make tangible progress. That's the main lesson. Lots of advance decisions, planning what to implement, what programming languages and APIs to use, and a critical number of people who are familiar with those technologies and can guide others.

Diversity hiding in plain view, or my thoughts from a SXSW 2013 panel

Conversations about diversity in technology are as interesting for who they include as who they leave out. Their goal should be to challenge the stereotype of a programmer as a young white male, unencumbered with anything that would keep him from coding 18 hours a day. The panelists who got together to discuss diversity in the Austin tech community were not in this category. But diversity is more than just being female or a person of color.

Those categories are, however, the most visible, and no wonder that the conversation revolved around them. There are companies who have been setting examples in how to bring under-represented groups into engineering. One of them is Etsy, the online craft marketplace, where one of the panelists, Garann Means, worked as a software engineer. Etsy noticed that while most of its customers were women, most of its engineers were men, and they set out to change that. Instead of poaching women developers from other companies, they started the Hacker School, and gave scholarships for women learning programming. Many of its women graduates found software engineering jobs. Moderator Mark Phillip noted that when Etsy committed to diversity, it also benefited male developers -- they became better team players.

Mark Phillip (CEO/Founder Are You Watching This?!), Nicole Cofield (president/CEO of Capital City African American Chamber), Garann Means (software developer), and Gerardo Treviño (founder and CEO of Paybook). More pictures from SXSW 2013 are in my photo gallery.

Garann (who is also the founder of All Girl Hack Night, Austin women developers' group) says that diversity efforts are often criticized as "we shouldn't separate women from men, we want to keep them in the same group". But she says that this kind of separation is never an issue, at least in her own experience. Many white guys talked to her about how things that are "supposed" to offend women and people of color, actually offend them as well. It is sometimes said that a special effort to attract more people from underrepresented groups to software industry would bring a lot of underqualified people. But there are examples showing that that doesn't have to happen. Garannn says her friend Divya put together a conference in San Franscisco, with very diverse speakers, and it was technically excellent -- you didn't have to sacrifice the quality.

People categorize themselves in interesting ways that can be different from the categories we assign them to. I saw this play out in my own life as well, and I was reminded of it by what Natalie Cofield, president/CEO of Capital City African American Chamber, said. Many black engineers in tech are not Americans: they come from African countries. She has heard Nigerian programmers say "African American Chamber is not for me, because I'm not African-American. I'm Nigerian." So she saw a need for AAC to be more internationally inclusive. I can relate to this from my own experience. As an international graduate student in America, I felt I was more of a minority here than the officially recognized minorities. They were at home with this country's ways, and I was not. (I know it's a subjective feeling, and a white foreigner still benefits from the white privilege without realizing it, so I would not put my experience on the same footing as that of truly underprivileged minorities.) But when the Natalie Cofield mentioned a need to include foreign-born engineers in the tech community, it was the first time I felt that somebody was inclusive towards immigrants in this country. It was certainly the first time in my experience that somebody wanted to make them a part of the diversity discourse, as opposed to treating them as a job-stealing, wage-depressing nuisance, which is how high-tech immigrants are usually talked about in this country.

Then there is another dimension to diversity, hidden in plain view. It came to my mind when the fourth participant of the panel brought up something, and his story was considered a success story without anyone noticing the darker undertones. Gerardo Treviño was talking about Paybook, his recently launched startup. It lets people take pictures of their receipts, and Paybook will parse them for you. He and most of his developers are from Mexico. At first he wanted to base his company in Austin, but it was very difficult to get USA work visas for the whole development team. Abandoning that plan, they decided that the company's home will be Monterey, Mexico. They wanted a safe place with landscapes that help creativity. So they got the whole team of a dozen developers to live together in Playa de Carmen, an organic food paradise, in a utopian commune of sorts: for example, the whole team collectively decides what to eat for dinner that night.

Mark Phillip (CEO/Founder Are You Watching This?!), Gerardo Treviño (founder and CEO of Paybook), Nicole Cofield (president/CEO of Capital City African American Chamber), and Garann Means (software developer). More pictures from SXSW 2013 are in my photo gallery.

No one in the audience indicated they viewed it as anything but a creative move, and perhaps it was; but such a move would only work for a team of people who have no other responsibilities outside of work. Clearly, someone who has children would hardly be able to leave their family and move somewhere for months at at time. This is especially true about people who have been traditionally responsible for childcare, namely, women. So I wouldn't say that it's really diversity when you pick employees who are free of family obligations. And since they tend to be in their 20s, you are clearly not aiming for age diversity either.

This goes against bringing more women into computing, because women would be the first to quit a company, or entire industry, that makes it hard to combine a job with a family. Even child-free women are less likely to stay in such a company, because they still want to have friends and personal lives. Encouraging your employees to relax on a beach or eat organic food is not a true support of work-life balance; the balance needs to be the kind that lets people fulfill their other responsibilities.

It reminds me of a story I read in our local newspaper, Austin American-Statesman, about tech startups that open offices downtown. They want to be in an attractive location, because their engineers like to to live music clubs or to the lake after work. Clearly, they are trying to attract only a certain kind of engineers, namely, those whose after-work hours are spent on leisure. They are not positioning themselves for another kind of employee who goes home to their family in the evening. It just so happens that the first kind is usually in their 20s, while the other kind is older and more likely to be female. So in the era when sex and age discrimination is illegal, this is a roundabout way to tell the non-20-something-male applicants that they are not particularly wanted here. And I think that as long as companies have implicit preferences for certain kinds of demographics -- expressed by supporting some lifestyles but not others -- I think that all the talk about bringing more diversity into tech won't yield much fruit.

First All Girl Hack Night

My post on the first All Girl Hack Night meetup is now on GeekAustin.org . On 9/28/2010 female programmers of Austin got together to socialize and work on their code projects.

More pictures from the meetup can be found in my photo gallery.