This post starts with a disclaimer. In no way do I profess to be an expert programmer. I am 99% self-taught, with the rest coming from a month long internship at StataCorp in Texas, and the many pestering emails and questions I’ve asked Stata developers over the past few years. And of course advice from the far more experienced pot of academic programmers who I have met and worked with since I started my career.
My favourite Stata command
Without doubt, my favourite command in Stata is
viewsource. I’m yet to meet anyone else with the same favourite command. It lets you view the source code of a command, simple as that. Given that Stata is essentially proprietary software, there is a substantial amount of Stata’s source code which is open source. You don’t even need to use the
viewsource command, you can delve down into the installed files and open them up for yourself,
viewsource is merely a convenience command. To me, it is the single easiest way to learn…look at others code! Especially the code of professional developers.
You can’t be a good programmer without being curious, and quite frankly, nosy. You must always want to improve, and even when a task is finished, you are quite happy to completely start again if you can shorten or quicken your code. If I think of a way to improve a program, generally I’ll scrap/adapt the old version and start again until it’s better, otherwise I won’t sleep (ok perhaps a slight exaggeration…but I have had Stata code dreams…more than once). I’m hoping it’s not just me.
Regardless, programming is the main reason I love my job. It’s the part of my job I most enjoy. I genuinely get a huge rush when I get something difficult working, be it a complex likelihood correctly maximising, some new prediction code doing something 10 times quicker than it used to, or two lines of code doing what 20 used to do. Messy, inefficient and downright ugly code really pisses me off. I’d never call myself a perfectionist, but the closest I ever get to being one is in the realm of programming. But something I love about programming is how personal and subjective it is. Yes of course an implementation is generally right or wrong, but how we get that (hopefully) right answer can always be achieved in an infinite number of ways. And that comes down to the programmer. I really enjoy it when other people show me their code. However, they tend to get nervous, mainly because they think I’m about to call them an idiot and tell them it’s all wrong… I only do that to close personal friends. I enjoy looking at others code because I find it fascinating how every single person will have approached the same task in a completely different way! You’ll always learn something, be it something to do or not to do, but it’s still learning and improving. Though to be honest, if your code isn’t indented how I like to have my code indented, then we have to fix that first…but that’s my issue.
Programming doesn’t always go well
My main collaborator Paul Lambert once started work on a command to implement the delta method, to get standard errors for complex predictions. Now Stata comes with the very powerful
predictnl command, but it can be slow sometimes. So off he went to write his own. Of course, when you start a new command you must name it…he went for
quickpredictnl…you can see where we’re going with this. A few days later he had his finished version. He did a speed test. And what happened? Of course, his was slower. I laughed…a lot. Note, I have asked his permission to tell this story, and he very happily said yes (in truth he said ‘yes you b*****d’…you can tell we have an effective working relationship based on mutual respect), but even if he didn’t I’d still tell it, it’s just too funny.
We all get stuck when programming. You know exactly what you want to do, but you can’t remotely figure out how to implement it. Or there’s a bug, a massive hornet sized bug, and you have no idea why. What do I do when I get stuck? I swear at the computer (a lot - and I grew up in Northern Ireland, so I know some good ones). So much so that I usually have to shut my door when programming something particularly challenging. It’s very easy to get disheartened by getting stuck for extended periods of time, it’s taken me days to figure out something before, but I’m so stubborn I’d have carried on for weeks. Not everyone is as stubborn as me (thank goodness), but one thing to learn as a coder is knowing when to stop coding, to step away and have a break. If you ever want to cheer yourself up, then look back at something you programmed a few years ago - and be prepared to go on a journey starting with embarrassment at how awful at coding you used to be, to pride at what you know you can do now.