Development Tips I Wish I Knew Earlier

At this point I am 8 or so years in to my development career. There's a vast amount of practices and methodologies I know about development now that I obviously did not 8 years ago. While some of these concepts I now know are complex, many of them are quite simple. Ironically, the simple ones are also the ones that can save incredible amounts of time of refactoring down the road. Here's a list of a couple minor things I wish I had known sooner than later.

Store all dates as UTC in your database

One of the first codebases I started on had date_default_timezone_set('America/Chicago') as part of its bootstrapping because the company was located in Chicago. Now, 8 years later, that line of code is still there, and it makes date calculation more annoying than it needs to be to this day.

The best way to handle storing dates in a database is to store everything as UTC. Then, only convert it to the timezone you need it in as a last step. This will make comparing dates and handling calculations between them way less confusing throughout your codebase.

As a perfect example of battle wounds from learning this too late, click on this tweet by AWS below. The replies show quite a bit of shock to a tip about changing your database's local timezone.

Change the time zone of your Amazon RDS DB instance to local time. https://t.co/JBq4JSgCRl 🕰 pic.twitter.com/eIqyKBczPP

— Amazon Web Services (@awscloud) May 17, 2018

Use UTF8 encoding in your database

The default character set in MySQL is latin1 for various reasons, although I imagine backwards compatibility is one of the largest ones at this point.

MySQL 4.0 (and earlier versions) only supported what amounted to a combined notion of the character set and collation with single-byte character encodings, which was specified at the server level. The default was latin1, which corresponds to a character set of latin1 and collation of latin1_swedish_ci in MySQL 4.1.

At first this seems pretty harmless since it is the default after all. However, as soon as you start to get in to international characters (or emojis!) in your database this makes things trickier than they need to be.

Nowadays I believe it is much more sensible to store everything in UTF8 since all of the major technologies support and understand it.

One confusing caveat for this for MySQL specifically is that utf8 isn't actually the encoding you want, you want utf8mb4.

Save yourself tons of time with git add -p

The "patch" git add flag has saved me countless time by forcing me to review my work before committing it.

Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index.

Basically what happens with this command is you hit "y" or "n" on each chunk of code you have modified for whether or not you want to include it in your commit. This has saved me from committing untold amounts of var_dump() or console.log() statements in code I was working on.

After discovering this the site of a git add . now gives me goosebumps.

How to escape a timed out terminal session

Ever closed your laptop while in an SSH session to find that tab completely frozen when you come back? On Mac you can type Enter followed by ~ then . to force exit the stuck SSH session.

Assume everything will change and you have unlimited environments to support

As your codebase and technology grows, so does the amount of situations it needs to run in. Maybe as a startup you only have your local dev environment and production. Then you get a little more sophisticated and add staging environments. Then you bring on QA resources and need and environment for these. Then one day you become successful enough that you get acquired. Now, instead of https://stagebloc.com, your domain is https://www.fullscreendirect.com (hint: I lived this one).

All of these changes and environments will have different configurations needed for them. Any and all values you have hardcoded in to your codebase will now become excruciatingly annoying to manage between environments. From day one you should assume all pieces of your infrastructure may change or point to new places, it will save you a lot of headache down the road.