Priorities

When using any issue tracking software, it's important to know which issues should take priority. Issues that are high priority should, obviously, be dealt with first. Issues of lower priority can wait.

Usually, this means assigning a number to a particular issue, perhaps with a descriptor of some sort. Some go from one to ten, some go from one to seven. They might go from "Must fix" to "Don't Fix". This is, however, not always intuitive. What does a six mean? What does a one mean? Are people just going to mark everything as a 10? Does the description of the issue say "Not a huge priority", but the rank says "Must fix"?

If you couldn't tell, I've had some bad experiences with priority systems.

Styling By IDs: Case In Point

There has been some argument in the web development community about styling HTML by IDs. Arguments against styling by ID include specificity (IDs are hard to override), and, more importantly, code reuse.

I Was Wrong

I mean, I was right… the first time.

When I first started working on SlickText, I converted the code that the CEO/Designer had written such that it would use Smarty templates. It was the right way to do things. However, he pushed back, saying it was “too complex”, and I caved and reverted back to the PHP/HTML files and output buffering that he was using previously.

The Dangers of CSS Resets

For a while now, people have been using CSS reset files to, well, "reset" their pages to a default, unstyled state. Until recently, I had never used one, and my current use of one is not by choice, but because it was already in place when I started my new job.