Hi, everyone!  It’s been four months since I last wrote about my journey to code.  In some ways, lots of things have happened.  I took a look at my goals in December, and on paper I’ve accomplished all I set out to–with the exception of starting to explore JavaScript.  Still, I feel like I could be a lot further.  While I’ve checked a lot of boxes over the past four months, I don’t feel I have put in enough time doing actual coding and project work, including problem-solving.  However, I have indeed been active during the past few months.  Below I will share some accomplishments, goals, and my thoughts on coding education geared towards women.

Since the start of the year I have mostly dabbled in lots of different areas, taking a great introductory classes on various programming languages.  I’ve taken workshops on Sass, Python, and Ruby.  I took an awesome two-day class on using Python in the lab facilitated by Software Carpentry for the New York Academy of Science.  I have also taken as many Girl Develop It courses as possible.  Both SC and GDI offer paid courses that are reasonably-priced and generally span anywhere between 3 hours to 2 days.  I tried out paid courses elsewhere, free lectures, and problem-solving meetups where attendees work through algorithmic problems.  While the problem-solving meetups are definitely fun and I have been to at least one lecture that completely blew my mind, I’ve gotten the most out of the GDI workshops by far.

If you don’t know GDI, here’s a bit about them:

Girl Develop It is a nonprofit organization that exists to provide affordable and judgment-free opportunities for women interested in learning web and software development. Through in-person classes and community support, Girl Develop It helps women of diverse backgrounds achieve their technology goals and build confidence in their careers and their every day lives.

Affordable and judgement-free are the key points for me.  Part of the reason why I’ve stuck with the GDI workshops is definitely financial.  If I pay for a class, I’m way more likely to attend even if I’m not feeling the ~1 hr rush hour commute from the Bronx down into Manhattan.  Compared to other coding classes, GDI classes are extremely affordable in terms of actual cost and the quality of the lectures themselves.  The idea of being judgement-free is a little more difficult to pin down and hard to define.  After being to a few GDI workshops, my feeling of what makes a workshop “judgement-free” is that it is a totally safe space for questions, peer learning, peer support, and mentoring.  This was most evident in an intermediate Python workshop I attended last week.  The class was full of women who were working as developers or had been self-teaching long enough to identify as developers.  The instructor was self-taught and passionate about her topic.  The class had questions and discussion with attendees and facilitators alike sharing advice and experiences.

I work in a profession that is largely dominated by women, and so learning to code in an environment geared towards women does feel very comfortable for me.  I am not at all opposed to working with men or learning with men, but the feeling between the GDI workshops and workshops dominated by men is very different.  At mixed or male-dominated workshops, I haven’t found the same degree of comfort from attendees.  At other workshops I have noticed people get stuck on exercises, but they don’t always ask for help.  At GDI, more people ask for help and more people offer help.  Of course, I know that different developer communities are all unique, and so my very limited experience is just that–my experience.  On the other side of this coin, the CSS Layout Club NYC meetup is a very mixed group of people (age, gender, race) and it’s a fantastic group.  This prompts another thought.  Maybe developer communities get more friendly and awesome once you penetrate the “intro” surface and get into the true meat of a language or tool.  Maybe gender has nothing to do with it, or less than I think.  In any event, I have completed TA training with GDI and am hoping to be able to volunteer with the organization in the upcoming months.

So, as you can tell from my summarizing the last four months, gender has been on my mind a lot.  Along with that, I’ve been thinking a lot about my professional identity, both as a librarian and as a developer.  When I first started learning to code I had an idea that at some point I might become more developer than librarian, but that’s not at all what has happened.  What has actually happened is that I have developed the vocabulary and understanding to talk with people who are interested in the nerdy things I love, (information architecture! ontology! open information resources!), but who have completely different backgrounds and training than I do.  Learning to code has actually made me love being a librarian in a way that I haven’t for a while.  It’s made me see connections within my field and outside of it, and allowed for me to build my network and contribute to some cool projects.  I have connected with some existing projects as a citizen scientist, such as data rescue to harvest and preserve governmental data and georeferencing to develop climate change and conservation data, but I know it’s time to start noodling on my own and making things.

I think that this post is different from my other two because I’ve been working through different problems over the past four months than I did during my first three.  I’m comfortable enough with the logic of programming languages that the idea of learning new languages or developing my skills in languages where I have basic training doesn’t intimidate me as it once did.  What’s intimidating me now is the thought of developing my own projects to prove my mettle.  Intro classes are easy, but creating projects, debugging code and troubleshooting problems are an entirely different arena.

About a year and a half ago I decided that if in the future I wanted to be competitive for an academic, tenure-track job as a librarian, I needed to start writing in order to prove my work ethic.  For a while, I went around asking people how I could collaborate with others on existing projects.  I thought that was the best way to get my foot in the door.  For better or for worse, I learned that actually the best way for me to find collaborative opportunities was to start producing on my own.  It took a while, but now I have offers for collaborative writing projects.  I think that the same principle is probably true for programming.  I want to insert myself into existing projects with the thought that of course I’ll offer something to the project, but I haven’t yet proven myself.  It’s hard to start to work on a project in a vacuum, feeling unsure if what you’re dong is worthwhile or will be interesting to anyone else.  However, the first step is to start.  The second step is to stick with it.  And the third step, hopefully, is to find a friend, peer or colleague who is excited to build something with you.  Stepping back from the more emotional side of this post, my practical plan is to begin focusing on the Python programming language because there is a very active local community, including three days per week of scheduled office hours/tutoring help for me to take advantage of.  I’ve begun to experiment with the data from the USDA plants database, and have already run into problems.  An exciting sign of things to come, I expect!

After seven months of developing what I think is a pretty good, (but by no means exhaustive), foundation of knowledge about programming, it’s time to take changes, get messy, make mistakes, and build.

Wish me luck!