4 things I wished I knew at the beginning of my programming journey
I work as a programmer now – as many of you know. But what some of you don’t know is that my own academic background is extremely far from it. In fact …
Photo by Kim Youngjun
This is what I studied. Not Python but Japanese domestic politics. Not data science but the Japanese Diet. Not CSS but the Constitution.
Over the past few weeks quite a few people have approached me about their own journeys into programming. How to learn, where to start. And of course the unspoken question of is it even possible to do so?
I want to reassure everyone that it is definitely possible to pick up programming by yourself. Programming is however one of those things whose learning curve is so steep that you think that you’re climbing Everest when you’re learning it. And while you’re doing it the sun is stabbing you by throwing gobbledegook errors into your eye.
Once you do get over this giant seemingly unsurmountable hump though things get much easier. More than just a skill, programming is a way of thinking. In the rest of this article I want to share some things which, had I known earlier, would have made my life much easier climbing this mountain.
1) Computers are more like animals than humans
With all this talk of “artificial intelligence”, I think people are getting the impression that computers are smart. Or like humanity’s future overlords.
Maybe in the future when we develop real AI which passes the Turing Test this may happen. If you want me to describe what computers and code is for programmers though.
This is what comes to mind. That’s right – a water buffalo.
Think about it. The point about code is to avoid doing things manually. Instead of printing out flyers one by one, you make a website. Instead of calculating things individually, you make an Excel macro. And instead of ploughing a field by hand, well you get a water buffalo to rake the fields for you.
Also, in the same vein your computer is a strong but dumb beast. Treat a water buffalo well and it will tend your fields well. Treat them badly and they will rampage. Same thing with code – direct your program well and your code will save you huge amounts of time. Treat it wrongly and it will do the work slowly or even break your computer.
The good thing about programming however is that unlike a water buffalo, code is predictable. Unless there is some external dependency, the same input put through the same program will lead to the same output.
Therefore, if you find yourself frustrated at code, instead of thinking punching your screen or rage quitting, imagine this face below.
This poor buffalo actually wants to help you. It’s just that it doesn’t understand what you’re telling it to do. And that learning to be a better programmer is like being a better cow whisperer.
The cryptic errors that your screen is showing you is a buffalo grunting at you that it does not understand. Once you figure this grunting out you can improve your relationship with it and productivity.
2) The most important skill for beginning programmers? Understanding errors
So this buffalo is throwing you all these cryptic messages. You know they’re in English but what the hell do they mean by an expected (or missing) token? Are we at a retro arcade here?
Being thrown incomprehensible errors is one of the most frustrating things about being a beginning programmer. And neither is programming the kind of thing where the problem solves itself the longer you work at it. Code works or it does not – no matter how long you stare at it.
The first thing to realize that despite how illogical, obscure and arcane these errors are, there is a logic to errors. For example,
Parse error: expecting ';' in line 1 of moo-world.php
Is simply the code telling you that you made a command to it in line 1 but you did not terminate it with a semi-colon. The code doesn’t know that it can go to the next line (next command) and therefore is staring at you waiting for you to tell it to move on with the “;”.
Similarly, another cryptic but very common thing that beginning programmers will see in Javascript. Say you want to get the milk of a buffalo on a farm.
var farm={};
farm.buffalo.milk;
Uncaught TypeError: Cannot read property 'milk' of undefined
In non-code English this is simply the computer screaming at you: “I know you have a farm but how do you expect me to get the milk (cannot read property) if there’s no buffalo (undefined)!”
In this same way, most of these cryptic errors can actually be explained in normal English. This is also why having a more experienced programmer who you can convert code logic and errors to understandable English is so important at the beginning stage.
Being able to digest errors and therefore be able to solve them is the key to not rage-quitting programming.
3) Computer Science fundamentals are important
Moving away from buffalo metaphors, I want to state that for programmers of all sorts, knowing the fundamentals of computer science is important. They are also crucial in your long-term development in understanding errors (as above). However, many obvious ways of learning programming do not actually teach them.
When most novice programmers start it usually starts from a want to make stuff. Maybe you want to make a new website. Maybe a mobile app. Maybe you handle data daily at work already and want to know more about the “science” part of it.
What usually happens then is that you go on CodeAcademy or Udemy and pick up a course that promises to give you everything to change you to a programmer.
You + Online Programming Course = PROGRAMMER!
Not to diss these solutions. Udemy was crucial in me becoming a programmer actually. However, my own experience has been that these courses often are designed to take you from point A (zero) to point B as soon as possible. The hidden subtext is that, depending on the course, point B is not necessarily becoming a competent programmer. It could just be someone who can recreate the exercises in the course.
The two are very different because coding in an online course is a very controlled environment. Many courses will actively avoid less beginner-friendly but very common ways of programming, handholding you until you reach the end point. Repeatedly using and teaching of loops over functional programming being one example.
In the worst case you can just copy and dump the sample code from the instructor after all. When you actually have to program actually, it’s a wild wild ride.
And bugs are usually nowhere as cute as Caterpie is. They will still tackle and string shot you though. What saves you in this case is not necessarily the coursework, but the fundamentals of programming which is will allow you digest errors, debug and learn faster.
Where you may learn the computer science basics
I have to say that a full computer science education is not necessary to be a programmer at all. Nonetheless, some understanding of computer science fundamentals is necessary for any programmer to reach at least intermediate level programming. The earlier you learn concepts like reference vs values, what the call stack is, encoding and object oriented programming the faster you will learn to code and be able to read someone else’s code.
It is also because of this that IMO, coding bootcamps can be very valuable because they tend to teach these fundamentals and have someone who you can directly ask if you really get stuck. If you’re Tokyo and have the resources, do consider the courses that Code Chrysalis‘ offers. I myself have taken a look at their curriculum and it really is very comprehensive.
Otherwise if you want to continue things online I highly recommend going through Harvard’s CS50 which is entirely free.
“But there’s so many things to learn!”, you may say. Two things I want to say in response. Firstly, that it really does get better once you go over the hump of programming. But also, that a desire to learn more and clear up the dark spots in your understanding is a prerequisite to becoming a good programmer. If the learning in itself seems too much then being a programmer may not be the best choice for you.
4) Referencing others’ code is both necessary and dangerous
One of the first things that you learn as a programmer is that there’s a lot of other’s people code online. Don’t get something? Google – which actually is perfectly healthy and common among advanced programmers too. Can’t do something? There are these godsends called libraries! Javascript too difficult? There’s jQuery!
Something not working? Go on Stack Overflow, find the top answer to your problem and copy and paste! Tadah – it works!
Clearly things aren’t so simple. After all, you might not need jQuery. As a front-end web engineer which often does CSS, there are countless times that I have seen top-rated Stack Overflow answers recommending using “float: right” to put things to the right. This was correct maybe 6 years ago – the industry standard right now would probably be using flex-box for the same purpose.
In short, other’s people’s code can be outdated (and by that same factor have enough time to garner +1 votes). Also, something that works can be inefficient – like using javascript to do positioning when just CSS is possible. In addition, adding in libraries en masse can lead to future blockages when you need to customize stuff and not to mention also possibly being insecure.
The difference between beginning programmers and non-beginner programmers is knowing when and how to use other people’s code. This section is very important so I want to split it up into three commandments of how to use other people’s code.
I. Thou shalt read beyond just the top answer
Stack Overflow is a godsend to all programmers. As mentioned above though, just because something is the top answer does not necessarily make it the best solution – you have to be discerning too. But how?
My suggestion is to always read the top 3 answers. Often the second or third provides a more updated solution that builds upon or makes a good critique of the top answer. Use your discretion to then choose the most applicable one.
Also, read the comments for these answers. Often a highly rated comment on an answer will explain its limitations or why it needs to be changed.
Aside from this allowing you to possibly get a better solution, this will also also allow you to understand the multiple possible approaches to solving one issue. It will also help you mature your thinking by exposing you to the various tradeoffs which programmers have to face – performance vs. human readability vs. support on different devices etc.
II. Thou shalt try implementing things thyself first
It is very tempting to run off to get a library/plugin each time you have a decently complex thing you want to make. Doing so too much is a surefire way to stunt your own growth as a programmer though.
As well as make future teammates curse you – they do not after all know why you chose the libraries that you chose. Actually you may end up frustrating your future self as your project expands and you run into customization difficulties or having to start digging into how the plugin works.
Always start thinking (like a senior engineer) about whether what you want to make can be implemented by yourself or if you can learn to implement it. Then, think about whether the time savings from using someone else’s code will outweigh the benefits you would gain from programming things yourself. (See this article about technical debt for a better explanation).
Especially if you’re doing things on the front end, many times you really don’t need to use someone else’s code to get to where you want. Bootstrap can be nice but the code can usually be done by yourself. Always start by thinking whether something is within your reach (or with a bit of a stretch) rather than immediately looking for someone else’s solution.
III. Thou shalt choose your libraries wisely
The above does not mean to avoid libraries entirely. In fact most companies will in some form or another use external libraries / plugins in their code. However, a bad engineer installs plugins just based on what they are supposed to do on the label, a good engineer investigates before installing.
All the above are necessary considerations which you should evaluate before installing something.
- Is the library/plugin well maintained?
In particular look at the date of the last update. - How many stars (GitHub) / reviews does it have?
Safety in numbers applies in programming too. - How big is the overall library?
Each extra line of code is one that needs to be downloaded and processed by a machine. - Does it have good documentation?
It’s own website, examples in a GitHub repository are all pointers. - Do you really need it?
See point II above.
In addition, each field of programming has its own “A-list” libraries / plugins. Advanced Custom Fields for WordPress, Moya for Swift etc. If you’re beginning you won’t know them though and these often come only with experience and working in a team. If you are unsure just be wary of the above bullet points when considering whether to install someone else’s library into your code.
There’s a long road ahead of you
So after writing all this and exposing myself as a shameless 90s boy I want to reiterate that yes it is possible to learn programming by yourself. It is however a long road ahead.
If I had known and understood the four points above though – I think that my own road would have been a bit shorter. Which is why I wanted to write this piece to help people have a smoother journey to becoming a programmer.
If there are any questions that you want to ask or for me to write about, please leave them below in the comments.
1 Comment
by Kaung Kyaw
Hello Austin, I am a kouhai MEXT scholar from Myanmar. I checked your blog in search of some wisdom for Shukatsu (I did find some), and also because I am interested in starting a blog too (even though I still have a long way to go), I liked this section very much that I thought I would drop a line; kudos for the buffalo metaphors. You have been a very good example for fellow MEXT students and this blog and especially this page proves that more. I guess the main obstacle in my learning of programming is to find the motivation to put in enough hours until I get a good understanding of how things work. I will also make sure to check out the resources you recommended here. Keep up the good work! 😀