I’m starting up a new open source software project and thinking of structuring it like an ongoing free seminar on how to be a great software engineer. I’ve seen a similar structure work really well in the Hydra Project and now I want to do it again. I think it might be a potent way to help a broader range of people to become empowered, successful, satisfied software developers.

In Spring of 2014 I ran a RailsBridge workshop as part of the Libraries Technology and Gender Summit in Austin, Texas. Almost all of the participants were women who have jobs at libraries around the country. Many of them had technical roles at their libraries but did not work as software developers. Most of them were interested in transitioning into software development roles. At the end of the workshop we had a lengthy discussion about “what next”. If you want to be employed as a software developer the first step is to learn how to code but then you need to get real experience. This creates a Catch 22 – in order to get onto a software development team you need experience, but in order to get experience you need to get onto a team.

Training experiences like a RailsBridge workshop are great, but when you walk out of that workshop you face a different set of barriers.

One woman told us about the dilemma her boss faces – should he give assignments to the two experienced software developers (both men) or should he go out on a limb and give those assignments to a young librarian whose only coding experience was a weekend training and a couple of online tutorials. Her boss was always under pressure to turn around work really quickly so he kept giving the assignments to the experienced developers. She understood her boss’s decision, but she wanted to get “software development” into her job description so she could build those skills in earnest. What was she to do?

Heads nodded around the room in response to this woman’s account. Training experiences like a RailsBridge workshop are great, but when you walk out of that workshop you face a different set of barriers.

One common suggestion for getting experience and establishing a portfolio as a coder is to contribute to open source projects. In theory that’s a great idea — most open source projects are willing to accept pull requests from newcomers. In practice, contributing to an open source project can be an intimidating or outright hostile experience and it takes a lot of up-front communication to work on really juicy features that will look good on a resume.

In practice, self-taught engineers, myself included, and fresh CS graduates have often found their way onto the meritocracy ladder by practicing the age-old art of “fake it til you make it”. Whether it’s by bluffing their way through a job interview or submitting pull requests to a stranger’s github project, they get past their lack of experience by relying on pure chutzpah. This approach favors people who are bold and brash, who have less to lose, and who have been encouraged to take risks. It also falls back on the existing biases of the surrounding culture — I’m more likely to trust you if you look like me, talk like me, and write code like me. As a result, it’s biased against women, people of color, people who have families to support and people whose cultural background feels foreign to the average geek.

What’s the alternative? I propose that it’s not enough to teach people how to write code. We have to teach them how to be great coders. I think that will make a real difference, and I have an idea about how to do it.

In some contexts, meritocracy really does rule among software developers.

Employers don’t just want to hire developers, they want to hire good developers. Open source projects don’t want more Pull Requests, they want good contributors. In some contexts, meritocracy really does rule among software developers. In some places, working code wins and Pull Requests are welcome as long as your tests pass and your code is commented properly.

There are objective, teachable ways to become a great engineer, and the best way to learn those skills is to practice them in a community of peers.

Working in an environment of mutual assistance and mutual respect is incredibly empowering.

A prominent part of my role at MediaShelf was to run HydraCamp workshops. These events, which range from 4 hours to 4 days in length, are focused on teaching software developers how to contribute code to the many components and applications under the Hydra Project’s umbrella. The formal content of the workshops was focused on learning how to use specific technologies like Ruby on Rails, ActiveFedora and Blacklight but the built-in learning goals were focused on the important nitty gritty of contributing and collaborating. We practiced writing different kinds of tests for your code, we practiced submitting pull requests and commenting on them, we talked through the process of planning features and, most importantly, we practiced asking for help.

I think that teaching people how to participate in the collaborative process has made them better, more productive engineers. It has also helped to make Hydra a distinctively positive, supportive, robust and dynamic open source project.

Working in an environment of mutual assistance and mutual respect is incredibly empowering. I helped to create and sustain an environment like that in the Hydra Project and I learned countless things from my peers along the way. Now I want to do it again and this time I want to document the process so others can crib notes and try their own approaches.

I’m interested in gathering a team to contribute a new module to the Dat project. This new module will be immediately interesting to a global community of software engineers and data-wielding researchers. I could write the module myself, or I could hire experienced freelancers to write it, but I propose a different approach. I propose gathering a team of software developers who want to “up their game” and bolster their resumes by designing, building and maintaining this module together with me. Together, we’ll cover all of the stuff that makes great teams of engineers. We’ll work on designing features, managing work with agile process, writing unit tests and integration tests, using Continuous Integration, submitting pull requests, doing code reviews, and documenting code. Surrounding all of this, most importantly, we will practice creating and holding a culture of mutual assistance and mutual respect.

It might make sense to approach this as a long free seminar with weekly installments.

Along the way, in addition to learning the skills of collaborative software development, participants will also hone their skills with NodeJS and get exposure to the cutting edge of technologies that will define the next generation of the world wide web such as blockchains and the new breed of wire protocols inspired by bit torrent. They will also get exposure to topics related to data science, open data, and reproducibility of research. We will tackle those topics together, pulling them apart in a safe, unassuming, respectful environment. We’ll also be able to tap some of the brightest engineers in the industry for answers when we have questions.

In an ideal world, I would like to build this team locally in Philadelphia, my new home. If we’re all in the same city we can meet face to face, which makes a big difference. I would like to draw heavily from the communities of people who have received training from projects like Girl Develop It.  I hear there’s an active chapter in Philly. I don’t know if this is reasonable, or even possible, but it seems worth trying.

If you would like to follow along or join the project, there is a project page on the Code For Philly website. The current working name for the project is “Dat Tables”.