Being the Worst Programmer at Work

I started a new job in early January. For the first time in my life I am getting paid to write code. I knew when I started that I would be the worst programmer there. Being the worst programmer at work is an interesting experience; you learn a lot, but you also look like an idiot on a regular basis.

In fairness, I am not actually the worst programmer in the place. There are hundreds of people who work for the company, and only a handful of them are programmers. So really I am one of the best programmers! I just happen to be the worst programmer among the programmers.

That sort of makes sense. I don’t think the company hired me for my programming skill. They never even tested my programming. I was just some kid who worked with data and knew some programming, and that combination seemed valuable whether I was a brilliant programmer or a terrible one. It just happens that I am somewhere in the middle (and I put in a lot of effort), and as a result I acquired the dubious distinction of “worst programmer among the programmers” instead of “best programmer among the non-programmers”.

Things I Have Learned About Programming

As the worst programmer, I have had my fair share of “learning experiences”. I will start with the bad.

When I started, I didn’t know how to make a pull request. I knew what a pull request was, but I hadn’t made one before. I avoided the problem for a few weeks, but eventually I found myself modifying someone else’s code, and I had no choice but to ask for help. It was somewhat embarrassing when I realized that all I had to do was push to a branch and click “make pull request”.

More embarrassingly, just last weekend I spent hours convinced that someone else’s code was an incoherent mess of missing imports. At the top it would say something like import specialFunction from './thisfile'. But specialFunction was nowhere to be found in './thisfile'! I even messaged my boss about the problem, only to discover a few hours later that I didn’t understand how export default works. For those few hours, my boss genuinely thought I didn’t understand how modules work. The very next day, I proposed a change to the same code where I set a value equal to the return from a setTimeout() call. Someone had to politely tell me why that wouldn’t work.

I find that I make mistakes like that last one pretty regularly, especially when I am programming in JavaScript. Twice now I have completely forgot about error handling. I would like to say that I won’t forget a third time, but I will.

My other “learning experiences” haven’t been quite as embarrassing. Before starting this job I knew basically nothing about Node, Docker, or Kubernetes. Yet a few weeks ago I wrote a Node app, made it into a Docker image (or container… I don’t know), and deployed it with Kubernetes (well, a sysadmin deployed it while I watched). The truth is that I still know almost nothing about those three. Node is a JavaScript thing that lets me act like I am writing Python, Docker is this thing that makes deployment easier so I follow a tutorial that tells me what to do, and Kubernetes is some deployment thing that I really don’t understand. However, I know more now than I did a few weeks ago. Baby steps.

But the most important thing I have learned about programming since starting at this company is that even experienced developers make stupid mistakes. They send something to the wrong endpoint. They use the wrong variable. They forget to include something, or they handle some case incorrectly. If I know what I am looking for, I can usually find the problem and fix it despite being a worse programmer.

Doing More

I may be the worst programmer at the company, but there are a lot of things that companies do that don’t require expert-level programming. If I want to add value, I just need to find those things and do them. Fortunately, this has proven to be exceptionally easy. As it turns out, companies are imperfect human-run organizations, and so the opportunities are never-ending.

Companies don’t always need experts; sometimes they just need people who are “good enough”. I am good enough at a lot of things well outside the scope of my normal work duties. For example, I am good enough at JavaScript to help the designers build custom, interactive visuals. I also am good enough at law to be able to assist with General Data Protection Regulation (GDPR) compliance.

I see discussions online about how to get a job as a data scientist, and the advice always revolves around becoming a better data scientist. That seems obvious, but I am not sure that it is always correct. I think companies realize that they need people who can do just a little bit extra. Some companies don’t need the world’s best data scientists; they need good enough data scientists who can also do something more.

So why am I writing all of this? I am not sure. Maybe some other programmer or data scientist will find it comforting to know that it is okay to be the worst. Maybe there is some advice buried within this story that people can learn from. I don’t know. Take from it what you will.