Don't learn to code

This headline must seem a joke to you, coming from someone who has done the exact opposite of this advice. But hear me out!

Recently, I was listening to a conference speaker make the point that every scientist should pick up coding skills, even if they are rudimentary. This stance reminded me of my own views a few years ago (see this post on CodingForChemists).

I still stand by everything I wrote back then. But it’s not the whole picture.

Learn coding for leverage

You should learn coding.

For personal reasons, it always makes sense to learn coding

Coding ability provides you with leverage. You can produce things that scale. You can create services that make money while you sleep. You have the capacity to turn an idea into a prototype or a product without much capital.

But all of that is only true if you are somewhat proficient at coding. This is a long journey.

The problem is not that you cannot produce useful things before you are proficient, the problem is that you cannot create reliable things, and that you may bring about collateral damage with your unreliable programs.

The rudimentary coder

In the beginning, I wrote bad code.

Of course I wrote bad code. At that stage, I knew the basic functions I needed to get the job done, but not how to structure a program or how to do things efficiently. Still, those scripts worked, and they saved me some time.

In the beginning, I caused collateral damage.

Collateral damage usually comes about when you take for granted that things work in a certain way. A way this is “logical” to you. These are the unknown unknowns of coding. Every coder will have their own experiences with this. Mine is a backup script that deleted half of our group’s network storage. How did that happen?

I was preparing a short bash script that would take care of backups for me. The procedure would look roughly like:

1. Create a new directory /Volumes/mount_nas to use as a mount point
2. Mount network drive
3. Compress my Documents folder into a .tar.gz file
4. Copy the compressed file to the mounted network drive
5. Unmount the network drive
6. Delete the directory /Volumes/mount_nas used as a mount point

If you have some experience with Bash, you can probably guess what went wrong here. What I didn’t know in my early coding days is that Bash scripts don’t terminate when a command fails. This is in stark contrast to Python scripts, which terminate when an exception is raised (and not deliberately caught). So if unmounting the network drive (5) fails, then deleting the mount point (6) will erase contents on the network drive. And that’s exactly what happened. When I caught it, quite a few folders were already gone. Luckily we had backups and restored everything.

The point is, every coder experienced with Bash would know to safeguard commands like:

...
<essential command> || exit 1  # script will terminate if <essential command> fails
rm -rf /path/to/mount/point  # not executed if <essential command> fails

I didn’t know, because I was used to the Python way of thinking. This is how, as a coding apprentice, you can cause collateral damage. To this day, I am slightly uncomfortable with writing bash scripts that contain the rm command.

There are more problems with the rudimentary coder, if the work is supposed to be shared with others. Project structure, documentation, and version control become important as soon as your project will be used by others (including future you!). In general, the rudimentary coder cannot be trusted to produce reliable, production quality code. Still, they have a useful function.

The subject-matter expert / rudimentary coder serves as a valuable translator

If you have both expertise in some non-CS subject, and you are able to code on a rudimentary level, you can serve as a translator between the subject-matter experts and the coding experts. Any larger company will have both of these types, but the subject-matter experts speak a different language than the coding experts. With exposure to both sides, you can facilitate the interaction by filtering out noise for the coders.

Never forget about opportunity cost

Coding is a highly useful skill, shouldn’t everyone learn it?

We tend to forget about opportunity cost when evaluating what skills we should embrace. To be plain, every minute spent on learning coding is a minute not spent on learning other things.

Now coding is an enabling skill. If you are not going to become a software engineer, you will use coding to multiply the impact of your core skills. Which means, you still need the core skills. Whatever the core skill in your profession is, coding can not replace it.

If your curiosity lies elsewhere, don’t let anyone push you into learning coding

Many STEM grad students today feel a pressure to learn coding. I hear from many peers that it is something they feel they should be doing. Even the ones who have concluded that it is not for them, can feel guilty about that decision. If you are predisposed to coding through your skills and interest, then definitely go ahead and learn. It will be a long, but rewarding journey. But if your curiosity lies elsewhere, and you are honing your core skills instead, by all means, don’t let anyone push you into learning to code, just because it has worked for them!

Key points

• Learn coding for leverage and unlock new avenues for your work
• Rudimentary coding skills are detrimental when used for coding
• Rudimentary coding skills are useful when communicating with coders
• Learning coding is a major undertaking and will take a lot of your time