A Mini-Guide to getting started in Coding/Python (Part 2)

Introduction to Part 2

So, it’s been 3 weeks since the last article. I’ve just finished the Algorithmic Trading course I wrote about in the previous article so as time goes by I get a better sense of what works and what doesn’t. In this piece, we’ll cover some of the topics (which are more conceptual rather than technical) that I didn’t manage to cover in the last article.

General Concept: What is Productivity?

These days, due to the extraordinary circumstances we live in, productivity is a word that has been polarized. I think we acknowledge that these times are more difficult for some than others so labelling someone ignorantly as being unproductive is, of course, unfair. To me, being productive is simply making the most effective use of your time. If you have commitments and no spare capacity to learn anything new, that’s fine! You’re still being productive in your own way.

Productivity is often seen as the overlap between effectiveness and efficiency). But one often neglected factor that I have observed is a healthy sense of realism. An unhealthy sense of realism, or what can be accomplished within a certain frame of time, tends to snowball into procrastination. Usually the person in question becomes demoralized when he or she fails to achieve what they thought they could achieve. Here’s a simple example for anyone in university. Assignments are often given way before the deadline (at least in the arts, your deliverable is generally an essay of sorts). Yet, no matter how much time we are given in advance, there will be some rushing crazily through it on the last day, narrowly avoiding busting the deadline (and some still do bust the deadline).

The question is: “Why?” We often hear things like “I was too busy”. Were you? Or did you just prefer to do something else when you could have been planning your essay? Being able to confront the fact that you aren’t as good as you think you are will help you become more productive in the long run. That’s the first step, because factoring in realism realistically (getting abit meta here) takes self-awareness and experience. I’m not an exemplary student by any means but one of the things that helped me gain a good sense of realism early on in life is this: be able to accept the consequences of your actions. Most of the time I don’t go to class because I felt like I could afford the hit in my grades. But I have never handed up work late. This has little to do with being a good student, though I do think that there should be an ingrained sense of responsibility to meet a deadline, which will bring you far in your career.

The reason why I don’t hand up work late is simple: I cannot fathom that my last minute work is going to be any better than the work I did 2 weeks before the deadline. If I’m feeling extreme, sometimes I just clear it immediately when I get the assignment so I can slack my time away in a carefree fashion. I’m not claiming that this is ideal, but I had a plan and I executed it. I have a few rules to make sure my time management is consistent. If I’m writing an essay, I spend time reading the material. I don’t go nuts over it, but I make sure I understand it. Then I go to sleep while thinking about it. I might take a few days to think about it, but it’ll be at the back of my mind for the most part. Only when I have pieced all the pieces of the puzzle together, then I sit down at my laptop and write the entire essay in its entirety. I don’t stop till I finish the first draft. It could take 3 to 4 hours. This methodology has something to do with the way I approach coding, but I’ll elaborate more later. There are a few advantages to my method. First, the train of thought is never broken so you don’t have to ‘get back into that same space’ again, if that is even at all possible. Second, with a first draft in hand, the rest of the work is basically editing. If you did the thinking properly, you likely wouldn’t have to make any major changes. By streamlining the way you do an assignment, you could very likely have enjoyed a lot more of your time in university. You start to see how this process of streamlining can snowball into a massive amount of time saved. What’s the real trade off? Being able to clearly see what your end product will be and having the discipline to execute in that one sitting.

In any case, the point is this: we often overestimate ourselves on what we can or cannot do in a given amount of time. If we consistently fail to meet our own expectations, we tend to start procrastinating for fear of falling short again. Maybe some people feel entirely different, maybe some don’t have good time management for other reasons, but at least from what I’ve observed, this tends to be the case. To become more productive, be effective, be efficient, but most of all be realistic.

Best Practices to Stay On Track when Learning Code

So, back to coding. If you’re studying in university or you’ve started working, taking any additional workload is going to become a mental drain. Even for me, there are some days where I would want to make excuses to not continue onto the next lesson. Fortunately for me, having been lazy most of my life, I have the willpower not to be lazy when I want to. Often it involves reframing the mind through asking the same question: can I accept the consequences of my actions? Would I feel more fulfilled watching one more episode of this TV series? Or would I feel better just trying to do some code and making sure I don’t lose my touch? Having done both before, I consistently feel much better knowing that I have achieved just abit more at the end of the day. The easier path is to watch TV, but the more fulfilling path for me is to do what I needed to do. If your happiness is predicated on fulfillment, then the latter option is the better one in the long term.

So, what’s a realistic way to keep on track? What I’ve found after doing this for 2+ months is that you need to be exposed to code everyday (or almost every day, you can choose take one day a week off if you need to rebalance). Being exposed doesn’t mean you actually have to code. You could be watching a lecture, or potentially just playing with some coding ideas in your mind. I find that an hour worth of exposure is quite manageable. If you’re doing a course actively, the lesson timings may vary but I typically spend about an hour worth on a weekday. You can choose to spend more time on the weekend but you shouldn’t be spending more time on the weekend at the expense of your one-hour on the weekday. As you’re learning syntax and absorbing new functions, you should be getting your hands dirty everyday so you don’t forget what you’ve learnt. Anything more than an hour seems slightly unrealistic in terms of sustainability and anything less than an hour might be a little too short to be meaningful, especially when you’re just starting out. If you really feel you have no capacity to do it daily, you can try to do it on alternate days. But it’s easier to aspire towards the former and drop the intensity down to the latter based on your circumstances.

Another tip I’ve realized of late, while learning different aspects of the language, is that even if the instructor provides you with the code or note book, you should be typing it out again. You will retain the content much better and even if you understand the code conceptually, as someone starting out you’re likely to forget the little nuances that will result in errors. Simply typing out the code as you follow will help to ingrain some of the necessary syntax without you realizing it. I recall when I just started, debugging was a nightmare because you may have typed an additional letter, or failed to include enough brackets etc. As you do more coding, you start to pick out these mistakes faster. You tend to write it once well, partially because you know the pain of writing sloppily and having to trouble shoot it many lines down the road. You should also put in your own comments on how you’ve understood that particular concept because when you revisit the notebook, the content will come back to you much faster.

Lastly, love what you learn. Coding is so broad that if you pick it up just to say “I learnt coding”, it’s very likely you wouldn’t go very far. Figure out something you might want to program on your own. That’s your end goal. Take modules to help you work towards those goals. After learning the basics, I thought that I would want to brush up on my data science skills for Python. I’ve also done some trading before. Why not algorithmic trading then? I could have some good ideas, and even if not, I’ve found an incredibly efficient way of breaking down stocks and getting stock data. Work towards your end goal and you won’t lose steam so easily.

In short, if you want to stay on track without burning out or just giving up: be consistent, type it out instead of just listening and pursue a concrete end goal.

My Approach to Thinking About Code

I might be lucky in this sense, but coding is basically piecing a jigsaw puzzle together with linear logic. So, philosophy helped me there. I was also pretty decent at math despite the common stereotype so matrices, arrays and what-nots weren’t difficult to pick up. I might have been abit rusty but it all came back to me pretty fast – assuming you didn’t waste your education just trying to get an ‘A’ and be done with it…

In any case, the computer does not understand the human language. It understands code. Python is probably as intuitive as it gets for a computing language (to a human). As I mentioned in Part 1, the syntax and key terms used are close to how one would use them in natural language. So, if the syntax isn’t difficult, then you just have to get used to understanding how a computer would read what you write. For this, I especially liked Charles (the Python for Everybody course) because he depicts every function he teaches you with a flow chart.

Sometimes you may encounter a problem you just can’t seem to crack. Not a syntax error, per se, but the conceptual approach to how you should solve the problem. My advice would be, if you don’t get anywhere after awhile, walk away and sleep on it. Sometimes when we’re tired we fail to see the solution that could be right before our eyes. But don’t use it as an excuse to skim on your daily hour of coding, just outright slack if you have to. If I had a really tiring day at work, I give myself the night off because coding would be akin to banging my head against a brick wall. Sometimes when I take a walk in the park I might think about a concept; maybe I want to automate my email organization with code. I would try to figure out how I would do that in my head while walking.  If I can’t solve it, I just let it stew in my brain for a few days. If you’re just starting out, often you’ll need to google some of these pieces or look for some documentation before being able to execute your vision. That’s all part of learning, but you have to be able to identify the pieces of the jigsaw you need before putting it together.

Once you can see the concept in your head, execute. Similar to how I would write my essays, I don’t like to break concentration when writing code (for the exact same reasons stated earlier). Use #comments to keep track of what your thought process is, if you do have to step away. You should be able to type out the entire process in prose before you type it out in code. Now here’s the catch phrase of the day: #prosebeforecode

Reflections and What’s Next?

So where do you go from here? I’ve been thinking about the longer term. What if one day I decide I can’t code everyday anymore. That’s definitely a possibility. For the people that know me personally, I tend to enjoy learning a wide variety of things. There will be phases of obsession and eventually some of that obsession will wane away. A friend asked me recently whether I wanted to be a Jack of all trades. I think given how competitive the environment is becoming, you can’t stop at being a Jack. In poker (one of the other fun skills I’ve studied) a Jack is essentially worthless. You have to be a King, at least. We used to categorize people into specialist and generalists. These days, they have evolved. There is the extreme specialist (who will be the top 1-2% of his or her respective field) or the expert generalist (who can navigate and manage complex products, technical discussions and organizations). The bar has risen in the most competitive and lucrative fields (especially since technology is only looking to become more pervasive, not less).

So, what level of expertise qualifies as a King? Everyone may have different definitions on where the bar should be set. I approach the topic with a very pragmatic point of view: in this particular skill I am learning, what other base skills are enhanced? Let me give you an example. If one day I were to lose touch with coding, does that mean that I’ve wasted my time? Probably not. Through having to learn how to leverage data science when coding, it may have enabled me to get back in touch with my math skills. Suddenly, all the things we learnt in school (at Junior College level, no less) become relevant. Why learn about matrices? Why learn about probability? Binomial Theorem? Logarithm? This latent knowledge I’ve carried with me for 10 years becomes active. The 18 year old me that never understood why I was learning something finally understands how these obscure theories actually set the building blocks for many things that run in the world. It is quite amazing, if you think about it.

With every skill you set out to learn, you’re strengthening other core skills that you can apply in other facets of your life. When I learnt how to make coffee, I inevitably learnt more about chemical reactions. You will find more synergies, more links, more things to appreciate about how our world runs as well as the unseen factors governing our day to day lives. If not coding, pick up a casual course somewhere. Google something you’ve randomly wondered about but never got to reading. You never know how the universe could surprise you.

As usual, happy to discuss! Read Part 1 if you haven’t.