I am a dumb programmer: that's why I am good at my job

As a developer, I try hard to be very dumb. I don't write creative software. My software is not fancy either, it is very uninteresting. I get told by people what they want to do, and then I (sometimes) use computers to get that thing done. My software has to be boring, no-one cares about it. Ideally, it wouldn't even exist.

I don't do crazy maths, I don't write new algorithms, I don't implement databases or design programming languages. I don't make video games or discover new ways of processing data with ML. I don't invent crypto protocols nor do I make shiny UI animations.

I basically write distributed versions of memcpy: my software gets some input information, and returns some output information.

Note that I said "information", and not data. This is crucial. My skill is to figure out:

• what is the information is
• what its purpose is
• what its lifetime is
• how to best fit it into bytes
• how to move those bytes around

Imagine that a user wants to buy a product from the company I work for. This information could be encoded in many different ways: It could be a button press on a POS, it could be a barcode scanned on a mobile app, it could be a checkout button on a webpage, it could be a subscription.

In response, I usually have to process a payment and inform the user that an order was placed. This could be shown on a display, printed out on a receipt, displayed in a web browser, sent as an email. The data and delivery mechanisms are very different, the information is the same.

Here is what I think when someone asks me to build such a system:

• do other people need access to this information ( fulfillment, sales, accounting)? How are these people going to access it, and what part of the information do they care about?
• how quickly do stakeholders need to get the information? For example, the customer should get instantaneous feedback, accounting only cares about it once a year.
• what are the different things that can happen in the real world (these are not error conditions as far as the software is concerned)? Can a product be out of stock? Can the credit card transaction be declined? Can the email address be invalid? Can the mobile phone connection die?
• what happens if something in my system goes wrong? Will we want to retry? Notify the customer? Log an error log? Show it in a realtime dashboard? Track it in an issue tracker? Make a note for customer support?
• do other things need to happen once the order is placed? Do we need to update the inventory? Do we need to potentially place a purchase order to replenish the stock? Maybe create a shipping label and send out a tracking number?

None of the code that will actually run to make this work is going to be interesting. It will usually write some version of the information to multiple recipients (log files, databases, message queues, displays, web socket), check for errors, and do some more of the same. In fact, the simpler my software gets the information from A to B, the better it is.

I am a dumb programmer, and my software is very boring. That is why I am good at my job.