1. Not Compiling Their Code

Now this sounds a little weird, but I actually see this a lot. Students will write up line after line of code without compiling or running it once. Then when it’s time to execute the program they get swamped with syntax errors.

They painstakingly fix all the syntax errors, it compiles, then what happens? Runtime error, the dreaded segmentation fault. So they fix the memory issue and then get a logic error! The program doesn’t even spit out the right result. But at this point, they can’t tell where the problem is because they’re written so much code that “should work”. All that debugging for nothing.

Compile early, compile often. If you're constantly running your program, testing your output and making sure everything works step by step, you save yourself so much time and frustration. It’s like making a curry. If you aren’t constantly tasting your curry as it’s cooking, how do you know if the end result is going to be any good? Maybe it will taste good, but you can’t guarantee it. Good chefs get consistent results because they’re always tasting their food at every step of the process. Good programmers get consistent results by always testing (tasting) their code.

2. Not Using Their Search Engine

As a software engineer, the internet is your best friend. Often I’m helping a student they say something like "how do I reverse a string in [insert programming language]?” I will say, just g**gle it and use the first result from stack overflow. They then say "but isn’t that cheating?"

We are standing on the shoulders of the giants. Just the fact that we are coding is leveraging all the engineers that paved the way before us, so it’s okay to ask G**gle for some help. Being able to read documentation or just find a solution on stack overflow is probably the most important skill to have as a software engineer. That’s why I encourage my students to ask g**gle before they for help.

Eventually there won’t be a teacher telling them exactly how to solve a problem. It will be a client or a project manager asking them to implement and all they’ve got is their computer. Maybe there are other engineers in the company they can ask for help, but if they show up without attempting to find their own solution, they’re going to look like a massive noob.

There’s this weird misconception among students that g**gling = cheating. It probably stems from the strict anti plagiarism rules that universities enforce. I have seen so many assignment specs that read “you may not copy any code from any outside source”. Which is fair enough, but the assignments they’re being tasked with consist of many smaller, solved problems. Are they asking the student to implement an algorithm, or invent one?

3. Premature Optimisation is the Root of All Evil

This is a classic quote in the software community originally penned by Donald Knuth. This is relevant for veterans as they need to be mindful of allocating time effectively - devs are expensive and budgets are usually tight. But it’s also relevant as a beginner, because you just can’t anticipate problems you’ve never experienced before.

A lot of beginners are concerned with the “right” way to do things. Don’t get me wrong, I actually think that’s a good mentality which will help them avoid picking up bad habits. But I see students get caught in analysis paralysis, spending a lot of time trying to avoid a mistake. But they don’t know what the consequence of that mistake is, so the optimisation has no context

My advice to beginner programmers is to just make stuff work. If you think your code is janky, it’s probably fine. And if it’s actually an issue, it will become apparent and you'll learn from it. Fail fast and often.

Personally, I’ve worked with over-optimised codebases and unoptimised spaghetti codebases. They both slow you down, but the spaghetti taught me what necessary and the over-optimised taught me what wasn’t.

So that’s the top 3 Mistakes beginner programmers make. The actionable items are:

• Compile Fast and Often
• Use Your Search Engine
• Write Jank and Learn From the Consequences