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 nor discover new ways of processing data with ML. I don't invent crypto protocols nor do I make shiny UI animations. Really, my code is very dumb.
Yet, I consistently create products of great value. Here is how I do it.
Ultimately, I write distributed versions of memcpy: my software either gets some input information, and stores it; alternatively, it receives a request for information, reads it out of storage, and sends it out.
Note that I said "information", and not data – this is crucial. To understand what information the business needs, in contrast to the data it actually processes, I ask a lot of questions:
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.
The business also requires a transaction log. The business needs to know who ordered what, when; it needs to know which inventory got sold by whom, to whom, for which price, at what time. This log will be used to create analytics, drive business insight, and help debug discrepancies.
Here is what I think when someone asks me to build such a system:
None of the code that will answer these questions is going to be interesting. It will be fairly standard APIs backed by a messaging bus, receiving and sending the information out to multiple recipients (log files, databases, message queues, displays, web socket). It will check for errors, validate inputs and sometimes implement a minimum of business logic.
The simpler the path that the information takes to get from A to B, the better the system becomes. Because we asked the right questions, the software is aiming straight for the bull’s eye, solving the actual business problems.
My software is very boring – but I asked the right questions; that’s why my work has such a profound impact.
Also Published Here