devmorgan.com

For the last several months, I have been a programming and database tutor here at RIT in the Information Technology department. I have seen many students come and go for help, with varying levels of skill and motivation when it comes to programming.

I hate to say it, but I usually find my self disappointed in some students. I have been trying to figure out why they struggle with programming so much, and I want to try to help them get past the roadblock they are having… I have determined that one of the biggest roadblocks that students run into is having a profound lack of attention to detail and no patience.

Many times I get asked a question that could really be answered if someone just took some time to look at the code in detail, or think through a concept fully. I believe that people are fully capable of logical thought, so just taking some time is all that is really needed.

Step 1: Determine the problem you are trying to solve.

Even at the low academic level, you are programming for a reason. Before being able to code anything of value, you need to be able to abstract the fundamental essence of what it is you are trying to accomplish. If you are writing a program that will calculate area of shapes, that is one paradigm, another is connecting to a database. You must tune your brain to the frequency of the problem, and attack it from there.

Step 2: Develop a plan

Over the past few years, I have determined, I am not one to spend lots of time on design. In fact, I find that most design methodologies are too much overhead or too optimistic. I do however believe that you must always have a plan for what you are doing. A complex UML diagram is not needed, but a simple “WTF Napkin-gram” should usually suffice. Sure, part of this post is about detail, but the detail is most important in the code, not in the plan (this is my opinion… methodologists will wholeheartedly disagree).

Step 3: Code, and follow the plan

Here is where things start to go awry, and this is where I want to focus on a few key problems that I run in to.

People tend to write code blindly. You need to think about what you are writing. Every line should have purpose, and should be directly trying to accomplish the goals in your plan. Every line of code that you write that deviates from that plan is code that is considered ‘junk’. Look at the documentation for your language, and make sure you are not reinventing the wheel, but more importantly, understand what each function call you make does. Does it return a specialized object that behaves in a certain way? What are the bounds of your parameters? Take the time you need to make sure you understand each piece of what you write.

Focus on the error messages. A lot of the problems that I get asked to help with are (relatively) simple compile/syntax errors. Every language has some way that it can get these error messages to you, use them! This is where your attention to detail really comes in handy. You can look at a block of code and see things you might have missed, incomplete statements, and most common (but not always an error) incorrectly named variables. Make sure you understand the code you are touching, and be very explicit in fixing problems with it. Don’t shotgun debug, be precise about what you are trying to do,

Copying code is a bad idea… usually. This is one I am guilty of, in fact, most programmers are. There are several major flaws you need to worry about when you notice yourself copying code. The first problem is the most obvious, if you can copy code, there is a chance that the branch of code you are copying should be in a reusable function. Look at the code, see if you can abstract it to be a function call, and if so, do it! The second major problem with copying code is that its extremely easy to miss any changes you need to make to the code. For example, if you copy a few lines that are modifying variable xmlDoc, and you want the copied code to modify xslDoc, you might miss a change in going from xmlDoc to xslDoc. Happens all the time… so be careful. The third major point I want to touch on with copying code is this: I don’t recommend copying more then 3-5 lines of code at a time from another project. Be sure that you actually need the code you are copying. If you just grab an entire class file, you will likely need to change it enough that it might be a safer bet to just rewrite it… of course on that note…

Don’t reinvent the wheel. If code exists that does what you need, use it. In academia it is a little different, since we are trying to build up core concepts, but, in reality, if it has been done, you likely do not need to do it again. Many people could go on for hours about how important it is that programmers be lazy. I agree, programmers need to be lazy so they can see the way they can save time while coding, but remember that programmers also need to be proactive. You need to be able to spend time looking at documentation, and just playing with existing code to see what is already out there. Save yourself a headache later by taking some time to discover things now.

Program for programming’s sake. I guess this will be my last big point. A lot of people only code because they have to. Sure, this stuff isn’t for everyone, but if you want to be a good programmer, you need to do it a lot. Practice is how you begin to learn all the documentation, and all the tricks about a certain language (To Students: Yes, that is why I know where everything is in the javadocs). Really, the best thing I can recommend is to come up with a pet project, and do it. If it suits, trash the code and write it from scratch after you work out the initial kinks and know the problems you will run in to. The more you code, the better you will become.

These are only a FEW tips for becoming a good programmer. They are just some of the big issues that I see on a day to day basis with students here.

This entry was posted on Monday, April 14th, 2008 at 1:04 pm and is filed under coding, education, rambling. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.