It's pretty easy to build a website, print some business cards, download a free development tool, and call yourself a programmer. In fact, if you aren't intimately involved in the software industry you may not be able to tell the professional from the amateur. After all, there's a world of difference between someone who just picked up "The Idiot's Guide to Computer Programming" and a professional, and that is sort of the purpose of this page. I want to give you the knowledge to be able to tell the two apart.
What exactly is "computer programming", anyway? Of course, it is the process of writing computer code (i.e. programming, coding), with the result being a functioning (hopefully) software application. But if you are going to do it correctly, you need to do a lot more than coding. Let's take a look at the steps we need to take to provide professional computer programming services:
The Development Environment
The way a programmer structures his or her development environment says a lot about them. Often times, new developers will keep one (and only one) copy of the source code on their local computer. They rarely use a source code repository, such as SVN. There are serious problems with this approach. For starters they are a system crash away from disaster. But there are other issues, too. If you don't use a repository, you can't really do team programming properly. You can't unit test your applications effectively either. Basically, you are back to the 1980's style of development without a repository.
Comments/Documentation
I can usually tell a lot about a programmer by looking at their source code. It doesn't matter what language being used, or if I even understand the code. A professional programmer will write comments throughout the source code, explaining its purpose, clarifying tricky sections, and logging changes. In just about every instance, an amateur will do none of that. The truth is, they are too busy trying to figure out how the language works to concern themselves with comments/documentation. Without comments the source code is almost impossible to maintain.
Test-Driven Development
In the olden days (1980's and early 1990's) we used to write some code, compile it, and then run it, spot-checking for problems. Trust me, programmers make the worst testers. They know how the system works (they created it) so they know what buttons to press, and what buttons not to press. It was the tester's job to find the problems. This has serious flaws. For example, let's say the test team doesn't catch the problem for a week. Now the programmer has to go back and revisit the code. They may have forgotten exactly why they coded it a certain way, and now they spend two, three, even four times longer fixing the problem. The bug could have been fixed in minutes - even seconds, had they caught the problem immediately.
That's why test-driven development makes sense. The sooner you identify the problem, the faster and less expensive it is to resolve. You also avoid needless effort, such as when QA has to log bug reports, documenting everything to the letter. It's wasted effort we should avoid.
Rarely will an amateur use a test-driven development approach. It takes time to setup, and it requires all of the other items above to do well.
Our Programming Expertise
Now that you have a better feel for how professional programming is done, you might wonder what our areas of expertise include. Our main areas are:
- .NET Framework (Microsoft's Technology)
- #C (pronounced "C Sharp", if you are curious)
- SQL Server (not really "programming", but still relevant to this discussion)
- Java (and related technologies)
- PHP (scripting more than programming)
- Ruby and Ruby on Rails (the framework for Ruby)
- Visual FoxPro (also not really "programming")
- JavaScript, AJAX, Perl, Python (technologies we sprinkle throughout an application)