Things I wish I knew before starting to code

Things I wish I knew before starting to code

A lot of people want to get into coding because of it’s gowing value as a skill in any discipline. This seems like a daunting task at first but if you keep going you will quickly realise that there is a lot of material and training out there which is just waiting to be picked up by the avid learner. Programming is like a giant staircase you need to climb and it is way more rewarding to focus on the little steps that you’re climbing than to look at the top of the stairs to see what the professionals are doing. Advanced programming always looks like black magic even to experienced users, because there are myriads of different branches and techniques out there and not one single person knows all of them. I frequently look around the office and 90% of the time I have no ideas what my colleagues are up to. Even if you don’t make it up there even understanding what is possible in coding might help you get a better grasp of how experiments can be designed to get the most valuable output. So just focus on the little steps and make a bit of progress every other day and before you know it you might be able to call yourself a coder. The problem when teaching programming to yourself is that you lack the counsel of more experienced programmers to guide you through the process. I am by no means at the end of my learning curve or can call myself a professional. However, here are a few things I wish someone had told me before I started to save me some of my frustration while climbing the staircase that is coding.

The Life of a Programmer

Before diving into programming itself it might be worth knowing what the programming life looks like. Some people are under the wrong impression what coding actually means on a day to day basis. Also just being aware of the struggles when starting we all have encountered might help you through the experience.

Before I started one of the first quotes we were shown was by Samuel Beckett

“Ever tried. Ever failed. Don’t matter. Try again. Fail again. Fail better.”.

This concept has proven to be very true in my experience. Be under no delusion, you will fail a lot. You will learn to expect failure and be surprised if something works and that is completely normal. Every time your program fails and you get a different error you fail a little bit better. Eventually it will run smoothly before your eyes, littering the screen with output and the feeling of accomplishment will be incredible. Overall the number of errors you encounter and thus your productivity will fluctuate a lot. There will be days when nothing seems to be working or you might actually break your program and that is fine. There will also be times when you are reach a flow and countless hours rush past without you noticing. However, putting in more than 8 hours of productive work will be very difficult as a high amount of focus is always necessary. Some of us don’t really abide by the 8 hour day and work nightshifts or intermittently during the day which can also be very productive. Find your productivity sweet spots during the day and make good use of them. Also we all get distracted during work. It’s fine to browse different sites on the side but one can get easily lost in some rabbit hole. A 25 work to 5 minutes of break rhythm has shown to be very efficient. Over time you will also get better at focusing for long stretches at a time. Everything gets easier over time in programming. Don’t get frustrated in the beginning.

Programming is no black magic and programmers are usually no wizards. Not everyone knows every command by heart and coding is no vocabulary test. It is better to know what exactly is possible and where to find it and then simply google the specific problem. Writing a program often is like choosing the nicest bouquet of flowers from the neighbourhood gardens you find on google. Bundling together different functions from other programs and binding them with your own code is usually a quick and efficient way of arriving at a solution. If you can’t find your specific problem anywhere there are most commonly two options: Either you just had an idea nobody ever had before or you’re looking at it the wrong way. For me personally it always the latter.

Programming Life Lessons

There is a few things everyone has to learn very early on the way. To catalyse the learning process I tried to come up with a few hints worth knowing before getting started.

• Focus on one language before getting started. This is a very important choice and depends on what you’re trying to do. A good generally language is Python which is used and loved by many. It is very readable and doesn’t have a learning curve as steep as other languages. I would recommend R if you are trying to learn coding as a statistical tool. Matlab is the programming choice of most mathematicians and is also very helpful when doing image analysis. C will force you to learn a lot about computing architecture but also has a very steep learning curve. If you don’t know which one to go for Python is probably a good call.
• Text editor choice is key. This is where you will live on most days coding. Sublime is one of the nicest text editors on a graphical interface and is used by most programmers today. Vim has no graphical interface and only function in terminal. It has a steep learning curve but can be extremely powerful in capable hands. Check out our other report here to see how to become a professional in vim. There are a few others out there and I recommend reading a few top 10s on the subject before choosing one. Once you have a favourite text editor it is probably a good idea to print out a cheat sheet with all the hotkeys and pin it next to your screen. Hotkeys will not only speed up your analysis but number of hotkeys you use directly correlates with respect from peers.
• Think before you code! Before wildly hammering away on your keyboard you should consider writing pseudo-code which might help structure your thoughts. Pseudo-code is essentially just writing out what you want your program to do and where in clear text. You should also think about whether you have the necessary computing punch to pursue your goal. You should have approximately as much memory available as the size of the file you are processing. Otherwise you have to find a work around like processing every line in a file individually. Consider also the time necessary. If you need to process 1000 files and initial scripting implicates that one file takes roughly one day should you really go ahead? Has someone else attempted to code something similar and can you learn from their approach? These are all questions you should ask yourself before you begin to write a script.
• There are multiple stages of error handling once your program inadvertently spits out one. Your first go to should always be look at your code thoroughly and try to google your error. If that doesn’t help it’s ok to take a walk or a little break to clear your thoughts. Then you can think about asking for help on pages like stack overflow and seq-answers. People are usually really nice even to newcomers if you play by their rules (don’t post a question until you have assured that it hasn’t been asked before). Then you can go and bother your peers or even PI about your program, but consider that looking and understanding someone else’s code takes a lot of time and effort.
• Change one thing then test. Instead of making a lot of changes to your program and then being lost to where the error occurs you should make minuscule changes and test very frequently. This makes error handling a lot easier.
• Readability goes over efficacy. When you write a program make every variable and function name as descriptive as possible. Try including the file-types into the names like integer or string. Also separate logical blocks of code and introduce a lot of white space to separate lines of code. This will ultimately lead to longer scripts and will not look efficient, however it makes error handling and orientation within your code way easier.

Organisation Makes Everything Easier

You can make your life a lot easier if you follow a few rules which seem tedious now but will come in handy later on.

• You should adhere to file naming conventions and make files as descriptive as possible. Don’t use white space as a word separator because it confuses a lot of programs. Instead use capitalisation or underscores to separate words.
• Make a lot of folders and sort files constantly. Nothing is worse than an overcrowded folder with a plethora of different output files none of which make any sense yo you. Simply sort different files into a lot of folders to avoid confusion later on.
• Comment your code. I know this seems unnecessary but nothing is more frustrating than coming back to your own programs and having no idea what it does or what it takes as input. It’s good practice to describe in the beginning what goes in and out of the program as well as how it is used and where. This will also help other people to use your code and they might be very thankful
• Back up everything. I don’t want to tell you how often I have deleted scripts by accident and thus lost days if not weeks of process. It seems unlikely but it occurs more often than you think especially in the beginning. Make a little back up folder with your scripts and regularly copy your progress in there.

Best Coding Practices

Just talking about coding is a little bit dull, so I made a little script demonstrating how to put some of these rules into practice. Additionally it will be formatted in a way that is considered readable and there are a few tips and tricks I included to make your life in Python easier. Check it out on our GitHub

Written by Nicolas Arning