Letters to a Young Developer, pt. 1

26 Mar 2015

I love programming, I really do. I like making stuff work, I like when I finally wrap my head around a concept, I really like rubber-ducking with people. Since I love it so much, I can get pretty excited when someone tells me they’re learning to program. And I get even more excited when they ask me for advice. Vainly, it makes me feel good that someone thinks I know enough that they might want to take my advice.

Often people ask “What do you wish you had known when you were #{insert stage/job/etc here}?” So this is “Letters to a Young Developer”. The series of blog posts and advice I wish I’d come into when I was first #{insert stage/job/etc here}.

What Should I Learn Next?

“What should I learn next?” This was the question I asked once I’d finished a few of the recommended tutorials for new Ruby/Rails developers. At that time I was thinking I needed to practice certain techniques, learn how to implement certain features. For a long time when people asked me what they should learn next I would rattle off a laundry list of my favorite tutorials and guides. I assured them (as I had been assured myself not so many months before) that picking up another programming language was easy after the first one or two.

What I didn’t think about though, was why it was easier to pick up another language after you had already learned one. I had the benefit of having a little bit of experience on my side, so I was familiar with the concept of debugging. What I didn’t realize that what I was missing was understanding how to effectively debug in Ruby.

As I get more opportunities to work with other beginners, the difficulties of really learning and understanding a first language become much clearer to me. Even across different learning types, it seems like beginners’ struggles circle around a few themes:

recognizing patterns
understanding syntax
figuring out what went wrong

The first two, I think can be learned through writing code and reading. The last one is a little trickier. Sure, if you know a lot about design you can probably reason your way through what you think went wrong. But even with tests in place, sometimes your best guess is just that, a guess.

What I Wish I Knew

What I wanted to learn when I was asking “What should I learn next?”, was really “How can I learn what’s really going on?”. My problem was I could implement the same things I had implemented before but I was nervous about implementing new things as I wasn’t sure how to do them without a guide. Because at the end of the day, when you understand the language you can really learn how to implement almost any feature.

Think about when you work with someone (or when you worked on things) and something goes wrong they(or you) say “That keeps happening & I don’t know why”. They’ve tried this several times before and gotten the same error but the error doesn’t mean anything to them because they don’t know how to read it. This was me when I was first starting to write applications outside of the safety and guidance of tutorials. I knew something was wrong but I didn’t know how to troubleshoot it.

Learning to Troubleshoot

The advice I’d give young Kylie (just a year & a half ago) would be learn how to troubleshoot. The very first thing I’d recommend to learn how to do this would be watching Blithe Rocher’s Scientific Method of Troubleshooting. Developers seem to value methodical approaches to problem solving, so this is the perfect marriage of development and learning. For other new Ruby developers I’d recommend Jonathan Wallace’s Effective Debugging in Ruby and this presentation by Melissa Holmes on Pry for Ruby. Learning how to debug effectively can make the difference between feeling like you’re floundering and being able to move on quickly from mistakes. I know for me at least, being able to debug on my own has helped a ton. One, because you’re able to power through problems and figure out what’s really going down. Two, because of the great confidence boost that comes from finding a problem in code and fixing it yourself.