Month: October 2021

The Hard Parts

I remember talking to a friend who worked at a company that did contract programming for people. The gist of the conversation was that they got a signficant amount of work from people who had some kind of application that had been programed by someone’s sibling/cousin/best friend. The app worked, and was starting to bring in money, but as the business continued to grow, the app wasn’t scaling the way that it needed to be.

The take away was that companies were engaging his firm because the writer of the original app had hit the limit of what they could do, either because they had other commitments, or because they had hit the limits of their expertise as a software engineer.

At the time, I was lucky if I could just get the right onto my screen when I was programming.

In the years since, that story has come to represent what I think of as the ‘hard’ parts of programming.

The initial roll out of a project is hard. You’re making dozens, hundreds even, of decisions about how to structure things. If you have deep subject matter expertise in the area that you’re trying to automate, then your decisions are more likely to be correct than if you don’t but even then, some of your assumptions may be drastically wrong once the app is in the hand of the users.

Those wrong assumptions can then result in needing to put in a lot of work to fundamentally re-structure the application.

Additionally, when first creating any kind of software application, there are a whole host of things that you need to get working together which aren’t a factor for someone coming along later in the process. It’s one thing to access the database via code in an app that’s been running for a year or two using methods that work hundreds of times over in other spots in the code base. It’s a whole different kettle of fish setting that database up and writing those methods which will allow those who come along later to access the database.

So, setting things up is hard. You can get around that to some extent by using open source tools that packing different components together, but I still have mad respect for those people who get the initial version of a project up and running.

The other thing that I’m realizing is really, really, hard is extending an existing project in ways that minimize the complexity so that you don’t cut your throat making future changes harder and harder to bring about.

Props to all of the engineers out there who are doing that or who are removing unnecessary complexity from an existing system.

I suspect it’s not the end-all-be-all, but in this area, I got a lot out of Code Simplicity by Max Kanat-Alexander (affiliate link).

Javascript Milliseconds vs Postgres Microseconds

I recently ran into something that I never would have even considered thinking about before now.

I was trying to query Postgres looking for all records with a specific result in a field that was a timestamp.

I got zero results, which was a real head scratcher given that I could see the records in the database.

As it turns out, by default, Postgres saves timestamps that track 6 digits to the right of the decimal. (Microseconds.) On the other hand, when you convert a Javascipt Date object to it’s string equivelent, you only get 3 digits after the decimal (Milliseconds).

So, when I asked passed in my query string it was something like YYYY-MM-DD HH:mm:ss.333. Postgres would then look at that and say ‘I have YYYY-MM-DD HH:mm:ss.333125′ but that is slightly after what you’re asking for, so I have no results to return to you’.

You can over-ride the default settings for a timestamp in Postgres to be only 3 digits past the decimal at the time you create the table/field by defining it as ‘timestamp(3)’