Wow, it’s been almost a month since I’ve posted! I can’t believe time is flying by so quickly. I have a point to this post (albeit convoluted, as usual), and I’ll get to it, but first… a couple of words about what the hell I’ve been up to!

Good (First) Jobs Are Hard To Find

The reason I’ve been so quiet lately is a combination of personal/family issues (aging family is rough) and my desperate job search as I near the end of my financial rope. I finished my Code Academy at the local community college in late August, and went on to launch myself fully into finding a first job. As it turns out, trying to land your first development position is actually very difficult, and extremely competitive.

So, this great thing happened to help me with this part… I’M GOING TO THE GRACE HOPPER CELEBRATION OF WOMEN IN COMPUTING! THIS IS HUGE, folks. I received notification that I was taken off the waitlist, and immediately freaked out because it’s not exactly a good time for me financially. The irony is that the reason I need to be at this event is the networking and even interviewing potential.

Fortunately, my Wellesley alum network had my back, and within 48 hours, we had crowdsourced the funds for my ticket and airfare. I can’t even believe that I have so many incredible supporters and fans cheering me on to succeed in this career transition. 🙂 Many, many thanks to everyone who was able to contribute. Hopefully next year, I’ll be a GHC Scholar or receive some other kind of grant funding to attend!

New Opportunities Means New Languages

I have a couple of possibly awesome opportunities on my plate for my first web development position. One is centered around PHP, my true love to date… and the other is infinitely cooler, but the first steps involve me learning a different language ASAP in order to solve the first coding challenges. As such, I have decided to switch tracks (temporarily) off the Full-Stack JavaScript track, and onto Ruby.

FUN! Right? Actually, it really is. Treehouse comes to the rescue once again with their amazing tracks, and I switched from the long-lingering Full-Stack JavaScript track to Ruby. Do you know Ruby? If not, I’m going to put this out there after just a few hours of slamming out videos, quizzes, and code challenges: it’s really fun.

Once I know enough, I’ll probably do a Code Speed Dating piece on Ruby, but that’s not the point of this post, either. But so you know, so far, I’ve just gone through da basics:

• variables
• functions
• strings/numbers/floats
• arrays
• hashes
• objects

These are all the tools in our toolbox. However, as I jumped into the coding challenges… I realized that I have some hangups. You can’t use the tools unless you understand what the project actually requires, and what you’re going to actually need to do.

The key takeaway of this post, if there is one, is that learning to programming isn’t exactly a process of writing code. Programming is artistic, and centered around evaluating problems the world faces. As an engineering discipline, we build solutions to these problems by first approaching the problem in our native language.

What exactly is the problem? How many smaller problems make up the larger problem? How can each of those smaller problems be approached? If you are working for an organization, you may even have to ask yourself, what is the most effective way to build this program for scalability and expansion?

Tunnel Vision: The Problem With Focusing On Code

I’m noticing that I am going through Treehouse at grueling paces. There have been occasional “extra credit” challenges, and they tend to make me a bit nervous. At some points, I’ve even just looked up what other folks did to solve the problem, then tried to reverse engineer it to truly understand their solution. This, to me, is indicative of a greater problem. I’m not spending enough time learning solid problem solving skills.

But how do you know when you need help with problem solving?

I’ve been reading a lot lately about actually “thinking like a programmer”. One of the books I’ve really enjoyed so far is called Think Like a Programmer: An Introduction to Creative Problem Solving. I’m currently about half way through it, and would highly recommend it to anyone looking to become a more well-rounded programmer. In fact, the book opens up with the following text, and I felt like it was speaking directly to me:

Do you struggle to write programs, even though you think you understand programming languages? Are you able to read through a chapter in a programming book, nodding your head the whole way, but unable to apply what you’ve read to your own programs? Are you able to comprehend a program example you’ve read online, even to the point where you could explain to someone else what each line of the code is doing, yet you feel your brain seize up when faced with a programming task and a blank text editor screen?

My answer to this is a resounding yes! I’m not afraid to admit that it takes far longer for me to develop an approach to a problem, then develop the solution, than it should. I actually believe that this is a very fixable problem that virtually every new programmer who doesn’t come from a logic/problem solving background will eventually encounter. And it comes with time! But for now, I figure can do something to speed up the process.

After the introduction, Think Like a Programmer moves into some “classic puzzles” like the sliding numbers puzzle, and even Sudoku. It’s hard to believe, but these games tie very closely into programming concepts, as well as identifying patterns in problems and solutions. Building on recognizing common problems in programming, including recursion, pointers, code reuse, and objects… Think Like a Programmer does a solid job of explaining how to approach them, regardless of the language being used. This is one of the greatest parts of learning to effectively solve problems in programming: while the book focuses primarily on C#, its principles apply to any language.

Another book in my queue is Pragmatic Thinking and Learning: Refactor Your Wetware (Pragmatic Programmers), which has been plugged by programmers on StackOverflow and several blogs. The cover image above is an excerpt from the book, depicting a map of the process surrounding “pragmatic thinking and learning”. I’ll probably write something up on this book once I’ve read it!

Once I’m done with this book, and maybe beforehand… I’m going to take advantage of GAMES! Specifically, coding games! Codingame appears to utilize coding to make things happen in video games, moving away from the abstraction that tends to plague programming challenges. Being a gamer, this sounds like a lot of fun. I enjoy hands-on exercises driven towards making something happen that I will actually use, more than coding for abstract problems that I may not actually be facing.

In Closing…

At the end of the day, I want to feel confident and capable. Acknowledging what I am doing well, and also identifying what can use improvement, is a constant process in a developer’s life. It takes a lot of introspection and mindfulness to recognize our weaknesses. I have a feeling that I’ll be writing a lot more on this topic as I learn more, and hope that you’ll provide me with your insights as well!

Do you, too, experience paralysis when facing a blank text editor page? Know of some great resources for learning to solve problems more effectively? Let’s talk. As always, you can also keep the discussion going on the La Vie en Code Facebook page, or via Twitter @lavie_encode. Happy coding!