Idiosyncrasies of My Developer Career
Inspired by Dan Abramov’s Things I don’t know
1. Never have I worked at a place which used an RDBMS as its primary persistent data store.
Mongo, Redis, API’s pumping out to external providers, and blockchains, have been the backbone of the Apps I have helped to create. Therefore I am not much of an SQL genius. A certain company which used Mongo as its primary store did have a secondary MYSQL DB for a particular dataset and for a time due to organizational adjustments (a nice way of saying one guy left and the other was fired) I found myself as the person in our company with the most knowledge of this part of the codebase. During this time in pursuit of improving performance, I wrote my one and only SQL query. I don't remember the specifics but I remember the objective was to fetch all objects and certain relations at once to cut down on round trips between services (graphQL foreshadowing)
2. I generally call myself a frontend developer, yet I have always written at least some serverside code.
I can whip out an express route. I have written dozens of Rails controllers. I used to obsess over finding bottlenecks and optimizing ruby code. I have upgraded a node app from node v0.12 to node 8. I've written Rest APIs and Rest-like APIs.
3. I learned plain HTML and CSS years before I learned any Turing complete language.
When I was a young teen I wanted to be a graphic designer. I spent most of my spare time in photoshop and learned CSS and HTML in high school from this graphical interface point of view. While I was always technically inclined, it was not until the end of university that I started to learn code. Having heard of the LAMP stack from friends I decided my first project would be installing WordPress on a Raspberry PI, which after I successfully achieved I realized it was far easier to just run on my mac.
4. Data Structures and Algorithms seem to be both obviously simple and mysteriously hard to me
From what I have seen reading pull requests and writing my own code 98% of the time an Array or A HashMap will be the data structure for the job*. Will I have a key and need to get an element from a collection based on that key? HashMap. Do I care about the order? Array. As far as I can tell, most of writing fast and performant code comes down to “don’t do memory or IO intense things in a loop/iteration/recursion/repetitively”. The one time I used a linked list was to create an organizational chart where each node knew only its parent and an array of all the descendants was kept on each node to quickly knew which were owned by it. Basically, we had a tree but the optimized routes were bottom up and a general ‘these nodes are under you but no idea where’. It worked very well for our use case. It wasn’t my idea though, our junior-most developer came up with it.
*I should mention there was a time when I was probably about a year into being a developer when I became obsessed with Sets. If a problem could be solved with sets, I would find a way. I went thru our and converted many O(n1*n2) solutions to O(n1+n2) by replacing array lookups with O(1) set lookups. It was easy and fun. Of course then I started realizing that there was a cost to creating the Set which sadly in Ruby needed to be created from an array. so if that didn’t exist 2 objects needed to be allocated. In the end I decided that the size of the other collection was a good heuristic for if creating a set was a good idea. The larger the more likely it would be worth it.
