Girl Develop It Logo

I first heard of GirlDevelopIt (GDI) last year and I immediately fill in love with the idea. It’s based in NYC and the goal of the organization is to repair the wide gender gap in software development by helping women learn how to program in a supportive and fun environment.

GDI was started by Sara Chipps and Vanessa Hurst, two women that were tired of being the only female voices in their computer classes. They decided it was time to provide a place where all questions are acceptable and everyone can learn in an encouraging environment. The courses focus on coding, leveraging existing technology, and having something to show for it (aka building sweet websites).

I liked the concept and price-point so much (only $20/class) that I took the Bolt Bus back and forth so I can attend their first HTML/CSS class. I wanted to continue without making the trek up so I inquired about setting up a Chapter in Philadelphia. Fast forward a few months later and I’m excited to announce GirlDevelopIt Philly! In fact, we just posted the schedule and details for our first class that you can find on our Meetup page.

We found a fantastic teacher that you’ll fall in love with right away. Her name is Jenn Lukas and she’s the Interactive Development Director at HappyCog and a leading authority on structural semantic markup and CSS. We also acquired a fantastic space at Two Liberty Place, right in City Hall. A big thanks to Francis Taney and Buchanan Ingersoll & Rooney for providing the beautiful space (I wish you can see the view!).

GirlDevelopIT space for HTML/CSS class

If you’re a woman or man (yes, they are allowed) and have wanted to dabble in HTML/CSS or learn how to code, this is a great time to get started!

When I presented at the first TechGirlz event last year, I made it a point to discuss why we need more women in Technology. There are many reasons and I focused on two. Point #1: Women are vastly underrepresented. Point #2: Diversity is needed to spawn innovation.

What is TechGirlz exactly? A kick-ass local organization founded by Tracey Welson Rossman with the mission of empowering middle-school girls to become future technology leaders.

The goal is to get girls interested in technology from the get-to through hands-on workshops and sessions. Girls learn how to code, build circuit boards, podcasting skills, etc.

When I was asked to be on Board earlier this year, I jumped at the opportunity. I wish there had been an organization like this when I was younger.

All the classes are free and are run by volunteers. Our goal for this year is to reach more girls and run more events. We’re going to hold classes where the girls will learn how to build a website, start a blog, even dabble in game development (I know I’ll be in that class!).

How can YOU get involved? There are various ways to get involved and become part of the movement.

The TechGirlz stand at Whole Foods

  1. Volunteer for one of our upcoming events
  2. Be part of our Marketing Committee and help us get the word out
  3. Send us event ideas
  4. For the month of July, visit the Whole Foods Market in Jenkintown and grab a cup of .25 cent coffee

The last request seems odd so let me explain. The Whole Foods Market in Jenkintown supports a new non-profit every month by selling hot, fresh coffee for only a quarter. 100% of the money raised during the month of July goes to TechGirlz.  Stop by, hold your next coffee meeting there or swing through during lunch.

For more information leave a comment or contact us at info@techgirlz.org.

Thanks in advance for your support!

This is the first of a series of blog posts of lessons I’ve learned as a non-technical person. These are not in chronological order. This topic was brought up recently so I decided to post about it first.

This was my initial idea of a bug “report” : “Hey John – I’m getting a 404 error on this link.” “To Mint.com – This part isn’t doing what it’s supposed to do.” Notice I put the word “report” in quotes. That’s because it wasn’t a report. I would literally send an email with a one liner saying what didn’t work.

Submit a bug report or you'll go to hellPhoto Credit: http://www.zope.org/Members/ajung/PloneCollectorNG

I’m picturing developers everywhere shaking their shakes as they’re reading this. Don’t worry, I caught on to the right way quickly.

According to a good friend and a great developer that I’ve had the pleasure of working with, Owen Winkler, there are three components to a successful bug report that he blogged about here. To summarize, they include:

  1. Discussing what went wrong.
  2. Noting what you did before the bug occurred.
  3. Including what you thought was going to happen.

Make it easy for the Company/developer and include as much detail as possible while breaking down each category. Here’s a great example of a bug report submitted to GoDaddy:

What went wrong – When I went to check out, a pop-up full of offers appeared and I was not directed to the payment page.

What I did – I added a domain I wanted to buy to the shopping cart. When I clicked on Continue to Registration, a pop-up appeared telling me to stop and buy additional domains. I clicked “No Thank”s and another pop-up asked me if I wanted to purchase domain protection. Again, I clicked “No Thanks”. This time, I was directed to a page that displayed email options. Bypassing it directed me to a variety of hosting options. I was then presented with a page asking me to donate money for the server costs of displaying the upselling opportunities they provided at my convenience. Seeing no end in sight, I gave up.

What I thought was going to happen – When I selected the domain I wanted to acquire and hit checkout, I expected to be taken to the payment page where I would enter my credit card information to complete the purchase.

Okay, okay. I’m being facetious at GoDaddy’s expense (can you tell I’m not a fan?) but you get the idea. When you submit a report to a service or work with a developer, you want to provide the courtesy of completing these steps to streamline the Quality Assurance process.

Finally, you should include screenshots of the error if applicable. A lot of tools don’t include the URL field by default. If you’re talking about a particular page, drag the selected area so it’s in there as well.

*Bonus* – When submitting a bug, only include one per report. I’ve been guilty of adding a few at one time. Don’t do that. A kitten is also killed at your expense.