The PNTRLY Code
Over the last few years, some folks have been working hard to bring you a project called PNTRLY. Simply put, it’s a digital coloring book, but beyond the surface it’s so much more.
The app started with a little bit of research and a whole lot of passion. Data suggested that a coloring book app was not only what people wanted, but also it’s what people needed. it’s no secret that coloring is fun, but more than that, it is therapeutic in the exact ways we need after the turbulent years we’ve all survived.
You will also find PNTRLY to be technically excellent — a deep source of pride for our time. There were many decisions our co-founder and CTO, Roger Miller, agonized over, from naming conventions to data structures, even which 3rd party services were the best fit.
“I am really proud of where the code base is right now, even though there are some competing ideas in there that have both proven their value. So from an engineering perspective, this has been more soul searching than it has been just getting the job done. What have I actually learned? If I were a politician, this is the point where I should get abstract and hedge my bets, but I am an engineer and I reserve the right to change my mind if I get better data. These are not new ideas or new to me, but I took the time to test them and my biases.”
— Roger Miller, PNTRLY co-founder and CTO
Here you can see Roger’s rules for building PNTRLY:
Simplicity is still the best policy. No matter how much I test this principle, it always wins one way or another. Keep your code as simple as possible. Less to test, less to go wrong. Don't be ashamed of simple, rather use it as a rock to challenge more complex structures.
Over engineering is the devil's business. Never write more code than you need to get a job done. Be ruthless if you can. Even when my bets for writing code for future use cases have paid off it has not been worth it when evaluating the total effort. This is a little different when writing things like SDKs but then you need to be clear on your use cases. Trust and be disciplined with the refactoring process. If you accept that you need to refactor often and embrace it, this becomes second nature.
I don't believe in encapsulation as a reuse principle in product development anymore. I believe in encapsulation as a separation of responsibility, but only so far as it makes things testable and simple. Encapsulation can so easily lead to over-engineering, and make your code difficult to use and understand. In my 25+ years of experience, hardly any code gets reused anymore because technology changes, people change and requirements change. If you find you need the functionality from another project, that's the time to make it a library, not while you are writing it for the first time. After all, you need at least 2 points of data to draw a straight line.
We’ll be sharing more insight into the tech behind PNTRLY, and in the meantime be sure to download and enjoy!
Roger Miller
Co-Founder | Chief Technology Officer
With 25 years in the software industry, 15 in the game/AR/VR industry, on 4 continents, Roger comes with a breadth of knowledge. Roger Miller has been on the leading edge of both server and client side technologies from factory automation to data cataloging to award winning games and XR applications. He has worked with leading advertising agencies such as Ogilvy One, been a vendor for entertainment companies such as Unity, Amazon, Disney and HBO, created solutions for BMW and Deloitte and been nominated for awards such as the IMGA. He has spoken at Unity Unite, a once frequent speaker at the Unity User Group in Los Angeles and founded the Unity User Group in Bend, OR.