Making It Go Faster
Sometimes you have to slow down to speed up. We spent a lot of time on dev this week. In between coding sessions, I happened to read Paul Graham’s essay, Hackers and Painters. In it, he writes:
“A programming language is for thinking of programs, not for expressing programs you’ve already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that’s not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.”
As the CEO of the business, I spend a lot of time thinking about the commercial aspects of the business, but I also spend a lot of time thinking about programming languages, development frameworks, and questioning how we can create a better engine to sit at TimeSentry’s core.
At this stage, it’s our internal engine that comprises the vast majority of the enterprise value of the company (or the 2.5M+ lines of code that comprise the prototype…) The faster we can build, the faster we can eventually build into market pull.
Coming from an analytical background, I prefer coding in python to anything else. In my mind, pythonic is a compliment. That’s why I wrote v1 and v2 of the beta in python. But the speed limits we were hitting with server-side rendered templates and vanilla JavaScript was unfortunately too slow for the competitive landscape in this modern age. I thought a light frontend framework (Jinja templates + JavaScript) was enough because the analytical functions of TimeSentry could live “under-the-hood” as python microservices, but I was wrong. There is simply too much front-end work to be done and a more robust framework with reusable components is needed. The breakpoint was trying to implement a drag-and-drop functionality on some analytical dashboards in Jinja. And that’s where I think we pushed Jinja to its limit. As such, it is with a twinge of sadness that I say goodbye to server-side templates and with them, Jinja as an application templating language.
Super exciting and related: We are about a quarter of the way refactoring our front-end into React and our backend into an API. The good news is that React has much cleaner libraries for almost all front-end functionality. We unfortunately have to rebuild quite a few features, but compared to the first build we are FLYING (side note: we also switched from Bootstrap to Tailwind for finer-grained control of the look & feel of the product — expect a much sleeker look once we exit beta). I estimate we’ll be done in a few weeks and at that point we will be much, much faster on the dev side. I believe taking it on the chin dev-wise and making this change now hurts for two weeks but will serve us for years to come.
Meanwhile, we continue to pursue customer discovery and book meetings. I met a number of prospective customers across a few events and we had several new people complete the signup flow on the website, presumably from word of mouth. That was awesome. All of them came from large enterprise firms so I’m going to reach out and see if in any case they can champion a meeting.
Onwards, Joseph