• Setting up your development environment
• Making a static calendar using HTML
• Mockup a more attractive look with fireworks
• Styling the the calendar with CSS
• Use PHP to detect the current date and display the calendar accordingly
• Use PHP & MySQL to store and display events
• Using Javascript and jQuery to make things slick

That's not to say we don't use tools.  Every programmer has a preferred text editor, but they all end up doing one thing: writing plain text.  That said, here are some of the features common in the good editors:

I posted last week about how feature bloat can ruin software.  Adding lots of small features to a project doesn't just add harmful bloat, it slows down real improvements.

Several times per day something comes up where five minutes of coding could significantly improve our software.  When this happens, I add that idea to "the list".  Everyone at the company knows that when something goes on the list, there's no telling when (or if) it will ever be completed.

I'm going to use this post to defend that way of doing things.  It's really easy to say, "but it would only take five minutes.  Why don't you just do it now?"  The simple answer is that while one individual improvement only takes five minutes, I have about 200 small things on my list.  If a developer stops to make every little tweak imaginable, the software will suffer.

No amount of tweaks will ever add up to have the impact of a well planned and carefully implemented week-long project.  This is one of those situations where the whole is greater than the sum of its parts.  One block of five minutes is certainly better spent on a small fix than a week-long project, but a week of small fixes can't compare to a week focused on one important problem.

Additionally, it may only take five minutes to complete a small project, but it could take 30 minutes or more to get back in the flow of whatever you were working on before the interruption.  It's hard to say "no" to little things, even if only temporarily, but it's irresponsible to let yourself become distracted from the real work.

And that's what the title of this post is talking about.  Just because something only takes five minutes, you should still treat it like a project.  You should still put it on a list and prioritize it just like you would a month-long project.

Each day I get into work and decided what I should spend my time on.  This is based on which projects I think have the best chance of improving our customers' experiences and help our company grow as a result.  When that idea for a small tweak that would make everything better comes in, I have to remember that I'm working on my current project for a reason and that's because it's the most important thing right now.  The tweak can wait.

There's a pretty easy compromise for programmers.  We generally deploy new code every Friday evening.  I don't want to get into the details of our version control system, but deployment is a lot easier if I don't start any other major projects until the old ones have already been released.  That means that if I finish a couple hours early on Friday, I can spend that time checking items off "the list".  This is a great way to make sure that the little things get fixed but that they don't take over my week.

I was talking with Ben (the CTO at Zane) about what some of the core skills that set apart good programmers from bad ones.  Probably the most important thing is a solid understanding of how to store and retrieve information from a database.

I understand databases pretty well.  I'm no expert, but I almost never run into a situation where I can't easily implement a database-driven solution to a problem.  My initial reaction was, "thank god I learned about databases at Wash U."

Then I though about it.  I don't think I ever once dealt with a database in school.  I never learned how they worked.  I never used them to store data.  I never ran a query.  Not once.  How in the world could I have gotten a CS degree from a great school without once coming across one of the most fundamental aspects of programming?

Ok, so to be fair, a computer science education is supposed to be more about theory and less about learning what you'll use in the real world.  But I still had to learn Java, C, C++, VHDL, and the list goes on.  If I only needed to learn theory, then I should have only needed to learn on programming language.  Hell, I shouldn't have even needed to learn one if the point was to study theory.  And if there is even a hint of practical experience being taught, databases should be as high on the list as learning any programming languages.

Also, there was one database class which I was planning on taking as part of my Masters program.  I'm sure I would have learned more than enough in that class.  But that class wasn't required and most of the people I know didn't take it.

I'm not trying to blame Wash U for this.  I think my coursework was very similar to the status quo.  But still, shouldn't every CS major be required to at least understand the basics?

Many people don't understand just how scalable software is.  Computers are really good at performing simple tasks over and over.  They don't get bored.  They don't quit.

So let's look at some hypothetical software and talk about how difficult it is to do different things.

Let's say you're building a site that lets users publish blogs. To publish one blog (such as this one) you need a table to store the posts, and another table to store comments.  I've got more bells and whistles, but those two tables store just about everything.  So I'll assume that this hypothetical software only has those two tables.

This means that the software supports exactly one blog.  You can add as many posts as you want but there's no way to differentiate between multiple blogs.  In order to support more blogs, you need to add another table that stores information about each blog which links to the individual posts.  What I'm saying is that there is a fundamental difference between supporting one blog and supporting two.

Those of you that have experience programming know that adding the extra table takes about 10 minutes.  It's hardly any work at all, but there is work involved.  The thing is. once you have a table that stores information about the individual blogs, you can add as many entries to that table as you want.  There is no additional development work necessary to go from supporting two blogs to supporting three (or four or 5000).

I mention this because sometimes the way software is distributed makes it seem like it's difficult to duplicate certain things.  Maybe you only get to add so many user accounts or you can only perform an action a certain number of times before you have to pay more.  This is almost always an artificial limitation imposed by the software company as a way to get you to pay more.  Don't get me wrong, these companies have every right to use whatever fee structure makes them the most money, but we as consumers need to be more aware of these practices so that we know when to call BS.

I first thought of this because the Palm Pre application launching screen only allows for three different pages (or whatever they're called).  You can add links to apps and contacts anywhere you want on these three pages, but you can't make a fourth.  For a device that is generally very well designed, it seems crazy that they would allow more than one page without allowing as many as I want.

Notes:  Because at least one of you works at Facebook, I should say that scalability is an issue when you have millions of visitors every day.  Really high traffic websites can't just scale infinitely, but this isn't an issue for 99.9% of software out there. 

More Notes:  Sometimes making the jump from one to two doesn't actually require any work (as was the case with a project I recently had to write specs for).  Most of the time there is a little work.