I may have previously mentioned how my days typically consist of programming. I have problems that I have to solve, I then have to think about how to solve them, then write some code to do just that. In my last post I mentioned how I was working on writing some MCMC code, and was finding it difficult to keep it very general so that it is highly reusable. Yesterday I got that code working and began doing so more intensive testing which revealed that there is another feature that I need to add, but it should only take a few minutes to do that thanks to the parameter file parsing library I’ve created. This got me thinking this morning about the things I’ve learned since I began programming, and I thought I’d share some of those as they may be useful to others.
1. It’s hard to write good code
This was the entire topic of my last post, so I won’t say too much about it. I mention it here because when you’re writing a program and things are working like you want them to, just remember that programming isn’t easy. People who are really good at programming have been doing it for a long time and gone through a lot of effort to learn how to write good code. So, don’t get down on yourself, just try to learn from the mistakes that you will inevitably make. That’s how you’ll get better, and eventually you too can be one of those really good programmers.
2. Stack Overflow is your best friend
Let’s face it, in spite of what our moms and elementary school teachers may have told us, we’re really not special snowflakes. However, that’s actually a good thing! If you are having some problem with a program you are writing, chances are someone else has had the same or similar problem and asked a question about it Stack Overflow. This allows you to do a quick Google search, click on a Stack Overflow link and likely find a solution from someone who is a really good programmer. This also helps you learn a lot of tricks for solving problems and can make you aware of features in a programming language that you may not have been aware of previously. I wish Stack Overflow had been around when I first started programming. I would likely be a better programmer now if it had!
3. Github is your other best friend
In my efforts to become a better programmer and de-clutter my hard drives, I’ve recently started making use of Github. This has solved several problems I found myself having. First, you are less likely to end up with duplicate source code files all over your hard drive. Instead, you have the folder associated with your Github repository, with sub-folders for different pieces of code/projects. As long as you do all of your development there, and use branches for adding features you can make sure to always have just a single up-to-date source code file. Second, you have a backup of all your work! This is particularly useful, because you never know when something on your computer may fail, or you just need to work on some code on a different computer one day. As long as you’ve made sure to git commit and git push, you have the latest version of your work accessible to you anywhere.
4. Try your best to write reusable code
It’s very easy to fall into the trap of writing code that solves one very specific problem. After all, you then have a concrete goal in mind. However, this isn’t the most efficient way to program. You will likely find yourself writing some other code at a later time which is really just a slight tweak to your previous code, and if you’re in the mode of writing one program per problem, you may not even think to go back and just tweak your old code. So, whenever you sit down to code, get in the habit of asking yourself if you may need to solve similar problems in the future. If so, try to keep the parts of the code that may need to be very specific to a particular problem separate from those that will be the same. An example that comes to mind from my experience is calculating the galaxy power spectrum. The steps involved are almost always the same, but the input file formats can be drastically different. So, by creating some template function called inputFileRead, which should only need to take the file name as an argument, then you can simply write an implementation of that function to handle specific file formats (I’m using the same idea with my MCMC code, where the model implementation code is kept separate allowing me to use the same main code, just writing specific model code for the situation).
5. Create local /bin, /include and /lib directories
If you are keeping your code as general as possible, you might want to have certain functions in a library which would need associated header files. Sometimes you may have written a program that you’ll need to run a lot with out having to change anything. By creating a bin directory for the codes that can be run in many different situations, and include and lib directories for reusable functions written into custom libraries, you can then add those directories to your system path variables. This will allow you to easily access those things later on. For example, my parameter file parsing library is something that I use with pretty much every piece of code I write. It would have been a pain to have to either copy it into different directories, or specify the full path every time I needed to include the library in some code. So, I created the mentioned directories, and I can simply link the library like normal with a -lharppi, and #include <harppi.h> in the code. I also have a simple histogram code (which needs to be rewritten to use harppi) which I need to run frequently, and a covariance calculation code that I need to run frequently. By having them in my local bin directory, I can access them from anywhere on my system without having to copy them into different directories.
6. When your code doesn’t work, it’s because you did something stupid
Sorry, this is just the way it is. Sure, there is a non-zero probability that you’ve found some bug in the compiler you are using, or some library you are using, but its more likely that you are using the wrong variable as an array index somewhere, or are dividing by the wrong thing, or you have a typo somewhere. But like I said before, we’re not special snowflakes, so more than likely the bug is in your code. We’ve all been there. You’ve spent days writing countless lines of code. You compile it and everything seems fine. Then you run it and you get some memory exception, or garbage output. Then you have to debug, and when you see the mistake you sigh. You think, how could I have been so stupid, so careless. But, we’re all human. We make mistakes, and when your writing line after line of code, mistakes are bound to pop up.
7. Learning is a journey without end
The simple truth, no one, no matter how smart they seem, knows everything, and those who act as if they do tend to know the least. The fact is that we are all always learning. I’ve seen comments on answer to Stack Overflow questions from people with high reputations on the site that essentially say, “Huh, I didn’t know about that.” While there are undoubtedly those who know more than you do, even they don’t know everything. So, just remember, strive to keep learning, ask questions of those who know more than you do, and don’t be afraid to admit that you don’t know something. The important thing is to always try to improve yourself.
So, those are a few things that I’ve learned. I hope that someone may find them useful. If you have any tips/tricks, or advice for people who may be just starting out programming, or for those who have been at it for a long time, but feel that they aren’t very good, share them in the comments!