Survival Guide for Learning Software Development (When You Don’t Feel Like a Developer)

Given the number of bootcamps in the programming education landscape, there are likely to be a few more people coming to this field without a computer science background, or even the traditional developer temperament. I’ve met film buffs who wanted to learn programming to be able to edit and add effects to their films, designers who wanted to use algorithms to generate unique shapes, office workers who wanted to level up their spreadsheet skills. Coming from a background in industrial design and craft, programming is very different from most of the other subjects I’ve previously tried to learn.

It’s possible to feel pretty alone while learning a new discipline, particularly when coming from a different background.  It can feel like everyone is moving at a different speed, speaking a different language, using a whole different outlook.  You reach for familiar tools, only to find they’re not there.  The tools that are there are maybe not intuitive to you.  It can be difficult to even ask for help when you don’t have the sense of a shared language; it can be like asking a native Spanish speaker what “corazon” means, and having them give you a cardiology lecture in Spanish. I’ve spent a long time trying to pummel myself into being the “right” kind of thinker for this work, and after looking at the results, am trying a different approach. I’m hoping that others who are going through a similar adjustment might find some aspects of this approach helpful.

Give yourself permission not to feel like your knowledge is supposed to expand like cosmic inflation.

If a man does not keep pace with his companions, perhaps it is because he hears a different drummer. Let him step to the music which he hears, however measured or far away. – Thoreau

There are days where it might feel like everyone around you is going from white belt to black belt before your eyes.  There are days where it may seem like everyone else’s language and framework dance card is infinitely fuller than your own.  And seeing other people’s progress can make it seem like that’s how your specific progress is supposed to be (other people may help to reinforce this impression, but that’s another matter).  When I started my apprenticeship at DevMynd, I’d come away from a bootcamp where I learned a lot of stuff, really quickly.  From there, I figured that I’d get comfortable in the language I’d just learned (Objective-C, at the time), then likewise learn Ruby, then Rails, then Javascript, then some frameworks, then maybe something like Elixir or Go or Clojure or maybe really cool animation, then circle back to the kind of design work that made me want to learn programming in the first place, all at the same pace as bootcamp. It didn’t work like that at all.

The more I paired with experienced developers in a variety of languages, the less sure of my own understanding I became.  I started winding my way backwards down the reading list.  Instead of reading more complicated or higher level books, I traced my way back through simpler and smaller ones, and practiced classic code challenges.  I found myself reaching backward for a more solid footing so that I could “catch up” to where everyone else seemed to confidently sit.  And I felt really ashamed about it.  My inner voice would sneer, “You’re supposed to be going forward, but you’re reading the same kind of books you read in the first month.” But one night, er, early morning, I realized that stepping backwards to confirm fundamentals was a big part of my learning in everything from softball to figure drawing to trademark law. Leaning on fundamentals is something that is at the root of my learning style.

You might not need to revisit basics, maybe your learning style requires something different. My point is merely that when surrounded by folks whose learning style matches the default one, it can be hard to give yourself the space and the time you might need.  I try now to remember that everything I learn in this field is learning two things at once: the content and the way it’s taught.  And I try to deal with the drag that it puts on the process.

Your pace may not be as slow as mine, but it might not be as fast as the person next to you.  You might change pace as you slide across the spectrum from interfaces to databases to devOps.  Of course, you want to feel progress, but the judgement is a little extra.  There’s even research that suggests that in an academic setting, students perform better following a failure when they learned to be kind to themselves about it.  The judgement just gets in the way.  Consider how you would treat someone else who’s struggling, and treat yourself the same way. Let yourself move in your own time.

To love the plateau is to love the eternal now, to enjoy the inevitable spurts of progress and the fruits of accomplishment, then serenely to accept the new plateau that waits just beyond them. To love the plateau is to love what is most essential and enduring in your life.  – George Leonard

Work with what’s actually there.

Lean into the sharp points and fully experience them. The essence of bravery is being without self-deception. Wisdom is inherent in (understanding) emotions. — Pema Chodron

I spent way, way too much time looking for resources that resembled the ones I leaned on in other fields. Legal documents have a really nice system for defining potentially unfamiliar or ambiguous terms.  The type of writing that I encountered throughout years of lovely humanities classes had an argumentative structure that changed pace and tone in a way that let you know, “this part, here, it’s important,” and when presenting abstractions, employed metaphors to familiarize ideas.  In woodworking, I had a very organized teacher, who set the classes and shop time up in a considered, sequential and opinionated way.  Some people may look for opportunities to solve problems as a group, others may require a certain kind of experimentation.  By all means, sweep the landscape for materials that suit your default learning preferences, but if nothing turns up… there’s a good chance it just might not be there.  And you have to work with what is.

You don’t have to love the way things are taught, but you can manage it. What’s been helping lately, is to imagine a person that could teach me how I want to be taught, then treat myself like that.  For example, think of that teacher that really spoke to you, a parent with extra patience, or a coach who knew how to get the best out of you.  Think, specifically, of what they brought to the table… then set the table yourself. Here are a few examples of my attempts at this.

Terms of Art.

Industry specific terms are necessary, of course, but I find that in development, there’s not the same kind of emphasis on clarification or definition of terms that there was in law. I can’t count the number of times where someone has thrown around a term, the wikipedia page was a living nightmare of blue links, and then one day someone summed up the term in plain language – like, in three simple words.  I’m trying to get better about writing the “that’s it?” definitions down, and plan to gather them up into a personal glossary.  I recently talked to someone who wanted a plain-language translation for error messages; that’s a perfect candidate for DIY teaching assistance.  

Writing Style.

The Head First series of books has a really nice breakdown of how and why they developed their writing style, (“So how DO you get your brain to think Design Patterns are as important as a tiger?”).  Using images, telling stories, creating juxtapositions that engage feelings, and other great little lessons gleaned from studies on how humans learn best, are all folded into their books. However, I think of their style as a remarkable exception (and their books are for Java ?). Most of my other books and the blog posts and documentation I encounter are pretty tiger-less: straight descriptions with code snippets.  Now, as I go through new materials, I’m working to take notes I can use, draw more diagrams, cook up my own metaphors. It’s not something I can do all the time, but when I have time to review things on my own, it does seem to help.

Choosing a Path.

There is a real love of bootstrapping when it comes to learning development, and it speaks to a lot of people, but it overwhelms me. Once when I was little, I was asked to clean my room and I just sat in the center of the mess for hours because I didn’t know where to start.  My mom prodded me into moving one thing, and it unlocked a whirlwind of cleaning.  Programming, is that messy room: there are so many paths you could take, so many approaches within each path, that I could sit in the center of it forever. I miss my woodworking teacher’s one true path. I miss having even a basic syllabus, like you’d get in a classroom environment. So, I’ve been thinking about how to create my own. It always seems like there’s a big gap between the simplicity of the friendly, getting-to-know-you, introduction to a language (“look, it’s a string!”), and the complexity of the frameworks that you might use to render that string somewhere.  I’ve been working on a measured way to pull myself through that gap.  For me, I tend to think about things from the outside (views, etc.) and then work toward the inside, so that’s the approach I’m hoping to take.

Be social, even when you’re finding your own way.

As I mentioned above, sometimes I can get pretty ashamed about my learning progress, which can make it trickier to talk about with other people.  For some folks, this might not be a problem at all, it may be easier to find fellow travelers, digging in at hackathons or posting their progress to the world.  For some of us, it might just be a side comment at a party, or retweeting something that sounds familiar. It’s really helpful to connect with other people, for so many reasons. Sometimes, they can offer you what you’re missing or suggest an approach, and other times, someone might say something that is so foreign to your own experience that you have a breakthrough (“This framework makes sense to you, and you have conspiracy theories about kale? Somehow, huh, that makes sense.”).  Most of the time, it’s just good to remember that everyone has rough stretches, and that it’s okay for you to have them, too.

Everything in this post is still a work in progress, both in terms of the tooling (the actual glossaries and syllabi) and the habit of trying to be patient throughout the process.  Hopefully, this might be useful or encouraging to others just striking out on this path.  Otherwise… I have some intel to pass along about Big Kale.

DevMynd is innovation firm in Chicago and San Francisco with practice areas in custom software development, mobile and web application development.

Erin is a member of DevMynd’s software engineering team focusing on mobile apps and web development. She has been with the company since 2013.