The Programmers Wall

I have noticed lately that during the course of a programmers education they hit a "wall" of sorts. This proverbial wall that everyone hits makes or breaks the programmer. THIS is the moment that you can do something to change their life. Will you help them and keep them interested in programming, or will you watch them struggle as they decide to quit programming forever. I know what I would do (and have done in the past).

This "wall" is normally hit after a few different things are learned. The "Small Wall" is the first hurdle into computer science. This wall is normally during the students first few weeks when they are learning program flow (If, Else, Loop, While, For, Case, Function Calls). This wall should not take long to get over, otherwise you might want to be concerned about the future of that persons career. The normal ways of getting over this hurdle is to force the person to sit down and get them to experiment with flow control (you will notice a pattern with my solutions, they all include this step). Show them on paper how the program will run through a loop. Get an IDE that shows the flow of a program (Dr. Racket does this pretty well if memory serves me correctly). This wall isn't one you will see outside (very often) of academia (unless they are just getting into programming).

The second wall I normally see is the "Medium Wall". This shows up during a paradigm shift (Scripting (Python) to Object Oriented (Java), Object Oriented (Java) to Declarative (Logic based ones like Prolog)). Normally during this time the specific parts of the language make people frustrated, and they might entertain the thought that can't keep up with their peers (who look like they are excelling). This is the most common with programmers who are 2-5 months into heavy programming. The reason for this is that this wall seems larger depending on how many paradigms the person has learned/faced before. If this is their first shift (normally into OO) they will feel more pressure/stress. Again the first step to help them is to sit them down and make them experiment with (my OO example) Objects. During this step I normally give them examples of real life problems, and how I would make it into a program. My default example is a card game. Explaining how Cards can be an object that Deck holds. And how Hand can interact with Deck by drawing cards and replacing them seems to help them wrap their heads around the idea of OO pretty well.

The third wall is (as you might have guessed) the "Big Wall". This is a wall that you will forever face. The question you face is "How do I become better at my craft". You can never be perfect at the craft, there is always room for improvement. The question that everyone will ask themselves is "How do I go about doing that?" The way that I try to get better is to force myself to work on something I normally wouldn't have, look at different paradigms, do programming competitions, read historical and recent texts (Pragmatic Programmer, Thinking in Java, any academic paper based in Computer Science or Math). I also ask peers what they are working on to try and soak up knowledge. But I think the best way of improving your craft is to work on projects. Pick up anything from another project at the office, or work on an open source project that you use on a regular basis. Eric Raymond actually covers this part pretty well in How to be a Hacker (You should also read his other stuff like The Cathedral and the Bazaar By Raymond, Eric S. (Google Affiliate Ad)).

Right now I'm still trying to study these walls that I have noticed, and looking for more literature about them (if they exist). I am wanting to do my Bachelors Essay on how students learn and what we can do to help them if they ever get stuck.

Here are some links to books/movies that I would recommend people to read and watch (especially some of my fellow students).

• Revolution OS (On Netflix I believe)
• Godel, Escher, Bach By Hofstadter, Douglas R. (Google Affiliate Ad)
• The Mythical Man Month
• Code Complete By McConnell, Steve (Google Affiliate Ad)
• Any book from this stackoverflow question
• These TED talks
• And anything that you think could be relevant to making you better at your craft. (Online code practice like Code Chef and Project Euler are good places to start)

Hopefully some of my peers will read this paper and know what wall they are at. I hope that they will ask for help if they ever get truly stuck so that we keep pushing the boundaries of what is possible.