Knowing

There are some bits of code
That... I just... know... won't work
Yet.
Not yet.
There's no point in testing
Linting
Uploading
Anything
Until I've passed that point
Where logically
... no... intuitively
It makes sense.
And it will work.
And I can have some amount of
CONFIDENCE
In the code I test.
Release.
Write.
And knowing that I know this
Is one of the greatest signs
That I know what I'm doing
And I can have some amount of
CONFIDENCE
In my ability.

Behind The Scenes

When somebody I know visits Slick Text for the first time, they're inevitably impressed. In my completely biased opinion, Slick Text is a great product, and there is good reason that these people offer compliments. Similarly, our customers are often very pleased with our company and our product.

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.