Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

Invite the non-coder to your events!

Or: Why coding isn’t the only thing you need to teach

“A group of people brainstorming over a laptop and sheets of paper” by Štefan Štefančík on Unsplash

What do the following have in common?
Code Camp
Hackathon
Code Week
• Hour of Code
• freeCodeCamp
• Oracle Code
• Women Who Code
• Girl Develop It
They are all free or low cost. Most of them give back by encouraging app and site building for non-profits. But there is something more basic that they all have in common:

They are all code based events.

By their very names, they exist to teach people to code. They focus on coding basics, data access through code, code to build the interface, code to show results, etc.

But code is only one part of any software project.

It doesn’t matter what version of the lifecycle you are using to build your app or site. The stages of your product don’t change. Before you code, you plan. Before you code, you design the interface and the flow of the process(es) being supported. While you code, you should also be testing and building documentation. After you code, you should be preparing for customer support and monetization issues. If your project is complicated enough, you will want some kind of user training.

That’s where geeks like me come in. I can code, but I don’t. I don’t like the stress that comes with writing code. It’s harder for me than any other part of the software lifecycle. Testing, for me is easy. Breakages in your products become visible as soon as I start working with it. For other people, the non-coding parts of your project have experts like me available.

But if all we teach those new to our industry is code, we do a disservice to them. If we don’t teach a new developer how to plan for the app/website, we end up with code that won’t make sense to anyone else. Code that will be harder to use and maintain. Code that won’t get used as much as it should. If we don’t teach people how to actually draw out the planned interfaces, the paths through the app are likely to only make sense to coders. If we don’t teach how to document, how to train users, how to do support — the problems get worse. We get projects no one who isn’t a techie will ever use.

We see this all the time in the real world. Look at some of the biggest applications you use. Do you use it because you like using it or do you use it because it is the only app that does what you want it to do? Think about the last website that made you nuts when you were trying to find something on it. Think about all the sites that are aimed at people over 50 which use interfaces that don’t seem to realize that the older you get, the worse your eyes get.

What can we do?

The first thing: Stop only teaching code. When you start an event for those new to the world of code, invite people who do the non-coding part of the process as well as expert coders. If your talent lies in the non-coding world, volunteer to support the creation of the work items related to your particular part of the software lifecycle.

This isn’t a theoretical issue. I have tried to be a testing mentor at a few different events. Unfortunately, because testing wasn’t integrated into the events, few people understood why I was there or what someone like me could do for them and their project. Instead, the organizers talked about code and code alone. Even interactions with the clients were barely touched on.

Take it from me — You will get amazing results when you add the rest of the software process back into learning how to create software, apps, and websites