Aaron K. Redshaw

Learning the hard stuff

The thing about getting into technical writing, is that most employers care more about your technical mastery than they do your writing ability. For that reason, one of the best ways to show your value is to prove your technical skills. The list of what you can learn is just about infinite, and choosing what will impress employers can be difficult. (See my spreadsheet if you are looking for how to narrow this down.)

Recently, I heard about Google’s Certificates (see my post on this), and decided that completing this course might really boost my current job value, as well as open up future possibilities. Since my employer, Amazon, is really supportive of this, I am currently working through the Associate Android Developer Certification course, also called Android Basics in Kotlin for some reason. 

My goal here is to give you some thoughts on my learning journey, and how I approach learning difficult technical subjects in general. First of all, learning is hard. I don’t mean it can’t be fun, but learning something like a programming language can be difficult. My rule of thumb is to do everything three times.

The rule of three

When I first tried to learn Java, I realized I had no idea what I was doing. I read tutorials, some easier to follow than others, but mostly I was lost. I decided that maybe confusion was just a part of the process. We all learned to read. And it was hard. Someone showed us a letter and we were supposed to know what sound went with that letter. But wait, some letters have more than one possible sound. And some letter combinations can have more than one possible pronunciation. It was hard, but we did it because we had to. Eventually, those sounds made sense, but not because it got easier. It was because we didn’t stop with the confusion. We did it again and again. We pushed through.

If you are reading this, you can learn to program. I know this because you learned to read. But it’s the kind of thing that takes pushing through when you have no idea what you are doing. The rule of three for me means that I have to go through a complete course three times before I feel like I’m getting a handle on it. 

My favorite tool for learning programming is Sololearn. You can use it as an app on your phone, or use the website version, or both (premium is best if you are willing to pay a little bit). When I tried to learn Java with the app, I had no idea what I was doing. I muddled through the quizzes, and tried their code a little. I was not writing code on my own. I was completely confused.

The second time, I took their existing code examples, and started making small changes to see what would happen. It was cool because I felt like I understood small pieces of things. Some puzzle pieces were fitting together for me. Still, much of it was a mystery, especially ideas like object oriented programming concepts. 

The third time through the complete course, I pushed myself to try writing small programs on my own. Sometimes I would start with their examples, but then I would add other ideas from other sections of the course. I read people’s comments, or short articles on confusing topics. This time I felt like I was getting it. Even after this third time through, I never felt like I had it completely, but I felt like I was able to do this thing called programming. I felt capable, and less lost.

This pattern has repeated itself again and again. Later, I learned Python. It took three times before I felt I was getting it. And now, it’s the Android Development Course. Right now, I am going through it for the first time. I am copying and pasting the code they put in the examples. Eventually I get the code to compile and run on Android Studio, but sometimes I have to copy the completed code at the end because I missed something in the steps, or put something in the wrong place.

In truth, out of one thing I understand, there are at least four I do not. I am copying code that is a complete mystery to me. Some explanations make sense, and some go completely over me head. My hope, according to my experience, is when I do this the second time through, I will understand a lot more. I’ll let you know how that goes.

The important thing is to be okay with being confused. The ability to be confused and not give up is perhaps one of the superpowers of a good technical writer. None of us were born knowing this stuff. We have to look up things every day. The point is not to give up. Sometimes you have to walk away because the frustration is too great. I get that. Take a break. Go for a walk. Spend time with friends and family. Then tomorrow, do it again. Which leads me to my next point.

Do some every day

I have found the best way to do this, and not give up, is to do some every day. For me, working on this for up to 1 ½ hours is good. Sometimes I only get in 45 minutes. More than 2 hours and my brain is fried and I get frustrated, which makes it harder tomorrow. Less than 30 minutes and I feel like I’m not moving forward. If you have a day job, 30 minutes is great though, or maybe even 20 minutes. Not 5. But do it every work day, 5 days a week. Take weekends off. Then hit it again on Monday. If you do this, you will make it. Don’t rush it. It’s not a sprint. And it’s not exactly a marathon either. It will take a few months, but not years. You will see progress by the week, not by the day. At the end of a month you will be surprised at how far you’ve come. At the end of three, you might even start seeing yourself as a programmer. The important thing to understand is that it is doable. You’ve got this!