Skip to main content


Showing posts from March, 2014

What is #/products/toaster - The origin of the URL Hash

This post is historical, and exaggerated to emphasize points. It is not historically accurate, and it's tone is intentionally light, so that the subject matter is easier to absorb.

In the beginning, there was the internet Every website was a single webpage.  They were horrifying geocities nightmares, like this.

The internet was a treacherous place, and the Back button had one purpose, to escape something you never wanted to see in the first place.  But the .com boom happened, and every company wanted a webpage.  It became immediately apparent that a single page wasn't enough. So...

Routing was born Routing initially meant that you could link to any folder in the file tree that contained your website.  If you had a Tools folder inside of the folder with your website, then you could reach it on the web by adding /Tools to the URL.

The default page configuration was born.  When you go to a folder, the website would try to open the default page (usually index.html or default.aspx…

How to write good tests (in any language)

In the last few years, I've read manymany articles on how important testing is.  In fact, I'd say that it's possibly the single most blogged about thing in programming.  All of this advice is great, but what if you don't know how to write tests in the first place.  You can be following all of the advice, and writing bad tests, and getting no results for your efforts.  In fact, I suspect that there are PMs out there who have convinced their team to give up on testing because of this.  So, let's talk about writing good tests.

Scaffolding When it comes to testing, I personally follow the Steve Sanderson methodology: Arrange, Act Assert.  But this technical terminology just makes the comments hard to read, and in practice, they actually become Given, When, Then, so I skip the middle man.  Here's a sample of how I write test code.
//Given: Some intialization logic //When: We call some method/function //Then: We expect these results //CLEANUP (optionally, unchan…

How to identify a skilled programmer during an interview

How does one identify a skilled programmer?  No company that has interviewed me could tell the difference between myself and other programmers they'd interview.  The interview process is truly a game of luck in this industry--on both sides.  Both the programmer and the company are basing their actions entirely on luck.

Companies have come up with numerous methods to attempt to discern a good programmer from a bad one.  The best tricks they have include a series of math problems, algorithms, problem solving technique tests, and even obscure programming questions, some without definitive answers.  As an example: Is there an authoritative source of information on the core principles that define object oriented programming?  I've heard everywhere from 3 to 7.  In a field of research about a synthetic concept, an authoritative answer is almost impossible to obtain.

Programmers were then forced to study to the interview.  Careercup is one of my favorite sites for this.  This almost …