The First Program, The Biggest Block

I had not realized this myself, but now while dealing with students it is getting more than obvious. Even after attending most of the classes they lose their confidence when asked to write code. The main reason that I could dig out was that they were still not comfortable writing code. Whatever code they did write was usually a copy from some book or from the Web or they simply did not write yet. They were banking too much on the theory, or I would say they got so comfortable with theory that writing code started making them uncomfortable.

This affects their ability to understand the concepts. Just knowing the concepts is not enough, it is important to see them applied to solve problems. And that cannot happen till you see code in action. Writing code introduces a lot of practical disciplinary things, like including header files or using namespace or why classes should be written in header files. Most importantly writing code can help you understand why certain code works like that. You start coming up with your own abstractions, your own text, your own analogies that help you understand better. And if you do not write your first program, you get stuck with whatever someone else is talking about.

Mind you, the first program is not the usual Hello World program, which does nothing more than help you execute your first code. The first program should have a problem statement, it should have specifications, restrictions, validations and intended use. This first program will take you across the biggest block – hesitation or inhibitions about starting to write code, whether it is a function, class or a program.

Not only limited to students, this can help software developers too who are learning new programming languages. It was not very straight-forward for me to understand the functional programming techniques after being so deep into the imperative programming way of thinking. However writing programs, original programs, without looking elsewhere for code helped. It did bring up a lot of problems – syntax, appropriate constructs, best practices, everything.

Writing the first program does not help you avoiding mistakes, but it does help you in quickly learning from them.

Discussion [Participate or Link]

  1. Ricky Clarkson said:

    I personally encourage a “code first, think later” strategy. That is, I know that as beginners, the most important thing is to learn how to get to a solution, to become a Turing-complete programmer, if you like. Then I help them to graduate beyond that. Usually that involves reviewing their code and looking for duplication.

    I find it works well for me, coupled with small (one to three week) assignments. But then my students aren’t CS, they’re Multimedia and Internet Technology students. I can expect them to struggle with theory, but they excel at practice.

  2. Luke said:

    I think what creates this loss of confidence and comfort is that teachers fail to do two things with their students:

    1) Ask questions of the students with regard to a problem and let them brain storm collectively into how this problem should / could be solved.

    2) At some point, stop providing textbook examples so that the students have the opportunity to implement what they have learned using their own knowledge; not someone else’s. Much in the same vein as Ricky’s “code first, think later”.

    Moreover, what also creates this lack of comfort is that teachers rarely seek a middle ground. They either produce a problem that contains aspects that have not yet been taught in theory (too hard) or just stick with unchallenging problems that don’t require the students to implement more advanced concepts that have been learnt. That is, a lack of progressive difficulty building and/or including of new concepts.

    Well, this is how it appears throughout my Software Design and Development class.

  3. Abhijit Nadgouda said:

    Rick, Luke thanks for your inputs. I completely agree with what you said.

    I especially agree with you about using appropriate problems to motivate students to write a program. I think what also affects is lack of facility for students to try out programs during classes. The practicals and the classes are separated.

  4. Matt Giuca said:

    I agree with this – as a lab demonstrator I’m the one in the trenches with the students actually trying to code. The continuous feedback I get is, we learn a lot more in labs than in lectures and tutes.

    I always ask at the start of class “has the lecturer gone over this” and I get a few nods and a “yeah, but we didn’t really get it”. So the labs is where it happens.

    Rick: “code first, think later”

  5. David Locke said:

    In everything we teach, confidence is the real subject. Every thing we are exposed to gives us that “oh, my, look at all the things I do not know” feeling. This is the conscious unknowing stage of learning. It will take a long time to reach the unconcious knowing stage.

    These stages are built into our brain: unconsious unknowing, conscious unknowing, conscious knowing, and fianlly unconscious unknowing. It doesn’t matter what you teach, or how, the learner still goes through this and suffers the emotional responses that go with them.

  6. Abhijit Nadgouda said:

    David, that really helped. Thanks! The problem gets aggravated if the learner does not make any effort and so he/she does not go through the stages but stays at the first or the second stage and for some reason gives up.

Say your thought!

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.



Abhijit Nadgouda
iface Consulting
+91 9819820312
My bookmarks


This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.