Questions on the topic of how and where to start coding are not uncommon. I get them sometimes, and maybe you have been asked (or have asked them!) as well. This text is to help both the people asking and the people being asked.
I myself started with hopes of becoming a game developer when I was in my mid teens and failed miserably. I didn’t know what to expect but I found it really hard so I gave up. Some years later I figured it out and now I’m working as a developer.
The aim of this text is to help you make better decisions, not make those decisions for you. I want these words to bring you some confidence in your journey towards learning or helping people.
What is programming
Coding (programming, developing software, or whatever you feel like calling it) is two things, according to me. The first and obvious one is to give instructions to a machine and make it do things. Secondly (and maybe more importantly) it is to control complexity.
No matter how you twist it we are usually solving hard problems. Things may seem easy from the outside, but complexity is always there and making that complexity understandable is key.
Have a goal
Like with most things you want to learn, it’s good to have a goal: something to aim for and measure against. Just jumping in and taking the nearest book or tutorial is going to be tough and feel like a chore pretty fast if you can’t see the light at the end of the tunnel.
Think of something simple. Now think of the simplest version of that thing you can imagine. That is what you should build. It should preferably not need network access or a database — the more you can take away to make something you can show and use the better. The feeling of building something from code to usable application should feel satisfying. If it doesn’t, then maybe being a programmer is not for you.
Which programming language and tools to use is an easy question to answer: just use the default, most used ones. So if you want to learn how to program iOS applications, then you should learn Swift and Xcode, and if you prefer Android you should learn Kotlin and Android Studio. I would recommend asking someone with a little experience about this.
You should avoid new and hip things as they may not be as well documented and can have some kinks that are trivial to an experienced developer, but may be very frustrating for someone new to this whole thing. These new things are something you can explore later when you are more comfortable with coding.
Start as soon as you have made your choice of what you want to build. You will make mistakes and you will be frustrated. Remember that feeling dumb is okay and no one understands everything at the start of their journey.
Try to find someone to ask when you don’t understand. Don’t be afraid to ask for help but make an honest attempt to find the solution yourself first. When asking make it as simple as possible for the person to help you, you should prepare the question with an isolated example.
Just keep going. Things will get easier and before you know it, you will be the one helping people who want to learn how to code.
I have three pieces of advice for you that I consider to be the basic building blocks of good code. Of course these are not golden rules that should never be broken but having them as strong guidelines will hopefully help you in making good decisions.
Don’t worry about it if you haven’t started to write code yet or if you haven’t grasped the basics yet, just keep writing whatever you can until it works or breaks and keep going until you feel like you could use som advice.
Naming is key
Naming things is often claimed to be the hardest problem in programming and I couldn’t agree more. What you name things is very important, since names tell the reader what is happening.
Sometimes it is really hard, but I believe it is worth taking the time to come up with a good descriptive name. Every time you do, you will get better at it. There is usually an API guideline or other naming conventions document for the language you choose that will help you name things correctly.
Make it small
A favourite quote from the book Clean Code by uncle Bob is:
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.
I like this advice but I would like to generalise it to include data types and classes. When you try to make something small you force yourself into thinking with a constraint on how to break your code into small and understandable bits.
Doing this puts the reader (which is probably going to be you most of the time) in control as they can choose to look at the implementation if they want or need to.
A test is a chunk of code that proves your code hypothesis. The main reason for writing tests is to go from the thought “I think this code works” to “I know this code works”.
As soon as you can handle the basics you should try Test-Driven Development. It is the concept of writing tests for your code first, then writing the code that will make these tests pass.
Learning to code is hard. There is always going to be something you will not understand and you will feel like you are not good enough. This is what we call Impostor Syndrome: the feeling that you are not good and you have only gotten this far because no one has found out how bad you really are.
An important lesson that I have learned is to not be ashamed of what you don’t know. Knowledge you don’t have is not an obstacle, but an opportunity to learn.