Blog 1

| No Comments

Blog Entry 1

One thing that I very much need to work on is my use of Software Development Tools. I've always used the sort of quick and dirty approach applications. I don't even know what a version control system is, so my knowledge in that area could definitely improve. In Linux I've always used geddit as my goto IDE, even though it is basically featureless, and when I SSH in I use nano. Nano is pretty awful, it takes all the tabs and replaces them with spaces. If you're writing a long program you have to use the directional keys to get from one end of the document to another. When you add up the time wasted simply navigating the document its quite a bit. I could probably improve the efficiency of my coding simply by learning how to use an IDE that isn't just a glorified text editor. In terms of debugging I've been a printf kinda man. I've used gdb on just one occasion and that was for the bomblab. I'm pretty sure I already forgot how to use it. This area is particularly appealing to me because I could significantly reduce the amount of time and trivial frustrations in my coding and focus on the things that actually matter.
Software Development Processes is another area I need to improve on. In that paper we had at the beginning of the class the author talked about the build it and fix it approach. This been my primary method for designing my programs. Sometimes I write some skeleton code first to get a feel for it, but generally I just dive in and let my ideas flaws pop up as they will. If I had some sort of structure to the way I planned my coding it would probably save me a lot of pain in the long run.
One of my strengths is Program Design. My software design is usually pretty modular, specific functions can be isolated and changed without having to find and change other pieces of the program (usually) and my comments always accurately describe the input, output, and what the function or class does. I generally don't have trouble adhering to a specific layout or style. My code is formatted correctly and very readable. It is almost always obvious what is going on, or if it isn't then my code is well documented. I do this because it makes my life a lot easier later if I have to go back and edit. If I need to debug there is a specific module of the application where I can isolate the problem. Making my code readable makes it way more pleasant to scan through visually and will just generally alleviate my headache at a later point. In my early days of programming everything was messy and debugging/editing them was pretty much the worst thing ever.

Leave a comment

About this Entry

This page contains a single entry by marqu245 published on October 5, 2011 10:54 PM.

Blog 2 is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.