Introduction

“Listen. Easy now,” said the old man gently. “I know, I know. You’re afraid of making mistakes. Don’t be. Mistakes can be profited by. Man, when I was younger I shoved my ignorance in people’s faces. They beat me with sticks. By the time I was forty my blunt instruments had been honed to a fine cutting point for me. If you hide your ignorance, no one will hit you and you’ll never learn. [...]”

–Fahrenheit 451

Newbie programmers, when set to complete task, will often complete the task in the worst way possible. Of course, most programmers graduate beyond newbies. This post will detail some questions that newbies can ask in order to build better programs.

The below questions are things that all newbie programmers should be asking themselves so they can produce good programs. The questions can also be used as a very simple litmus test to see whether a programmer is a completely lost newbie or not. The Five Essential Phone-Screen Questions has a set of questions that help find good programmers.

<insert image here>

Photo credit: Flickr user anomalous4

When coming up with ideas for solutions

1) What patterns or algorithms can help me solve the problem?

Computers work well with numbers, and numbers are full of patterns and sequences. A simple example of a sequence is the Fibonacci sequence, where every number is the sum of the previous two numbers (1, 1, 2, 3, 5, 8, 13…).

A simple and useful algorithm is the Sieve of Eratosthenes, which is used to create lists of prime numbers.

2) Has somebody else already solved this problem or a similar problem?

Google called; they said they have the answer to your problem.

For those that can handle looking at the possibly messy code of others, looking online for open source code that can partly, mostly, or completely fill a need is a good idea.

A somewhat recent example is that I was looking for an open source Digg clone in PHP to make slight modifications to, and managed to find Pligg. Unfortunately, Pligg didn’t manage to fit my needs, but I managed to find PHPDug, which I like better.

3) What are potential issues I could run into when solving this problem?

It is important to think ahead about what issues could be faced when solving a problem.

For an important website, the power of the hardware, the power of the software, and the precautions taken for data loss and downtime, and more should be considered.

When looking at possible solutions

The first group of questions are things that newbie, or n00b, programmers should ask themselves when looking at a source code or a way to solve a problem.

1) Is this method fast as it can be?

Writing fast programs is a very important thing. Too many people are not patient enough for slow programs, and writing programs that can easily be made faster is not going to make users happy.

2) Is this method secure?

I sometimes wonder if it would be more beneficial to beginning developers Baller shouted “Security!” instead of “Developers!”.

Some common, but dangerous security mistakes that n00bs make are:

1) not escaping user input

2) not using file permissions properly

Chmodding everything is 777 is bad. Very bad.

3) using improper encryption to store things

3) Is there a simpler way of solving this problem?

If a person has two solutions to solve a problem, that person should always choose the simpler solution. The more complexity there is in a system, the more difficult it is to use and maintain that system.

4) Is this method scalable?

Creating software that works perfectly, with the exception it not being scalable at all, is setting up the programmer(s) for some major headaches down the road. A classic example is Twitter’s severe instability a few months ago.

Final notes

All programmers ought to subscribe to Coding Horror, a blog with far more useful content than you’ll ever find in this waste of disk space.

Also remember to ask questions on mailing lists, forums,  and so forth, but only after several hours of experimenting with Google keywords.

You know why I haven’t posted in a while? No, it is not because I’m really busy, but because the CodingExperiments team has been churning draft after draft and ping-ponging back and forth between them to make updates. The result is a massive amount of half-baked blog posts. Working on posts one at a time and not starting another post until you have finished or given up on an existing post is a good way to prevent a barrage of blog post drafts from raining down on you.

While plenty of people say that producing good content is more important than posting regularly, plenty of new bloggers, including me, feel guilty when they do not post regularly.

Now, there have to be exceptions to this rule. Bloggers that write mostly time-sensitive material, then following this rule could possibly hurt them by delaying the publishing of the posts. Taking a look at this blog’s archives will show that whenever I try to cover something time-sensitive, I always end up covering it a few days later.

Also, if you would like more extremely obvious (or extremely brilliant, depending on your perspective) tips on blogging, you might like reading some of this blog’s other posts covering bloggi–oh don’t bother, I know nothing on blogging.

Sorry I was unable to post for a while. I wasn’t busy, but wrote a bunch of drafts and decided I wouldn’t publish them.

I shouted to the Internet that I am unhappy with existing RSS readers. Now, let’s use our prediction skills to see what will happen next.

Hmm… Programmers like to solve problems. I appear to have a problem with RSS readers. The title also gives a hint that I’m making plans for an RSS reader. Considering all that evidence, it is pretty likely that I’m going to make an RSS reader, right?

Yup. You guessed correctly. I’m going to build an RSS reader.

Because I want to access my RSS reader from anywhere, I will be creating a web RSS reader.

Below is the list of features that I have planned for the RSS reader.

• Tagging of feeds as well as individual posts.
• A recommendation engine for posts.
• Integration with:
  • Google Reader
  • FriendFeed
  • Delicious
  • and possibly more
• The ability to experiment with possibly dozens of user interfaces.

Wait, “experiment with possibly dozens of user interfaces”? Now why would I want to do that? The main reason that I want to experiment with a large amount of user interfaces is because no user interface for an RSS reader (both desktop and web-based) have ever satisfied my need for large amounts of data to come down the pipeline and be displayed in a good looking manner.

I am also interested in getting feedback from users to see which user interface is the most easy to use.

Now all I have to decide is what language to write it in. I’m thinking of either writing it in PHP or Python. I’m leaning towards PHP, as I haven’t actually done any real web programming in Python. I might try Ruby on Rails, as I know a small amount of Ruby.

Because of my limited resources, my RSS reader would be restricted to private alpha, though making the RSS reader open source would allow other folks to try it out on their own servers.

Any comments and suggestions on my RSS reader? Comment below.