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.