Coding Sins

source

I loved this recent twitter exchange on coding sins, where programmers confessed to looking up code on the internet all the time. This was to protest job interviews in which candidates are asked to come up with some code off the top of their head, which is a bad idea for a number of reasons. The first is that the interview style probably doesn't correlate well with job performance, especially since there are now training courses to get you ready for obscure "whiteboard coding" interview questions. The second problem is how it impacts diversity in programming fields, because who do you think has plenty of time for cramming for these type of interviews?

Whiteboard coding interview questions haven't really been a problem for me as a research scientist or academic, but I found some comfort in knowing that I'm not the only one who continually needs to look stuff up when I'm coding. I think it's important that we're open about the stuff that we don't know, or more importantly, don't need to know to do our jobs.

Some have focused on the downsides of always having information at your fingertips, saying it makes us less likely to commit to memory information that we know that we can re-access easily. But as a scientist I'm always looking for things I can safely ignore. The scientific process is an onerous one when you try to account for everything. Parsimony, or the ability to explain something using the least number of inputs, is highly prioritized because each new variable means additional resources required to answer the question. When I'm coding I try to focus on the structure of what I'm writing and how to produce outputs that are compatible with other products, rather than memorizing syntax structures or complex functions.

I'm pretty open with my students that when they start out, they may be re-working other people's published code, and there's nothing wrong with it. Most often, nobody has done something exactly in the way you want to, so you'll need to tweak and sometimes even correct their code**. And in the process, you'll be learning to code yourself!

*Common stuff I need to look up: how to delete all but one variable in R, how to make a Python program executable from a bash shell, plotting commands in R...

** This generally works well, but it might lead to doing things in a way that isn't well-suited to your datatype, or doesn't produce output in a format that is most useful to you. In the beginning, the only thing that matters if it works and if it makes sense to you.