We often talk about how our courses go beyond the basics of programming languages and teach students to actually think like software developers. We help students learn how to learn, so they have the ability to continue studying and improving throughout their careers. But if you haven’t been through one of our courses, it might be hard to understand that concept. So we thought it might help to hear it from someone who has.
Four weeks into his first job as an iOS developer, one of our graduates reflected on the idea of learning to learn. Chris Myers recently graduated from our Mobile Engineering course in Salt Lake City and is now working for a research university in Atlanta. In his post, he talks about how he overcomes the daily challenge of not knowing how to do something he’s been asked to do.
I have been taught how to find an answer, to discern whether it’s useful to my situation, and 99% of the time, tailor it to my needs. Not knowing something is not the same as not being able to figure something out.
Chris’s full post is below. Want to read more about his journey? Check out his full blog here.
I know, it’s been awhile. Apologies. I have been busy though. I’m just finished week 4 of my new job. I work as an iOS Developer for a research university in Atlanta. We are building an app that monitors the stages of aging through games. It’s a challenging project with a lot of different pieces to build. When I came in, the first game was completed. Before we get to the second game, we’re working on the secondary tasks that need to take place, such as log-in verifications, security protocols such as encrypting data we receive, and uploading results remotely to a back-end server.
I didn’t know how to do any of this when I got here.
Allow me to clarify that point though. I didn’t know how to use Alamofire to post results to a server. I didn’t know how to encrypt the results using Realm to upload to Realm’s server. I didn’t know how to encrypt locally in the directory the file is stored. I didn’t know, I didn’t know, I didn’t know. It’s a common theme each day–pretty much the start to every morning.
However, I have been taught how to find an answer, to discern whether it’s useful to my situation, and 99% of the time, tailor it to my needs. Not knowing something is not the same as not being able to figure something out.
When I started, I bought a new notebook to keep track of tasks that I’ll probably need to know how to do on a regular basis. I was given one of these when I started The Iron Yard and I filled it up by the time I ended.
The one I bought is a bit nicer, and much thicker. I’ve got tasks ranging from pushing, pulling, branching, and merging on Git, to making NSURL requests to upload documents to a back-end. I consult this book daily and my fellow iOS colleague has dubbed it “The bible”. It may very well be as I always have it with me, and I always use it!
I won’t say it’s all sunshine and roses though. There are large portions of my week where progress feels slow and I’m stuck. To combat this, I keep in mind a quote I heard on a tech blog devoted to new programmers. “Programmers are paid to be frustrated.”
The quote speaks to me on several levels. One, they’re exactly right. I’m constantly frustrated–very rarely do I get it right the first time (Ok, never!). Two, it’s a mantra that keeps me from losing it when the frustration passes for multiple days, which happened with both encryption and multi-part body post requests. Finally, I use it as a performance indicator to gauge my frustration levels.
All said, I’m enjoying being paid to be frustrated. The successes always overshadow the days of frustration. The gratification that comes from problem solving is intoxicating.