Tag Archives: Motivation

Learning to Program on Your Own

Learning how to code is like learning anything else – You have to do it. The hardest part is figuring out where to begin, and then you need some mechanism to show you that you’re making progress. The latter is important because it motivates you to keep going.

First, have a goal. I initially wanted to make AOL “punters” (apps that kicked other users offline) and malware. I found them interesting. Do you want to program games? websites? Facebook Apps? Apps for OS X?

Once you have the goal, do research on how those apps are made, particularly on the language used, APIs/libraries used, and so on.

When starting, you will be learning a lot of concepts that you will see no use for. If-then statements, variables, etc. You might understand the basic idea of what a variable is, but might wonder – why would I ever use this instead of putting the value in directly? At this stage, it’s important that you remain persistant and just go through the examples/exercises in your book (or those provided by your tutor). I noticed that most people will struggle through the first set of concepts, and then lose interest and quit after seeing that they aren’t doing anything interesting. One day, you’ll be doing something and everything will fall into place. An A-Ha moment.

You’re learning a bunch of stuff that doesn’t really connect with each other. How does printing “Hello World” to the screen eventually become a 3D game? How do I go from a console app to a window app? How does knowing what a variable or constant is translate to a web development project?

It’s a plateau — and I want to stress that this applies to almost anything, not just programming. You begin by learning a lot of stuff, very slowly making progress, and over time you begin to see that you kinda “know” what’s happening behind the scenes of the apps you’re using. After that, learning because easier and quicker. Getting to that level requires persistance.

My Turning Point – Stop Asking “What Should I Code?”

When I first began coding, I had the mentality that I had to “learn how to program” before “making app X” – This is logical but the way I structured in my head was important in impeding my progress. I divided learning how to program and making app X into two separate goals. It was a problem because it migrated me away from the goal of “making app X.” I began asking the wrong question – what should I code to learn how to program?

Instead, I should have been asking – what should I learn next, to reach my goal of making app X? I broke down app X into individual tasks, and then began learning how to do each one. For example, let’s say my goal is to program a game.

If I ask “what should I code to learn how to program?” I will spend a lot of time learning things I might not need anytime soon (or ever), I will get nowhere near reaching my goal, and will become unmotivated and quit before getting there. Instead, I would break down the game into individual tasks (this requires research) and work on learning each one.

Let’s see, I need to figure out how to make a window/draw things on screen. That becomes my new short term goal. I dig deeper and learn that I need to learn the Windows API. I learn that the Windows API is how one draws to the screen. But the Windows API is another thing I need to learn, so that becomes the immediate short term goal. Digging deeper, I realize that the Windows API is just a bunch of functions with some conventions that I need to memorize.

Now my goal is somewhat clearer. I begin reading about the Windows API, making different small apps to make sure I understand what I’m reading. Eventually I am able to draw a window and controls. Great. I still don’t have a game. What’s next? I need to draw graphics. I dig into how it’s done and learn that the Windows API provides a set of functions graphics. I’m familiar with the Win API and so I just begin learning the graphics lib. I make a few dozen apps drawing basic circles, loading bitmap images, etc. Now my goal of making a game is starting to take shape in my head. I can mentally structure how the game will be, minus a few concepts I might not have learned yet.

Persistence.

What Firefox’s Memory Leak Feature Taught Me About Life

(draft)

I’ve been using Firefox since the first public beta, and the one thing always on my wish list was fixing the sluggishness and unbelievable memory consumption (2 GB of RAM?) that results from keeping Firefox open for too long. This is still on my wish list today (almost 2010), and I know it’s unlikely to be fixed. In fact, I’ve realized that – Zen Moment – the ‘patch’ must come from within.

The Mozilla team claim it is a feature and not a bug. Firefox stores pages you’ve been to so that you can go back to them instantly upon hitting the “Back” button. This means that FF’s memory needs grow as you browse the net, and leaving a page doesn’t necessarily mean the page’s memory has been deallocated. It makes sense, but in practice it results in Firefox becoming unresponsive. You can go into about:config and edit hundreds of settings, but I’ve never had any success with any of them in any version of Firefox on any OS. Ever.

I probably don’t use Firefox like the majority of users, and certainly not like the developers intended. For one, I don’t close it. In fact, I’ve never voluntarily closed Firefox in my life (I don’t shut down). I purposely crash it and then re-open it so that it asks me to load up all my previously open tabs. This clears out some memory and restores responsiveness making Firefox useable again.

Why don’t I just close it? Because I usually have a minimum of 50 tabs open across several FF instances, and some of those tabs are actually those “Oops, this is embarrassing…” windows that let you choose what tabs to re-open when you re-run a crashed Firefox. That means some of the tabs hold the potential to open up dozens or even hundreds of more tabs.

I feel relieved when Firefox is unable to restore my tabs. Life starts anew.

I keep tabs open that I intend to go through (never!), and I keep different sets of windows/tabs open depending on what I’m doing. i.e., cooking tabs in one window, work tabs in another, research tabs in another, etc. But this isn’t restricted to Firefox. On my Linux desktop I have 2 displays and 8 virtual desktops, making that 16 workspaces, and they’re usually always full. Since I have the RAM/power to run this setup, it’s smooth… except for Firefox and most other browsers (not Chrome).

On this desktop I worked around the Firefox memory problem by creating multiple profiles and using different profiles for different tasks (one for work, one for multimedia, etc). This also allowed me to crash one without affecting the others. It’s a temporary and crude solution until Firefox natively supports multiple processes like Chrome (see Electrolysis.)

But while there are some workarounds, fixing the technical issue isn’t going to increase productivity much. Having more sites open will probably make things worse. The habit of putting things off for later is inherently the problem. Having many sites/apps open is normal only amongst abnormal people. There’s nothing ‘wrong’ with it, but I don’t feel it’s very efficient, even if it may seem so at the time.

I’m generally disorganized and severely ADD-ed, and so this issue doesn’t only exist digitally. My desk is just as messy as Firefox. I have pieces of paper, napkins and anything else I jotted down notes on. I have unopened snail mail, opened but unchecked mail, and mail that has been checked and separated into 2 piles, those that require a reply and those that are to be trashed. There’s books I’m reading (multiple), and always unsorted pages of ideas/diagrams/blueprints of things I’ll probably never get to.

I’m obviously spreading my attention span thin. Going back to Firefox, if there’s an important piece of news on a page buried beneath other sites, I subconsciously still have “must read that article” somewhere deep in my head. It probably doesn’t result in any noticeable effect on its own, but when multiplied by 100x, the decline in calmness becomes significant enough to kill productivity. It produces a weak feeling of anxiety or overwhelmingness.

Learning to Read and Grok Other People’s Code

One reason many people don’t contribute to open source apps is because they find it daunting to look through somebody else’s code. Some might even think that it’s just simpler to write something from scratch than to study someone’s work. This isn’t true, and reading foreign code is something get used to and excel at over time. It’s a necessary skill for every programmer, and has many benefits.

A huge benefit is the massive amount of information you learn and get accustomed to in a short period of time. There’s no way to download O’reilly PDFs into your brain just yet, but grokking source code written by those much more experienced than you is one of the fastest ways to see and practice everything you’re been learning in theory (books, sites, classes).

It’s certainly overwhelming to jump head first into a huge app trying to understand every line. I think it’s common for people to open up some code, read it for a few minutes and then never touch it again because they don’t understand it. This was the case with me when I began programming. Here are some ways i used to justify putting off the need to read third party code.

Their code style didn’t suit my taste, i.e., they add the opening curly bracket under the function definition, and I would find myself changing their brackets and formatting more than I spent time actually looking at the logic.

I told myself I would learn much more by re-inventing the wheel, or have more control over my app if I built it from scratch. This is only partial true, but the cons outweight the pros. Reinventing the wheel means diviating from writing program logic and having to learn something that might not even remotely be related to the project I intended to start or finish. Here’s an example that used to be common.

Continue reading Learning to Read and Grok Other People’s Code