Backstory
When I began work on a multilingual Point-of-Sale app seven years ago, which I’ve since named Saucepos, I had no idea what I was in for. I had coded separately on both client and server over many years, but this was my first opportunity deciding my own client-server architecture. Following established norms would have been easiest, but I’m a perfectionist and an idealist. The verboseness of those existing options hinder maintainability, especially in a system with complex business requirements. I insist of making the complex appear simple, or at least no more complicated than it has to be. I want to write succinct application code, free of repetitive infrastructure code that gets in the way of a clear expression of requirements. I forsake the safe and easy choice of architecture in favor of the ideal way that it can and should work, and then I remain determined until I’ve made it work that way. These personality traits conspired to lead me on a journey that’s lasted seven years – and counting. I’ve reached an exciting point on this journey that I want to share with other programmers.
About Me
- I’m Adrian Alexander Pinter. See my LinkedIn profile.
- World wanderer and polyglot (English, Korean, and Thai)
- Co-owner of a popular Thai restaurant in my hometown in Pennsylvania (provides a nice runway for coding!)
- Computer programmer since my first app (a game) at 13 years old
- Second app at 16-18 y.o. was a line-of-business app written in Java, when it was a brand-new language. I’ve wanted to enable better LOB app development ever since.
- I’ve been running marathons for the past four years.
Technical Interests
- Book that most influenced me was Object-Oriented Software Construction by Bertrand Meyer.
- Microsoft .NET developer and admirer of C#’s functional language features
- Avid proponent of document databases
Approach to API Design
- My goal in developing the framework was to be lazy… I mean, stay focused.
- I wanted to remove friction from the tasks of expressing business logic and implementing features.
- When I’m in the flow of writing application code, I want to stay in that flow. I don’t want to switch over to dealing with “infrastructure”.
- Philosophy: “Make the complex appear simple.” Or just “Good API design is wanting to be lazy… later.”
- Reoccurring thought: “This sucks. Let me write this code to cover every use case now, so I never have to deal with the problem again.”
- Tackle a problem to its bitter end while the details are still fresh in my head.
- By the time I get done with it, its minute details actually seem interesting.
- As I gain more experience with my API, refactor it to make it easier and more intuitive to work with.