Learning to Learn
I’ve been talking to a lot of people to try and get a feel for the options and landscape for an aspiring developer, and have learned several things.
1. I want to work for a product consultancy or devshop that has a very teaching culture.
I want to work for a product consultancy or devshop (to be honest, I don’t know if there’s a difference between the two) because I would have the opportunity to work on many more projects and be exposed to new languages and frameworks, and I would have the opportunity to interact with people form other industries, which is one of my favorite parts of my job today.
I also realize that as developer, I suck and I need to get better in order to provide any real attitude, I want to start my career as a programmer with an apprentice’s mindset and really try to soak up everything I can from the people around me so that I can get better and start contributing. Without someone to guide that learning and provide feedback, I’m not going to learn as much or as quickly.
I’m still trying to get a grasp of the entire landscape, but from what I can gather and the conversations I’ve had so far. This seems like the right thing to shoot for.
2. There’s so much to learn.
I’m reading “The Well Grounded Rubyist” to brush up on the theory, and basic tenants of Object Oriented programming. If I’m committing to this, I want to do it all the way and learn from the ground up. “Why’s (Poignant) Guide to Ruby” was a really great and memorable way to introduce many of the concepts, I still like to think of Arrays as content caterpillars stapled to paper. behind but I appreciate how thorough and granular “The Well Grounded Rubyist” is. However, as much as I realize how important a solid understanding of the fundamentals is, you can’t really learn to program by reading a book. You actually have to open up a text-editor and do the work. that can be intimidating because reading reveals just how little you know and you have to contend with the fact that whatever you build is going to be built poorly and turn out to be absolute shit.
I’ve been using the ADEPT method to get the most out of what I read, and I’ve been using the problems on Project Euler as kind of a coding bare minimum for the day. I like them because It forces me to figure out how I would solve the problem in plain english first and then figure out how to translate that into code. I’ll start posting my thought process and solutions soon (I need to upload them to Github first). I’ll soon take on a project like TicTacToe or some sort of game likeDwemthy’s Array, and you should start to see a lot more code on here.
3. TDD and Git are a big deal
Test Driven Development (TDD) is something that I need to learn and so is git. The two are unrelated but they came up a lot as I was doing job research. I’m going to take Thoughtbot’s course for a primer on TDD and still looking for a crash-course in git and github. More and more quitting earlier and learning this stuff seems like a better and better idea.