I’m a total newbie when it comes to programming. I no longer try to convince myself that these couple of years of Turbo Pascal in high school still count for something. I realised that my <a href>s and <div>s became common knowledge. So this is why I started my Programming Primer course with a clean slate. For anyone with a tiniest bit of an ego and anything more than 5 minutes spent creating your own blog, it’s not easy to accept that you in fact know far less than you think you do. My husband often challenges me to “Forget everything I think I know”, being a true Marvel fan as he is, and I found this bit of advice very useful when I approached the programming course.
Perhaps unsurprisingly, two classes into the course, I found that letting go of any preconceived notions and ideas about programming, programmers, and programming courses can teach me much more than just learning how to code. Sure, I’ll know my functions, methods, arrays and lists soon enough, but there are also important life lessons in there! I wouldn’t be myself if I didn’t try to zoom out…
Define the end game first
I’m yet to discover whether this is true for all cases and all programmers, but in yesterday’s class the instructor started a coding exercise by writing the last few lines of code first: this is what we want the program to ultimately do. And then we worked our way backwards, creating all the missing tests, commands and variables in between. It struck me that while I’ve known this approach of beginning with the end in mind and I usually apply it to big decisions and plans, I somehow lose sight of it when it comes to the day-to-day. I’m fine with writing my eulogy in 3 sentences to make sure I live my life how I want to be remembered, but I struggle to insist on ending the day feeling accomplished and working my way back for the perfect recipe. What if, just like in programming, I started everything I do by focusing on the outcome?
Nothing ever happens in a straight line
Before this week, I imagined that you write code line by line, progressing from an earlier command to the next one, and the next one, and so on. Imagine my surprise when I actually saw, on a big screen in a lecture room, that the instructor himself jumps around unapologetically. He starts with the last few lines, then goes back to the beginning, then inserts something in the middle, then goes back to the beginning, adds some more towards the end, and then inserts some other bits here and there. Wait what, I gazed in awe, you don’t just write it in an orderly manner, in the same order you want the program to then work? Apparently not. And then it dawned on me: the end result you see in others and in your own life is a product of a messy process with sidesteps, leaps ahead, backtracking, circling back and doing U-turns. It’s unrealistic, and a bit naïve too, to expect that you’ll swiftly move from zero to hero.
State your boundary conditions
What a great lesson for life, too! You tell the program what’s required and needed for it to work properly and how you want it to work. You define your must-haves and exclude your won’t-haves. I decided to adopt this approach for my own decision-making. If I’m thinking of designing a day when I feel accomplished, I list everything that needs to happen on that day, and I write down what can’t happen on that day. If I’m thinking of my own business, here are the things that are essential to me, and here are the things I don’t want to do (and yes, accounting is one of them). Why haven’t I thought of this before?
Don’t try to figure it all out by yourself
Apparently, in programming you start with the assumption that someone, somewhere has dealt with a similar challenge before, so you go someplace you can find code written by others, you look for a solution and there you go, you don’t write it from scratch yourself. It’s not only allowed, but even encouraged. Life, to my surprise, seems to work in a similar way. If you’re facing a challenge, you don’t get a special badge of honour if you push through and persevere all by yourself. Quite the opposite, this can cost you time, money or health. It doesn’t seem to be very honourable or practical to insist on the idea that you have all the answers within you, if you just keep on working very hard. This, for someone as independent and stubborn as me, is a revelation.
Reading and applying are two very different things
I did a lot of pre-reading for the course, and I still ended up being incapable of creating the same functions I studied when it was my turn to write some code. But I read it all! How difficult can it be to apply it now… It turns out that reading and applying are not the same thing, in programming and in life. You can read all the books and articles on productivity, time management, reaching your full potential and maybe you’ll know the ideas conceptually, but it still won’t make you stop procrastinating and manage your time like a ninja. It’s only the actual practice, the struggle of applying what you’ve learned, that can put you on the path to really, really knowing something.
Important lessons came with some less prominent ones. I now have proof that I find it hard to focus on a given problem, especially if it involves looking for solutions online, without getting distracted. I know it’s difficult to stay concentrated in a lecture if you’ve been out of the student mode for a while. And I picked up a few really, really geeky jokes… On to more programming now.