Blog - TimeSentry

Making it Go Faster

Written by Joseph Frantz | Jan 17, 2025 4:49:09 AM

 

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 if you are a customer). 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 Taylor and I both for years to come.

 

For now, we are still running v2 of the beta with a few added features for demos, etc.

 

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 (as I didn’t meet them directly). 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.

 

Asks:

 

  • Set up a time to demo the new algorithm, I’m curious how well we can do on your timesheet!

  • Send us your favorite influencers in the professional services space so we can experiment with influencer marketing

 

Onwards,

Joseph