Lessons learned in Dev/Iowa 2015

Last week Dev/Iowa, the nine-week programming course I was part of this summer, wrapped up. Instructor Steve Davis gave a presentation on the program at 1 Million Cups (see that below for an overview of how the course worked) and we pushed our projects live online, ready or not.

It was a small class, with just three students, but focusing on individual projects let us get a lot done in a short amount of time.

I’m not about to become a full-time programmer any time soon, but the class definitely gave me more confidence when dealing with all things tech, and in the future I’ll at least know where to look for answers and helpful starting points.

After nine weeks, my project is definitely not done (my infographic is a bit of a mess), and hopefully my learning isn’t either. That said, here are some of the biggest things I’ll try to remember from this summer:

Dive into the deep end

My earlier forays into learning to code were all online, using some of the many free tools available. I’d dutifully start each time at the beginning of an HTML course, believing the way to learn was to master each thing before moving on to the next (HTML before CSS, CSS before JavaScript). I’d also frequently lose interest and abandon learning for a few months.

In Dev/Iowa, there was no time for that. Most weeks had a theme – say, version control with Git, writing to a file, or structuring a database – but we hardly went in-depth. For each new skill, we learned the basics, tried implementing it into our projects, asked for help where we needed it, and moved on.

This doing-focused approach let us cover a lot of bases quickly. I can’t say I know everything about databases now (or even most things) but I can say I’ve built one and it works.

So…not quite a D3 masterpiece. Yet.

Even within the context of this quick pace, there were forks in the road where I could choose an easier or harder path. For my data visualization, I was interested in using D3.js, which organizations like the New York Times use to make super-slick infographics and interactive stories. Several people – some who know D3, some who don’t – told me this would be too hard for a beginner and suggested alternatives.

Ultimately, I chose the harder tool, and I’m proud that I did. In addition to the feeling of accomplishment, the challenge kept me interested. I don’t know if I would have been as motivated to keep programming, styling and debugging a simple pie chart.

This might be the biggest lesson I learned – to have the confidence to dive into a new tool or skill head first, instead of trying to test the waters.

Don’t be afraid to delete

Additions and deletions to my project

Additions and deletions to my project

As our projects evolved, tossing out earlier work was just as important as adding new code.

Case in point: The sliding menu I was so proud of in week two, after spending hours and hours with it? Totally gone by week four. And that’s a good thing.

But while the execution changed often, the core idea of each project had to be solid from week to week or else we would quickly become lost.

In fact, one valuable lesson we learned was to talk through a feature and write it out on a whiteboard before starting to write code.

A systematic approach to problem solving

One of the most frustrating parts of learning to code, for me, was trying to figure out what was wrong when something didn’t work as expected. Some tools and programs give helpful error statements that tell you where to look for the problem, while some are frustratingly silent.

While I’m still not a pro at debugging, Davis got us in the habit of trying several steps to identify and remove problematic code.

Usually the first step was to back up and evaluate our own assumptions – some of the most perplexing problems came when we had jumped to a conclusion. (Say, assuming I could feed a function a word or phrase, where it expected a group of numbers; this could be found with a simple console.log statement).

This has got me thinking about how to take a more systematic, step-by-step approach to dealing with non-technical issues as well.

It takes a community

Thanks to everyone who asked if my project is online yet (kind of!) or asked me how it was going. Thanks to the mentors, experienced techies, who took time to sit down with three new students and help us work through whatever issue we were grappling with that day. Many thanks to Davis for tirelessly keeping us engaged on nights and weekends and to UI Partners for keeping the program going even when unexpected changes happened.

All of these things made a big difference.

See you on Github!