My Profile Photo

Notepad.ONGHU

Knowledge, without memory, is useless

• on | Programming | Personal |

10 + 1 Tips for Beginners who are Starting Out

I noticed and responded to a Tweet that simply asked – what tips would you give to beginners who are just starting out (in coding/ programming)?

I responded with 10 items that came to my mind and I thought it would be good to add a bit more detail and context into a blog post. Also, I would say that these are things that worked for me as I grew as a programmer. Things have naturally changed in the 20 years since I started working as a programmer, so not everything is perfectly relevant but I’d like to share these ideas any way. So, here goes.

Background

The world of programming has grown very fast in the past couple of decades – new hardware architectures, new CPUs, new programming paradigms, new programming languages and methodologies, new databases, and so on. Old ideas have given way to newer ones and again, newer ideas have given way to ideas based on very old concepts.

Given that, we need to keep learning… and most of what I note below is about different ways of learning and discovering information.

1 – Don’t be afraid

Learn by doing – if you’re a beginner, don’t be afraid. Code and see what happens – of course, don’t do this on systems where you can cause serious damage (e.g. delete a production database, launch a nuclear missile, etc.). Write a program, run it and see what happens. If it crashes, it crashes! Look at what the error messages say, read the warning signs, and then change things and try again.

2 – Correctness > Idiomatic

Languages such as Ruby have an idiomatic way of writing code and you might be ‘looked down upon’ if you write code differently. However, I would always take code that works over code that does not. First, get it working and then progressively refine the code to make it more idiomatic, more succinct and clearer. It’s easier to write, read and debug simpler code.

3 – Don’t be scared of code from ‘seniors’

Depending on where you start, you might encounter the larger-than-life senior who has written a lot of code and seems to be able to have a solution to every problem. Their code might also look complex because experience has taught them so. As a friend once told me, “The way to work with giants is to not try to measure their girth but instead to stand on their shoulders”. That’s what you should try to do. Approach the seniors and talk to them – tell them what you learned from their code and ask for help where it wasn’t clear. There is a very good chance that they would be happy to explain to you why they wrote code a certain way and what considerations motivated them… that’s one of the better ways to learn by asking and listening.

4 – Don’t adopt “best practices”/ “design patterns” because they’re cool

Best practices, principles, methodologies, design patterns, etc. come from a distillation of experience. Don’t force yourself into adopting these just because ’it’s cool on the resume’. Once you’ve spent a bit of time coding and doing some of the other things here, you’ll see what problems these solve for you and you will appreciate them better for what they do for you.

5 – Read, and read ahead

For me, this was one of the things that helped the most. I strongly recommend that you read, and that you read random programming-related stuff even if it seems that it has no relevance to what you’re doing. Read without bias! Don’t force-fit it to your current problem but use it to build awareness. Read a bit about everything – graphics, OpenGL, databases, SQL, security, encryption, Javascript, HTML, CSS, R, Python, Ruby, FreeBSD, Word, cloud computing, etc. The idea is to soak your brain into different things without worrying about applying it. Each exposure opens your mind to new experiences and new knowledge. Even if you don’t need it yet, you will realise when it becomes relevant. Critically, read about other programming languages (i.e., languages you are not using right now) and get ideas on why people like (or hate) those languages.

One of the things that I enjoy is doing a shallow scan from a deep resource. I mean I love to scan a book about a new programming language but mainly read the preface, the table of contents, the first few chapters and flip through the rest of the book. While this will not (by any stretch) make an expert (or even a novice), it gives me enough ideas about why this language is used, what it roughly does, and what kinds of things it does well. I’d recommend reading not just blogs but also books and tutorials if you can find them.

The most important thing here is to be aware of the existence of ideas, technologies, frameworks – so that you are able to pull them into your universe when you really need them.

6 – Read the warnings

If you’re using an IDE/ compiler that throws warnings about your code, turn them on – read the warnings, and when you get the chance, go out and read why that is a warning. What is the hazard that the message is trying to warn you against? Why is that hazard important? This technique will automatically help you get better. If you are unsure about why there is a warning, find someone and ask them. Check with a teammate, a relative, a senior, or search it up on the internet. If possible, turn warnings to the highest level allowed in your tool and aim to minimise the new warnings that your code generates. Some are easy to fix, and some might require a deeper change. If your language also has built-in (or easily added) support for static code analysis (e.g. Lint for C/C++, Rubocop for Ruby), turn those on and see what they show you.

7 – Engage in code reviews

If your code is reviewed, don’t be defensive in code reviews! If someone asks you to change something and it’s not clear why, probe to understand the rationale for the comment so you know why (it’ll help you become better). Also, explain why you did something in a specific way – maybe, there was an edge case that you were trying to handle and the reviewer is overlooking it. Your conversation in code reviews will help the reviewer understand your context and point of view, and might result in them recommending something specific that could aid your understanding.

8 – Practise, practise, practise

Practise, practise, practise – there’s no better way to get better with code than to code. It does not matter what you code but trying to solve ‘every day’ problems with code will always teach you something new. See how others are solving the problems, read their code, try to write your own.

9 – Join conversations

Join mailing lists of topics and technologies you work with (e.g. SQLite3, PostgreSQL, Ruby, Rails, …) so that you hear how “veterans” in that technology think & discuss. It also shows you the kinds of problems people solve with this technology and the issues that they are facing. It also might gives you a heads-up on problems with new releases, etc. when a lot of people complain. In a similar vein, you might want to follow specific people on Twitter so that you can hear their thoughts directly. I remember that I learned a lot in my early days on mailing lists and news groups about OS/2, C Programming, etc. The people, some of whom were pedantic, taught me a lot.

10 – Learn more tools

You will hear these 2 things in technology quite a lot:

  • Use the correct tool for the correct job
  • If the only tool you have is a hammer, every problem looks like a nail

Eventually, this means that you need to learn more tools! If you only know C programming, you will try to solve every problem in C. That doesn’t mean it’s not possible – it just means that you run the risk of not being most effective/ productive when you want to do something like transform a single file once from one format to another. That might be a task better done in a different tool, e.g., a scripting language such as Python, Perl or Ruby.

Plus 1 – Have fun!

Above all, have fun. That is critically important. Discovery, learning, programming, reading, participating in code reviews, discussing and sharing… all of it works better if you don’t think of it as a chore but instead have fun doing it.

If you have any ideas to add to the list, please share in the comments below.

comments powered by Disqus