Posts by — Adam

Here at devjargon, like most blogs around the blogosphere, we use Wordpress as our platform. We like the ease of development and the relatively fast performance that it gives us. We recently updated to the newest version of Wordpress 2.6, and so far have been fairly impressed with the new additions.

One thing that I don’t like about Wordpress 2.6 is post revisions. Today I’m going to show you how to turn post revisions off so your wordpress database doesn’t get bogged down with useless entries.
Click for more →

One of the constants in this world is the fact that technology will change, and it will change quickly. The average lifespan of a computer these days is between 2 to 5 years. Since technology is changing so quickly this equates to a lot of garbage from your old computers. Here are a few ideas of what you can do with your old computers instead of sending them to the garbage dump.
Click for more →

Creating software is difficult. You need to first get the requirements from the client (or create them yourselves), then you’ll use the requirements and design a working system. Once you’ve designed the system, turn the design into code. Next you’ll test your code to make sure it works and finally deliver the completed project to the client.

Today I’m going to look at the second part of the Creating Software series: The Design phase. There are a number of aspects to designing software. You need to take the requirements you gathered previously and start to create your software. At this point, you’ll have very little code (and possibly none at all). Don’t let this fool you though, the design phase is extremely important, and many projects have failed because they either didn’t design, or improperly designed their software.

Here are three things you can do in the design phase to make your software project more likely to succeed.
Click for more →

This week has been a great week for us here at devjargon as well as around the blogosphere. We’ve had a number of great articles and comments here and have seen a number of great articles emerge around the web. Here’s an outline of some of our great stuff this week.

• 15 Reasons Why I Became a Developer
• Create Software: Getting the Requirements
• Love to Fail: 3 Tips to Help Learn From Failure

Click for more →

The journey to developerism started when I finished grade 10. I was picking courses for next year and I couldn’t figure out which class I should take to fill the last spot. There were a number of options: gym, advanced math, maybe a French course, but one course stood out from the rest; it was computer science.

Since that original class, I have gone on to take my bachelors degree in Comp Sci. and have grown that original interest into a love for programming and development work. While some could say that the original reason I became a developer would be to the lack of other good courses, I have other reasons. Today I’m going to tell you 33 reasons why I became a developer.
Click for more →

Most software projects follow a fairly similar path from creation to completion. They start with talking to the user, getting the requirements for the project. It moves to the next stage, taking the requirements and getting them on paper (designing your software). After that, you get into coding, testing, bug fixing and more testing, and finally, you show the finished project to the client.

Now I know that I’ve outlined a fairly crude time-line but thats the basics of it. Over the next few weeks I’m going to go over each of the parts of the software project time-line and outline a few of the things that I find difficult.

Today I’m going to start off with the first in the list and also the hardest in the time-line; talking to the client and getting the requirements.
Click for more →

This morning I followed my usual schedule. I woke up, fired up my laptop, checked my blogs for any new comments, checked my feeds for any new posts and then opened my email client. As I was wading through the numerous emails (I have five different emails that I go through) I came across this email from a blog that I commented on yesterday:

Hi there 4620,

Thank you for taking the time to visit my blog. I hope i was able to help you with whatever you were looking for, if found my site to be interesting i would be more then happy if you consider subscribing to my RSS feed.

Click for more →

Every programmer will, at least once in their lifetime, have to work in a group setting. Most software today is just too large for a single developer to work on.

Programming with a group is a much different experience than programming by yourself. You need to worry about other people’s code, getting along with other developers and making sure your own material is up to standards. It can be a stressful time if you’re not prepared.

Here are 6 tidbits of information that will hopefully help make your group experience a little bit better.
Click for more →

What does it mean to be a great developer?

Does it mean that you’re the best programmer on the team? Does it mean that you’re extremely successful and famous? While great developers can often answer “Yes” to both of those questions, it takes a much broader skill set to truly be a great developer. Today I’m going to look into a few things that can make a developer great.
Click for more →

One of the most important practices in software development is taking breaks. I know how weird that sounds but its true. Programmers often focus on getting the task done and forget about their own mental and physical health. Taking breaks can help you be more productive, they help rest your body, and they help by letting your brain digest any code you’ve written.

Click for more →