When building a new application, one of the important decisions you make is the technical stack. This involves many considerations, one of them being the backend programming language. How flexible is it? What is the paradigm – FP or OO? Strictly-typed, loosely-typed, or no types? How has the language evolved? Is it still evolving? How extensible is it? How broad and passionate is the developer community? How does the language handle concurrency? Oh, concurrency.
In computer science, concurrency refers to the ability of a program to handle multiple instructions simultaneously. This is where multi-threaded languages excel. In a single-threaded language, achieving pseudo-concurrency (non-blocking operations) requires an event-driven architecture or asynchronous I/O.
My role at Liberty Supply requires a high degree of concurrency. The problem is that I'm not good at concurrent execution. My brain is single-threaded. For the most part, I think in linear phases of execution. I think in terms of dependencies and an orchestrated order of operations. Concurrency is at odds with this.
But, I acknowledge and adapt to the constraints of my internal runtime. I definitely work off an event loop... and man, is that queue deep. Perhaps that's why I gravitate to Node. I have a familiarity with and affinity toward its architecture.
As I get older, I recognize that none of the technical considerations matter to customers. As the interface, are we delivering value or not? Do we actually solve a problem? The answer to that question is binary. In its pursuit, the executive portion of my brain perpetually occupies the top of the call stack.
Start with customers, work backward.