problems – Technology in the Classroom

This week on IT Babble the Podcast Edition, you will hear Patrick and I discuss this topic that was posted on Slashdot.org: Revisiting Why Johnny Can’t Code: Have We “Made the Print Too Small”?

Any one claiming that programming is related to text size has a serious problem. Why? Because tools that you can use to write programs allow you to set your text size. These are the options that come with the built in terminal on the Mac:

Clearly, there are plenty of fonts, sizes, and colors available. People are grasping at straws trying to figure out why all the time spent having students plow through programming models simply is not turing them into “coders” or programmers. Trust me, it is not the font size.

The Main Problem

Everyone is over complicating the issues around learning to program, and they are not working towards the correct goals. The curricula are based on doing things in an hour, or 24-hours, or as a running elective without an objective.

Unless those in education set goals, at age appropriate levels, and have tasks that students can relate to, then attainment will be dismal. This process is not any different than learning a language. If a student is forced to do a language, and they have no application outside of the classroom, the language will not be learned.

The goal of programming, cannot be programming. This is what happens in all subjects when educators believe the subject should be taught, but have no practical application to connect the subject.

What Would a Curriculum Look Like?

I wrote a curriculum framework, yet to be fully implemented, for building problem solving skills and pattern recognition skills starting in year 3. The full framework can be seen here: Problem Solving with Computer Science and Programming: A Holistic Guide & Curriculum Overview.

The goal at every level is to build problem solving skills that connect to the physical world, as well as the digital world. The goal is always simple and repeated year after year. This allows a student to spend time working within the discipline, but also allows them to have time for all the other educational opportunities that are available.

Because this curriculum has a variety of experience based learning opportunities, students are more likely to apply what they learn to other subjects on their own initiative. When you state, this is programming class, and this is where you will do programming, then a student is less likely to apply programming outside of that framework.

What Does a Good Programming Class Look Like?

If students are required to take programming, then the lessons of a programming class cannot be based around following step-by-step instructions. Instead they need to be puzzle based, allow for teamwork, and follow a flexible assessment model.

One practice I like to follow for all new programming concepts is something I call “chopping wood”.

I once read that chopping wood is therapeutic because a person can get immediate results. Students new to programming need immediate results.

Here is how it works:

Students are given a working program, not piece of code, but a simple program with 3-4 parts.
The teacher asks the students to team up and annotate what they believe each part does. They do annotation with comments. The teacher asks the students not to run the program, just to study it.
The students run the program and play with it. Whatever features it has the teacher then defines so the students can experiment. This might take 5-10 minutes, it is not a game or challenge.
The teacher sends the students the program again, this time it is broken. The students compare the working model to the broken one and try to fix it.
The students break the program and send it to one another. (This can also be a homework assignment)
The teacher review the structures and logic.
The final assignment- add a new feature. Annotate what you will do inside the code, and try to achieve it. Make it clear students can sign-up for forums (teacher provides a list if age appropriate) to get help from their peers around the world.

Rinse and repeat with every new set of concepts. After students have a decent framework, they can start taking code that exists and combining it together, improving it, etc. Then after they have manipulated and used many scripts or programs, the process of making something unique will not be so trivial or difficult.

The assessments need to be peer (30%), self (20%), and teacher (formative/summative 50%). Students need to feel like they have some say in their work. Most teachers are not great programmers, and without some input from students, interesting solutions or attempted solutions, may be ignored. In programming attempts matter. The logic might be clear, but the syntax maybe jus be a bit off. Literally speaking – if you are not careful in programming you can fail a student with a great idea for a grammatical/spelling mistake.

Unless the goal is to have a factory of people typing instruction sets, schools need to focus programming efforts towards problem solving, pattern recognition, and team work. As much as possible, the subject of programming needs to be integrated and not separated. The student mindset should be that programming, writing code, etc. is simply a tool box that can be accessed anywhere and anytime.

Tony DePrato

http://www.tonydeprato.com

http://www.intslead.com/

When faced with a problem a programmer will ponder the cause and effect of the situation. They will look at various sides of it, even while it may be rapidly increasing, and look for its nature and its final outcome. Programmers understand that once you start a process, it has rippling effects, and even after you kill it- that process leaves a trace of itself. So making a rash decision or acting on assumptions without data is a bad idea.

After the problem is understood, the next step is to outline a solution. The solution is a set of goals or objectives the program needs to meet. Hopefully following these will lead to other unintentional successes as well. The success of the initial goals measure the success of the program. The main point to understand here is by compromising on a single goal, there is a risk of total failure. Each piece of a solution usually depends on the next. So the integrity of a program is also judged on the amount of compromise that was allowed; and integrity is what keeps a program alive when it is pushed to its predicted limits.

The next phase is to start working. Modules are made that focus on aspects of the solution and then they are connected so they can share information and influence one another based-on a set of rules. Testing and more testing happens in an environment that simulates the real-world. The idea is to be as close to real as possible, without causing any damage outside of the simulation. This is a natural trial-and-error process, and it mimics the most basic of all human learning.

The objectives are reviewed as the prototype emerges from the simulation, one being checked-off after the next. In the end, at least on paper, the goal is that all the objectives were met and that the data from the simulation suggests that in the real-world the solution will work.

Normally additional things are then considered, such as making the modules easier to access, easier to use, and then if time permits, aesthetics are applied.

The program emerges into the world, and is enabled to begin solving the problem-set it was designed for. Some parts are autonomous, others require human interaction. Data is constantly collected about the performance. Data comes in the form of logs sent by the program and feedback from the users. This data is studied and further changes are made. Changes come from data, and the best solution is chosen based-on the data. This may mean that the programmer has to learn something new, or apply a unique approach. Forcing a solution out of technological comfort is always going to compromise integrity. It will weaken the entire system, and eventually affect users.

Remember that the process began with an understanding of the problem, and the solution was not focused on brands or technology but on concepts and theory. There was always a goal of not compromising in order to preserve the integrity of the solution. The prototype was tested in an environment that was as close to real as possible. Data was driving all changes.

I think more processes need to follow this pattern. I feel like the method of thinking in code can apply to every aspect of education, school management, and day-to-day problem solving. It is not always possible to collect data as long as you want, to test ideas as long as you want, or even to get feedback as quickly as you want. But adhering to the concept and developing the discipline to achieve a data driven solution seems like it would filter out the noise and emotion that often clouds the best solution.

Tony DePrato

http://www.tonydeprato.com

Tag: problems

How to Teach Programming

Thinking in Code