Interview with Paul Modderman
Director of ERP Integration
Congratulations on your recent appointment as the Director of ERP Integration at Clear Software. Your company has created software that consolidates the entire ERP process into a single screen. How does this new position fit into your experience in product development?
Product development is the perfect role for me, in part because I understand one of my mental weaknesses. I’ve done some consulting work, and I’ve worked in-house for big non-tech companies as a staff developer. In both of those cases, you have to juggle a lot of simultaneous, unrelated things. As a developer, I just don’t have the brainpower to make sure that 3 entirely different projects for 3 different customers all come in successfully. At least not without getting completely exhausted. Software development is an inward-focused, hard-to-context-switch task.
But in product development you can reduce that context-switching a little bit. There are a ton of things to do, absolutely. But they’re all thematically related to that one thing: the product. I love the feeling of knowing something so deeply, so intimately that you could ask me a random weird question about it and I’ll immediately know the answer. Because I know it so well that it all fits in my head.
The new position at Clear makes this happen in a fantastic way. Whether I’m throwing out random ideas to the marketing team, jumping on a sales call, or hacking away with the development team, it’s all in service to that one thing: the product. It fits in well with my past experience in product development, because it kind of formalizes all those hats I wore in my previous job as part of a small shop: sometimes speaking, sometimes hacking, sometimes pitching to potential customers.
Clear Software’s flagship product is ClearUI. Why does it exist, and what technologies make it possible?
ClearUI is all about simplifying ERP processes, with a strong focus on making the user’s experience fast, simple, and easy to navigate. No one taught you how to use Facebook or Amazon – you just went there and figured it out because the UI guided you to clear outcomes. That experience is just not the case with traditional ERP user interfaces. The best example, of course, being the SAP GUI. If it takes you (for example) 8 screens and 6 transaction codes to do a straightforward accounts receivable process, you’re losing an enormous amount of valuable time staring at a screen trying to figure out what to do. And then you have to jump to some other screen that looks completely different. When you look at the numbers it’s pretty self-explanatory why it exists. People have gotten 5,000%+ productivity gains, millions of dollars in savings, and in one case a process that had taken two weeks for a user now takes about one minute.
I am beyond excited to work with this tech stack, because it allows for incredibly fast innovation. A couple times a day I have little aside conversations with myself, like “is this really my job? Do I actually get to work on inventing something totally new?” Yes, I do.
My younger self had a serious case of impostor syndrome. When I did something right or delivered something to expectations, I secretly feared that someone would find out how hard I had to work to make that thing happen. I thought that all the senior-type folks would just look at a problem, take a sip of coffee, and then conjure up beautiful code from this incredible well of confidence and experience.
There are two things wrong with that thinking. First, I’ve worked with enough senior level people to know that nobody just drops hundreds of lines of furious typing into an editor, publishes it, and goes home. Making software that works is a hard thing, and you have to allow yourself the mental space to have little failures and fits and starts. Second, when people give the appearance that they can conjure up beautiful code from nowhere that just means they’ve made thousands upon thousands of mistakes in prior projects. Code conjuration rests on the shoulders of code mess-ups.
The pithy one-liner could be: making new mistakes means you’re getting better, because you’ve already leapfrogged all your old ones.
Software crafting has been an important part of your career, so, tell us your secret sauce – how do you keep your inspiration fresh?
Talking to people that I find fascinating, and who are willing to trade ideas with me. I have a limited creative well to draw from – like I said in the other question, understanding my mental weaknesses – and the best way to fill that well is with thoughts and perspectives from others. For me, inspiration often comes with a current conversation suddenly connecting with a prior idea or concept.
Case in point: I was talking with Amber [Christian, Ace’s CEO|Founder] lately about the ins and outs of collaboration between very small businesses. I was suddenly reminded of a book I read a couple years ago called Nonzero: The Logic of Human Destiny, by Robert Wright. It’s about game theory and cooperation and how that all plays out in biology and society, with a mix of some religion-inspired thoughts. Right there, in conversation, a couple of ideas for writing and software features spring up, because the well I exhausted was filled externally.
Are there any best practices you can share?
When it comes to writing code, here’s what I’ve learned to try to do better with every project:
Think before you code. Suppose you have a feature you want to create or a bug you want to fix. Unless this thing is truly a one-line-of-code solution, your first step should be to put the requirement in your own words as though you were the computer. Sometimes this means doodling on paper and then taking a walk – don’t be afraid to leave your desk. Whatever jogs your brain into solving mode. Your key to when you’re done thinking and ready to write code is this: when you can write what you want to happen in clear prose in your native language. You don’t have a hope of doing any meaningful computer code in a computer language until you have meaningful human code in a human language.
Think after you code. When you make a change and you’re about to test that change, stop and say out loud or write down a prediction about what you think will happen and what should happen. This will force you to be in constant practice of keeping your mental model of your software up to date. I’ve caught a number of bugs before testing just by stopping to predict what I think will happen and why.
Free Will by Sam Harris. Harris argues that neuroscience points to the (perhaps disheartening to some folks) conclusion that humans don’t have “free will” in the sense that most of us mean it. He goes on to make a pretty good case (I think) that this shouldn’t cause us worry or despair, and can in fact inform our moral, political, and personal decision making. Even if “decision making” doesn’t mean what we think it means.
I recommend it if you’re willing to spend a bunch of time after reading it thinking about thinking itself. It left me contemplating the idea of agency in my life, and even questioning my thoughts as they occurred! But I think anything that moves the needle on how we understand ourselves is ultimately beneficial.