I recently completed two summer school courses at our local community college. I took one online course in Excel and one face-to-face class in Programming Logic at the local campus. I never dreamed I'd be going back to school at age 60 - well, not unless it was to follow in my parents' footsteps and pursue a Ph.D. But last year, I lost my job. I figured, like many other experienced and educated workers probably did, that certifications would prove the most efficient way to update my skills in the newer technologies that my programming degree did not cover or that I had not had opportunity to use in the work place. Specifically I was interested in graphics, all things web, and newer programming languages as they applied to design, which seems to be my passion. In addition to my IT background, I also have a masters degree in Educational Technology with a concentration in Instructional Design. So naturally, I can't resist reflecting on my current situation as an adult learner and have already written a couple of blog posts about my summer school experience. One of the posts includes an analysis of the online Excel course. In this post I'd like to consider the F2F Programming Logic Course.
My local community college allows people to attend for free after they turn sixty which I did this May.
It also offers certification tracks as well as traditional degree objectives. Itching to get started, I enrolled in summer school, even though the courses I wanted were not offered until fall. I enrolled in the Excel Class to get an MCAS/MOS certification, and I decided to take an introduction to programming logic course even though I probably knew most of what the course would cover. I told my advisor (who also turned out to be our instructor) that I thought it would be a good way to get my feet wet, and that I figured that about 70% of the course would be a good review, and 30% would be new material. He agreed and signed me on.
I had so much fun with this programming logic course. It was so interesting to be able to compare my training 25 years ago not only to see how much the content had changed but also how the student population had changed, and how the methods of teaching the content had changed. I was a bit surprised at how much the content had NOT changed - much of the material sounded like it came straight from my programming classes 25 years ago. Of course the review was helpful. I was impressed with how much the teaching methods had changed. In the first place, we did not learn programming logic separately from a programming language 25 years ago. Unfortunately the language we learned was BASIC - various interpreter versions, plus a souped-up compiler version, which looked more like C and Pascal. Still, not really a big seller in today's market or even that of yesteryear. I liked immensely that Ivy Tech taught the programming logic part separately from imprinting us on a “dead” language.
The textbook used this summer - Starting Out with Programming Logic & Design by Tony Gaddis was WONDERFUL. I was amazed at how simple it made concepts that once seemed so hard, and I appreciated the simplified real-world applications and examples. About the only fault I could find is that the text almost explained things too much. Adhering to pedagogical best-practice, it explained what it was going to show us (the concepts and algorithms). Then it showed us (the pseudocode and flowcharts). And then it explained what it just showed us (more paragraphs). Sometimes I was like, Okay I get it already, all these words are just slowing me down. But taking the time to process that right-brained intuitive grasp of things through the language center is an essential part of learning a software package- and especially beneficial if you will be training or supporting that software later on. As I read on, I sometimes discovered there was more to be learned. So I usually didn't skip. Part of learning is giving yourself enough breathing space, treating your brain to the luxury of a nice-long soak, taking time to renew an old acquaintance-ship rather than just giving it another passing nod as you dash by at a dead run. That's something you learn as you get older. ;)
Because the focus of the course was more on the logic than the language, the instructor scaffolded1 us with the JavaScript by providing us with small programs to type in and then modify. My classmate Mark, who usually sat at the computer next to mine, shared an aha moment when he observed, "It's better to retype the program than to copy and paste it." I had resisted copying and pasting (well, for the most part) for that very reason. Later in the semester the JavaScript laid ground for introducing OOP. As an added benefit, it also introduced HTML tags, with "whom" I'd already struck up an informal acquaintance and much appreciated the more formal introduction.
Throughout the course the instructor did a great job inspiring everyone to work in their Zone of Proximal Development1. The assignments and particularly the two logic projects allowed students to experiment and play at the top of their game while learning common core concepts. The class did skip the chapters on Sorts, Searches, and Recursion, considering that those concepts might best be postponed to a later course. I, however, did not want to skip those. So I read those chapters and implemented the three sorts in Raptor - Bubble, Selection, and Insertion. I added my own twist by pulling in a file and counting how many loops it took each method to sort something. Okay, so I was really curious, what can I say. I also implemented a recursive Binary Search both in JavaScript and in Raptor because I really wanted to learn about recursion. Don't get me wrong, the book handed us most of the logic in pseudocode, so I was just implementing - my point being that it was a great scaffolding technique to be able to take the book's logic and implement it with my own twist. Besides, if I'd had to recall those algorithms from 25 years ago, I'd still be working on them instead of on this blog article! (Although I am a programmer/analyst by trade, my work experience had not afforded much opportunity to use - or at least to write - binary searches and the various sorts through the years.) The scaffolding in this case encouraged me to go ahead and spend the extra time reviewing and revisiting concepts to clear up any remaining confusion left over from the years when everything was so new.
We were assigned regular chapter readings, homework exercises in pseudocode, and lab exercises in Raptor or JavaScript for each class. Every 4th class or so, we had a quiz which consisted of standard test questions as well as lab exercises. Our first logic project was to write a grading program in Raptor and our second, due at the end of the semester, was to write a game called WAR in JavaScript. The second project was especially fun. The final two classes of the semester covered Event Driven Programming and OOP. Our instructuor made the comment that he didn't know why courses always saved these til the end. He felt they should be introduced early on. I very much agree with that. Just because the foundational material emphasizes the control structures, file processing, and the concepts of functions, procedures, modularization, and scope, this shouldn't preclude "thinking in OOP," should it? He mentioned that he was writing a textbook, so I'm curious to see if he will include these topics early on. Since OOP was introduced at the end of the semester, we weren't required to use that approach on our second logic project even though it was implemented in JavaScript. But the instructor also allowed us to do two extra credit programs. So after writing a procedural version of the the War Game in which I implemented a binary search to help keep track of cards played, and a recursive error checking routine, I rewrote most of the program using an OOP approach for extra credit. It was a cool exercise. You may ask why I didn't write it in OOP to begin with? Well, I have self-studied OOP and I have used OOP a little at work - but it's been awhile, and I just needed to break down the problem procedurally to help me best conceptualize it in OOP. I suppose that's a normal jumping off point for procedural programmers and that they eventually get past it. It's sort of like learning a foreign language. You know you really know it when you stop translating it and start to think and dream in it.
The instructor also understood our need to see visual side-by-side comparisons, and developed tables comparing Pseudocode, Raptor, and JavaScript as we progressed through the semester. I suppose a similar approach could be adopted with procedural programming and OOP, just to get students to start thinking in those ways. A constructivist approach2 might even go one step further and have students build (and share) their own comparisons over the course of the semester. In any case, I believe that side-by-side visual comparison is a particularly effective strategy for reinforcing the programming logic component of the course.
At the end of the semester the instructor told me he had enjoyed having me in class and that he hoped it was worth my time. It truly was. I think there’s perhaps an overlooked demand by colleges and universities for providing an affordable, doable way for IT professionals to stay current. I have to wonder how many of the people I went through classes with at Purdue are even still in the field. (I know one person who was convinced that computer technology was a better major than computer science who has since become a hospitalist.) People get knocked out of the IT field by rapid progress and lack of opportunity at work to keep up with it, and they often don’t realize that they need to keep going back to school. Gone is the era of when you're through, you're through - albeit just for a while. While the necessity of keeping up in one's field has always been a given, we used to have an expectation of moving on after finishing our education. When many of us finished our first 12, 16, 18, or 20 or so years of schooling, we were ready to discover that big world outside of school - work, relationships, hobbies, etc. If we did decide to go back to school, it was either to explore something entirely different (like I did with my programming degree) or to pursue an advanced degree (like I did with my Ed Tech degree). We also used to have different expectations for professional development opportunities. Times have changed and like the summer rains, many of us are flooding the hallowed halls of learning, our book bags and bifocals in tow, this time to earn certifications and to upgrade our skills in the same fields we started with not not that long ago.
JuneBug
1Scaffolding, a concept introduced by Lev Vygotsky, proposes, among other things, that students can go further faster if you can find ways to scaffold them (my rough definition). This has to do with a student's "zone of proximal development which is the difference between what a learner can do without help and what he or she can do with help."
2Constructivism's basic tenet is that knowledge is not so much transmitted as it is constructed. While a teacher or a text may present material, in the end the student must have encoded the information structures in his own brain to be able to use and retrieve them, a process known as knowledge construction, which also dovetails with theories of Cognitive Psychology. As a learning theory, Constructivism is more about a change in focus. It eschews traditional teacher-lead methods to suggest that learning activities be intentional in helping facilitate or scaffold the knowledge construction process. This approach is referred to as being more student-centered.
Related articles:
My local community college allows people to attend for free after they turn sixty which I did this May.
It also offers certification tracks as well as traditional degree objectives. Itching to get started, I enrolled in summer school, even though the courses I wanted were not offered until fall. I enrolled in the Excel Class to get an MCAS/MOS certification, and I decided to take an introduction to programming logic course even though I probably knew most of what the course would cover. I told my advisor (who also turned out to be our instructor) that I thought it would be a good way to get my feet wet, and that I figured that about 70% of the course would be a good review, and 30% would be new material. He agreed and signed me on.
I had so much fun with this programming logic course. It was so interesting to be able to compare my training 25 years ago not only to see how much the content had changed but also how the student population had changed, and how the methods of teaching the content had changed. I was a bit surprised at how much the content had NOT changed - much of the material sounded like it came straight from my programming classes 25 years ago. Of course the review was helpful. I was impressed with how much the teaching methods had changed. In the first place, we did not learn programming logic separately from a programming language 25 years ago. Unfortunately the language we learned was BASIC - various interpreter versions, plus a souped-up compiler version, which looked more like C and Pascal. Still, not really a big seller in today's market or even that of yesteryear. I liked immensely that Ivy Tech taught the programming logic part separately from imprinting us on a “dead” language.
Let's take a little trip down memory lane just for purposes of comparison. 25 years ago I was working full time whilst starting a second undergraduate degree, this one in computer programming technology. My first had been in education. While computer science had probably been around for 20 or 30 years or so, the university's new technology department was only six or seven years old. C was an elective class (which I also took in summer school), Apple had just come out with their GUI system, and Wndows, Visual Basic, and C++ did not exist. We learned on mainframes. Heck, I had only just missed the punch cards by a year or two! As I worked my way (slowly because programming courses were notorious time hogs) through the curriculum, the PCs began to replace dumb terminals in the computer labs. However they still acted as terminals to access a mainframe programming environment, with the added advantage of providing general word processing and other office productivity tools that students could use to do homework. My degree became a moving target as the curriculum changed to keep up with the times (eventually the department taught COBOL exclusively). OOP and event-driven programming were around, but the department would not catch up with these until the mid to late 90's or early 2000's. So back then we could only dream ... But in all fairness, it was likely that way that everywhere.In contrast, Ivy Tech's approach to teaching programming logic was to use the familiar hierarchy charts, pseudocode, and flowchart symbols I had learned way back when but not emphasize any particular programming language. It was interesting to see how Pseudocode had standardized over the years. The course used a visual programming tool called Raptor, which allowed us to build and execute programs using flowchart symbols, and which, while not perfectly dovetailed with some of the concepts being taught, was still very cool, in my opinion. Later in the semester we used JavaScript which could easily be tested in our web browsers. I suppose a lot of Ivy Tech's choices, like Purdue's 25 years ago, were driven by cost and practicality. Back then BASIC was the omnipresent low cost learning tool. Today, Raptor is freely downloadable and JavaScript runs in any web browser. But I believe the Ivy Tech approach truly did teach us programming logic concepts along with the expectation / understanding that these would be implemented differently in different languages. (Actually I think I'd enjoy taking a computer science class sometime where we had to write a compiler. I think it would be really helpful to understand things at that level. But I digress.)
The textbook used this summer - Starting Out with Programming Logic & Design by Tony Gaddis was WONDERFUL. I was amazed at how simple it made concepts that once seemed so hard, and I appreciated the simplified real-world applications and examples. About the only fault I could find is that the text almost explained things too much. Adhering to pedagogical best-practice, it explained what it was going to show us (the concepts and algorithms). Then it showed us (the pseudocode and flowcharts). And then it explained what it just showed us (more paragraphs). Sometimes I was like, Okay I get it already, all these words are just slowing me down. But taking the time to process that right-brained intuitive grasp of things through the language center is an essential part of learning a software package- and especially beneficial if you will be training or supporting that software later on. As I read on, I sometimes discovered there was more to be learned. So I usually didn't skip. Part of learning is giving yourself enough breathing space, treating your brain to the luxury of a nice-long soak, taking time to renew an old acquaintance-ship rather than just giving it another passing nod as you dash by at a dead run. That's something you learn as you get older. ;)
Because the focus of the course was more on the logic than the language, the instructor scaffolded1 us with the JavaScript by providing us with small programs to type in and then modify. My classmate Mark, who usually sat at the computer next to mine, shared an aha moment when he observed, "It's better to retype the program than to copy and paste it." I had resisted copying and pasting (well, for the most part) for that very reason. Later in the semester the JavaScript laid ground for introducing OOP. As an added benefit, it also introduced HTML tags, with "whom" I'd already struck up an informal acquaintance and much appreciated the more formal introduction.
Throughout the course the instructor did a great job inspiring everyone to work in their Zone of Proximal Development1. The assignments and particularly the two logic projects allowed students to experiment and play at the top of their game while learning common core concepts. The class did skip the chapters on Sorts, Searches, and Recursion, considering that those concepts might best be postponed to a later course. I, however, did not want to skip those. So I read those chapters and implemented the three sorts in Raptor - Bubble, Selection, and Insertion. I added my own twist by pulling in a file and counting how many loops it took each method to sort something. Okay, so I was really curious, what can I say. I also implemented a recursive Binary Search both in JavaScript and in Raptor because I really wanted to learn about recursion. Don't get me wrong, the book handed us most of the logic in pseudocode, so I was just implementing - my point being that it was a great scaffolding technique to be able to take the book's logic and implement it with my own twist. Besides, if I'd had to recall those algorithms from 25 years ago, I'd still be working on them instead of on this blog article! (Although I am a programmer/analyst by trade, my work experience had not afforded much opportunity to use - or at least to write - binary searches and the various sorts through the years.) The scaffolding in this case encouraged me to go ahead and spend the extra time reviewing and revisiting concepts to clear up any remaining confusion left over from the years when everything was so new.
We were assigned regular chapter readings, homework exercises in pseudocode, and lab exercises in Raptor or JavaScript for each class. Every 4th class or so, we had a quiz which consisted of standard test questions as well as lab exercises. Our first logic project was to write a grading program in Raptor and our second, due at the end of the semester, was to write a game called WAR in JavaScript. The second project was especially fun. The final two classes of the semester covered Event Driven Programming and OOP. Our instructuor made the comment that he didn't know why courses always saved these til the end. He felt they should be introduced early on. I very much agree with that. Just because the foundational material emphasizes the control structures, file processing, and the concepts of functions, procedures, modularization, and scope, this shouldn't preclude "thinking in OOP," should it? He mentioned that he was writing a textbook, so I'm curious to see if he will include these topics early on. Since OOP was introduced at the end of the semester, we weren't required to use that approach on our second logic project even though it was implemented in JavaScript. But the instructor also allowed us to do two extra credit programs. So after writing a procedural version of the the War Game in which I implemented a binary search to help keep track of cards played, and a recursive error checking routine, I rewrote most of the program using an OOP approach for extra credit. It was a cool exercise. You may ask why I didn't write it in OOP to begin with? Well, I have self-studied OOP and I have used OOP a little at work - but it's been awhile, and I just needed to break down the problem procedurally to help me best conceptualize it in OOP. I suppose that's a normal jumping off point for procedural programmers and that they eventually get past it. It's sort of like learning a foreign language. You know you really know it when you stop translating it and start to think and dream in it.
The instructor also understood our need to see visual side-by-side comparisons, and developed tables comparing Pseudocode, Raptor, and JavaScript as we progressed through the semester. I suppose a similar approach could be adopted with procedural programming and OOP, just to get students to start thinking in those ways. A constructivist approach2 might even go one step further and have students build (and share) their own comparisons over the course of the semester. In any case, I believe that side-by-side visual comparison is a particularly effective strategy for reinforcing the programming logic component of the course.
At the end of the semester the instructor told me he had enjoyed having me in class and that he hoped it was worth my time. It truly was. I think there’s perhaps an overlooked demand by colleges and universities for providing an affordable, doable way for IT professionals to stay current. I have to wonder how many of the people I went through classes with at Purdue are even still in the field. (I know one person who was convinced that computer technology was a better major than computer science who has since become a hospitalist.) People get knocked out of the IT field by rapid progress and lack of opportunity at work to keep up with it, and they often don’t realize that they need to keep going back to school. Gone is the era of when you're through, you're through - albeit just for a while. While the necessity of keeping up in one's field has always been a given, we used to have an expectation of moving on after finishing our education. When many of us finished our first 12, 16, 18, or 20 or so years of schooling, we were ready to discover that big world outside of school - work, relationships, hobbies, etc. If we did decide to go back to school, it was either to explore something entirely different (like I did with my programming degree) or to pursue an advanced degree (like I did with my Ed Tech degree). We also used to have different expectations for professional development opportunities. Times have changed and like the summer rains, many of us are flooding the hallowed halls of learning, our book bags and bifocals in tow, this time to earn certifications and to upgrade our skills in the same fields we started with not not that long ago.
JuneBug
1Scaffolding, a concept introduced by Lev Vygotsky, proposes, among other things, that students can go further faster if you can find ways to scaffold them (my rough definition). This has to do with a student's "zone of proximal development which is the difference between what a learner can do without help and what he or she can do with help."
2Constructivism's basic tenet is that knowledge is not so much transmitted as it is constructed. While a teacher or a text may present material, in the end the student must have encoded the information structures in his own brain to be able to use and retrieve them, a process known as knowledge construction, which also dovetails with theories of Cognitive Psychology. As a learning theory, Constructivism is more about a change in focus. It eschews traditional teacher-lead methods to suggest that learning activities be intentional in helping facilitate or scaffold the knowledge construction process. This approach is referred to as being more student-centered.
Related articles:
No comments:
Post a Comment