Changing careers is a daunting idea.  It is a special sort of blessing to know one’s vocation on the outset of his or her adult life, regardless of whether that vocation is a heartfelt yearning or whether it has been thrust upon them by heredity and/or social stratum.  Not knowing where to put one’s efforts, in a world were so many others do seem to know for themselves, is a very uncomfortable and disconcerting reality.  It is also a blessing to realize one’s vocation at some point further down the line… albeit a much more difficult one.

I wish I had realized that I wanted to be a programmer 15 years ago.  On the other hand, at least I didn’t have this realization 15 years from now.

I was accepted to Hacker School, and today marks the last day of the first month (out of three) for my batch of students.  A fitting time, I think, to reflect on the myriad of concerns burdening the fledgling programmer.  I have heard that it can be difficult to teach or relate to programmers with less experience, and so my window of opportunity to relay insight to the beginner or advanced-beginner may (hopefully) not last much longer.  Now seems a perfect time to document my journey thus far.

Choosing One’s Tools:

After I submitted my application to Hacker School, I decided it would be wise to start learning a programming language other than the VBA used with Microsoft Excel.  Choosing a language, at the time, seemed almost entirely arbitrary.  I understood that languages which have been around for longer, such as C++, have much more community support, but likewise have had so much development in so many different directions that setting out on making one of them a primary language can lead to a big mess, which is not ideal for a beginner.  But personal programming hero Tarn Adams uses C++, and not knowing much about other languages but still feeling the need to start learning a language in depth as soon as possible, I began to delve into C++.

When I received my acceptance letter, I was advised to stop learning C++ and start learning “Python or another modern scripting language like Ruby.”  I yielded to the wisdom of my future teachers/facilitators, and started taking the free, online course, “Learn Python The Hard Way.”

I do think it was wise to divert from C++, but I am very glad I started learning it first.  C++ is statically typed, which means that when you tell a program that you’re going to store a value in a variable, you have to tell it what kind of value it is.  This makes sense, since the computer has to reserve a certain amount of memory to store that value.  Python and other modern languages are dynamically typed, meaning they make the determination about what kind of value you want to store on your behalf.  That’s convenient, but if you’re like me, you don’t want something doing something for you unless you understand how it’s doing it, or even that it’s doing anything at all.  Had I started with Python, how long would it have taken me to understand variable- or object-typing?  Likewise, how long would it have taken me to understand how arrays/lists work and how they are normally stored and indexed in memory?  I don’t just want a language to understand what I want to do and do it magically; that’s only making me a slightly better programmer in that particular language, but not a better programmer as a whole.

After a couple of months of learning Python, I honestly don’t think I like it very much.  However, I think it was a great choice for me, personally, to learn, for one important reason: it forces me to make my code pretty (Python uses white-space indentation to designate code blocks, as opposed to something like braces).  My mindset had been that the only significant factor in a program was functionality — that it worked well and efficiently.  I have quickly learned that readability and user-friendliness are just as important, especially as the programming world continues to become more and more collaborative and open-sourced.  Learning and using Python has helped me correct my tendency to spew out a maze of nested statements, unreadable by anyone but myself without focused, time-consuming study.

I’m going to stick with Python until I can safely say that I know the language “well.”  It’s an arbitrary word, as there is always going to be much more to learn about any language, and it may take me a long time to reach the point where I can feel comfortable saying I know it “well.”  Once I’m at that point, however, I think I will start learning something more “static.”

I also seem to be one of the only people in my Hacker School batch who doesn’t have an Apple laptop (although I see a couple of Chromebooks floating around).  After submitting my application, I ordered a System 76 laptop which uses Ubuntu (a popular Debian-derived Linux distribution) as its primary operating system.  I only had a desktop PC running Windows 7 before, and I’d read that some tech companies require knowledge of Linux, so it sounded like a worthwhile adventure.  So far, I’m a big fan of Linux; this was a good decision, especially for someone nostalgic for the days of running everything from a terminal.

Choosing One’s Own Adventure:

Hacker School is an amazing place.  You can pursue any projects you want with whomever you want, and everyone seems very happy to offer their knowledge and time and energy to you in a friendly, collaborative, helpful way.  But as a programmer on the greener end of the spectrum, I crave discipline, because I will need to be employable as a programmer and I have a persistent fear that I’m not learning what I need to learn, that I’m not as good at this as other people, and that I’m wasting this valuable time at this amazing place.

There are a lot of people here (especially the more experienced folks) working on very cool pet projects.  People like me seem to pick projects specifically with the aim of learning new things or generally becoming “better” at programming, or specifically programming in a particular language.  And while spending time coding anything will make one a better programmer, I want to determine what projects will improve my skill the most in whatever areas I’m lacking.  The trouble with that is that I can’t really know in which areas I’m lacking!  Pair programming and code reviews are great, and they are a big part of Hacker School’s modus operandi, but while those activities definitely make me a better programmer in general (by pointing out where and how I should be refactoring my code), they do not quell my anxiety about my trajectory.

So far, while at Hacker School, I’ve built a Connect Four program (with ANSI graphics and a working AI algorithm), a couple of Markov chain language generators (which use different methods of obtaining a similar result), and a simple tic-tac-toe program (with AI) built for the purpose of connecting to a tic-tac-toe server some of us built in a group project.  I’ve also gone to several informal classes, with subjects ranging from networks to databases to Git to theoretical mathematics, and although I’ve learned a lot from them, I have yet to apply much of that knowledge (although I’m using Git all the time now).  I’m not certain if the classes are a good use of my time, and I’m making a stronger effort not to overextend myself, so I can focus more on coding.  But in a month of being here, I feel like I should have a larger, more dynamic, more impressive portfolio.  I’ve spent time playing around with other programming concepts, but haven’t started any real projects with them.

On the other hand, there is one other way in which I’ve been spending my time here.  A couple of other Hacker Schoolers and I have been going through the NAND to Tetris, or “Elements of Computing Systems,” course, which was recommended to me in my first interview with Hacker School and which has proven extremely worthwhile.  The small handful of us taking the course have been keeping each other in check to make sure we get through each chapter and its related projects in time, and also reviewing each other’s finished projects.  So far in the course, we have each built (in a hardware simulator) every type of logic gate starting from a simple NAND gate.  We’ve built multi-bit multiplexors, demultiplexors, and an ALU from those gates, as well as memory registers, program counters, and CPUs.  From there we’ve built programs using machine language, and built assemblers to translate that machine language into binary our simulated computers (which we’ve constructed from the ground up) can understand.  So I do have those items in my portfolio.  I was a little worried about the fact that the course seemed a diversion from my becoming better as a Python programmer, but now that we’ve gotten to the point where we are programming assemblers and will continue to move upwards into higher-language functionality, I am able to use Python to complete the chapter projects.  It is a wonderful thing to fully understand the whole body of computing at every level, and I highly recommend the course to any advanced beginner (you at least have to know enough programming to build these components in a simulator) in any of the computer sciences.  It is also very nice to have a disciplined, linear series of projects to keep my focus and help me not feel like I’m flailing for project ideas.

Persistence, Frustration, and Satisfaction:

The Connect Four program I mentioned above took me one day to write; my first day at Hacker School.  I felt like I’d accomplished something, I felt intelligent, and I felt like I was following a good rhythm of tackling something new, completing it, and moving on to the next new thing.  The next day, I decided to add the artificial intelligence to the program.

Three and a half weeks later, it works.

The code in the program for the artificial intelligence is only 22 lines long.  It’s a simple “minimax” algorithm which took me about ten minutes to read about and understand, ten minutes to initially write, and hours upon hours upon hours to stare at, tweak, test, stare at, tweak, stare at, test, refactor, stare at, and tweak some more, in a seemingly endless cycle of utter futility.  I had other students look at it, I had facilitators look at it, and it just would not do exactly what it was supposed to do.

When I made the AI for the tic-tac-toe program, I thought to myself, “Now I’ll get that algorithm working, since it’s a much simpler program!”  I wrote the minimax code, and it seemed to exhibit the exact same malfunctioning behavior.

This time, however, one of my fellow students offered to help and actually stuck with me for literally hours and hours trying to get it working.  Both of us agreed that it should be working, and since I had already spent what I felt was a ridiculous amount of time staring at very similar AI code, I was not very optimistic about our chances for success.  As we kept testing and tweaking, in the back of my mind I kept thinking that he was wasting his time, and I felt bad for wasting his time.  But some time after most of the other students had left for the day… it finally worked.

This was a huge lesson in persistence which is invaluable to any programmer.

So, of course, I now felt confident that I could just mimic what we did with that code in my Connect Four AI, and get it working without too much effort.  Feel free to chuckle maliciously to yourself at this point.

An experienced Hacker School colleague, having heard how long I’d spent trying to get it to work and how many people had attempted to help me fix it, saw it as a challenge and spent a good deal of time on it.  She got it working; apparently the issue had absolutely nothing to do with the AI portion of the code, which she’d said was “actually really elegant.”

There are days when I come home with my brain totally fried, so frustrated with how the day went and how little it seemed like I’d accomplished that I can no longer think straight.  But even these days are a testimony to the fact that I should be programming.  In every other job I’ve had, when the day was over and perhaps I felt overwhelmed with frustration, I would just shut my brain off to that aspect of my life.  I cannot do that here.  I am thinking about what could possibly be preventing my code from working even as I lie in bed.

There are several lessons here.  The first I learned is that if you spend enough time on something and do not give in to frustration and the feeling of futility… it will succeed.  But I also learned that if I felt the same way about coding as I have about my previous jobs, there is no way I’d be able to do this.  If you are unable to became totally frustrated with a program and persist despite this fact, you should not be a programmer.

Fortunately, I’ve also experienced what it’s like to get something to work.  Sometimes on the first try!