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.

Making sense of criteria for making sense of Javascript frameworks

How do you select the right parts from a talk about how to select the right technology? Especially if you haven't spent a whole lot of time working with any of the development tools that are being compared? Perhaps you just listen to what resonates. And so I did at the All Girl Hack Night presentation on how to select a Javascript framework that's right for you, by Justin Lowery from Cerebral Ideas. Justin compared Angular JS, his team's favorite, with two other popular Javascript frameworks, Backbone and Ember. So while an experienced web developer might be nodding their head sagely at the criteria Justin gave (which I put at the bottom of the page), I just pondered how web development today is still oddly plagued by the same problems as when I did it in 1999.

When you just can't separate presentation from business layer...

Justin Lowery (the presenter).

Back in 1999, when we wrote cutting edge web applications with (ahem) CGI and Perl, separating business logic from presentation seemed a distant dream, which my team at the time quickly gave up on. We wrote spagetti code where HTML was generated in a deeply nested tangle of Perl's ifs and fors. It's 2013, and it sounds like HTML still can't be made completely independent of business logic. And some people say you might as well embrace that, and pick a Javascript framework that lets you hook up Javascript to backend-generated HTML easily. According to Justin, that's one of big advantages of AngularJS.

Those Javascript-hating backend developers

This will let backend developers generate chunks HTML without ever touching Javascript. In Justin's observation, backend developers hate Javascript, but are much more friendly with HTML. Why they hate Javascript more than HTML is anyone's guess. Perhaps it's because backend developers are used to "proper" object-oriented languages, whereas Javascript kind of has objects without actually being object-oriented. It has this strange prototype inheritance, which is not like the "classical" inheritance that backend developers are used to. But I have been a backend developer for a long time, and I'm not averse to Javascript: I've been learning it eagerly in recent months, and I'm fascinated by some of its features like closures.

Freeform HTML versus generating the whole page from Javascript

Then again, there exist Javascript frameworks that not just let, but force you separate presentation from business logic; it's another question if those solutions cause bigger problems than they solve. I am talking specifically about ExtJS. ExtJS expects all the data from the backend to be returned as JSON objects via service calls. I'm not sure you could make it accept custom HTML even if you tried. At least that would be very hard, and it would violate another of framework selection commandments: "Choose a framework designed by someone who thinks like you, otherwise you'd be fighting it all the way". It would be hard to stick any custom HTML into an ExtJS application, because ExtJS does not "hook" into your existing HTML: it generates it all from scratch, from Javascript alone. Some pople don't like that. I suspect our presenter didn't either, because he considers it an advantage if a framework lets you write free-form HTML, like Angular does.

This ties into our next criterion.

Page load time: the "no blank page" criterion

Left to right: All Girl Hack Night members Annine, Yim, Angelina, and Kate at the Angular JS presentation.

Allowing static HTML versus generating it all from Javascript is tied to another criterion: how fast the framework is. Mainly it means page loading time. Justin observed that a perception of loading time is not the same as the loading time itself. This criterion can also be summed up as "No blank page prior to JS parsing". If your application renders some HTML elements before it executes all the Javascript and populates fields with data, some HTML elements are already on the page even though some fields are initially blank. Even if loading the data into those fields takes 2 seconds, the user will still perceive this page as loading faster than a page that stays blank until it generates all the content, though that might take 1 second. In this case Angular obeys "no blank page" rule, whereas ExtJS -- you guessed it -- doesn't.

Opinionatedness: what does it mean?

The most mysterious criterion is probably "opinionatedness" of the framework. Perhaps you have to be an experienced front end developer to fully understand this concept, and I'm not. A Google search did not give me a crystal-clear understanding of what it means. Apparently, opinionated APIs are on the opposite end of a "scale" than REST APIs. Unlike REST, opinionated APIs don't treat URLs as resources. They are more like function calls that URLs: save(collection, key, value) versus http:///collection/{collection}/variable/{key} (this example is from an article Opinionated (RPC) APIs vs RESTful APIs). But from what I read, experts seemed to think that REST APIs are more intuitive than opinionated ones.

Clockwise from the left: Bridget, Patty, Ashley, Maryam, Simi, an IT guy from the company that hosts All Girl Hack Night; Justin Lowery (the presenter), Neelima, unidentified woman, Annine, and Yim.

Opinionatedness of the framework figures into its learning curve. Justin said that Angular JS becomes harder to learn as the API becomes less opinionated. This seemed counterintuitive to me. Why would it be harder to program using RESTful API than one that consists of commands? Googling more about it, I found that AngularJS is called opinionated because it forces you to give your application a certain structure. If so, that can influence the learning curve in two ways.

Again, let's take ExtJS as an example. If you are writing an application that resembles the "Hello World" tutorial, it's easy to use this framework. You follow the steps, and the widgets on the page magically materialize and get populated by the data from the backend. So the learning curve does not seem too steep. But then you find out that a real-world application does not match the confines of the tutorial, and its logic often does not conform to the structure the framework imposes on you. That's when the learning curve becomes steep, as you have to find various backdoors and workarounds around the framework's assumptions. From that perspective, I'd say ExtJS is very opinionated, and this can make it hard to write real-world applications. This framework gives you prefabricated houses instead of individual bricks. But if it gave you just the bricks, a beginner wouldn't know how to stack them into an architecturally sound house.

A meta lesson is that it may be hard to know what concepts are and are not too vague for an overview talk (assuming that overview talks are introductory in nature). All Girl Hack Night has developers from all walks of life, from device driver writers to front-end, and I don't know that many non-front-end developers are familiar with the concept of opinionatedness. I will have to keep that in mind when creating my own presentations.

What kind of philosophy / methodology does the framework use to solve problems?

• How is it architected?
• Is the framework authoritarian or egalitarian?
• Are all problems solved with Javascript?
• Are problems solved with a bigger, more aggressive API?

How does the framework solve common problems of development?

• Templating?
• Data binding?
• Routing?
• Bootstrapping?
• Data management?

How active are the creators in the community?

• Do they have an active forum with many users?
• Do they have stale pull requests or issues list?
• Are they active in the community?

HTML-centric philosophy

• HTML is intuitive for those that are non-Javascripters.
• Strong separation of concerns.
• Event binding is much easier.
• Backend devs that hate JS have limited exposure to it.
• Views are compatible with other frameworks, especially backend technologies.

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.