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.

Response to: No Silver Bullet, Chimera of Software Quality, and Errant Trades

Response to stuff we had to read for Software Development class.

A common problem that is emerging in software development these days seems to be one of Quality. That isn't to say that all engineers work is shoddy, but with increasingly complex systems that they have to design problems can and will arise. No Silver Bullet makes the case that software development as seen from the non-technical managers perspective is actually something akin to a werewolf, they “transform unexpectedly from the familiar into horrors”. To combat the werewolf menace some people have tried coming up with a Lean(#1) software development model, but is this absolutely necessary? Will we find “the silver bullet” by forcing our engineers into a new paradigm? I think this approach would work for other types of work (data entry, HR, management), but I don’t think that cutting corners of the development will make a better product.(#2)

On the opposite end of the spectrum we have people saying that software needs to be regulated more, and developers need to have certifications before they can start working on different systems(#3). But as Les Hatton said in The Chimera of Software Quality: “In my experience as an employer, [software engineering] doesn’t even appear to have much to do with [employees] educational background. The best programmer I ever employed started as a 16-year-old with no academic qualifications... one of my worst programmers had a PhD in mathematics”. So if the educational background doesn't seem to have an impact on who is a good developer then I can safely say that certifications would be the worst possible thing you can do for this job market. The people who can do well in an academic setting (The PhD student) will be the ones that have the certification to work, while the 16-year-old will not even be able to take the test.

So how do we actually fix the quality of the software we make if we can’t just educate the developers? I think that the best way of changing the habits of the developers (and the software companies specifically) is the same way Gamers(#4) show their wants and needs to video game companies, though buying the product. I know it seems like we are doing that already, but hear me out. If we (as a collective of people) decided to not buy shoddy software, or actively going out of our way to contact the great companies and let them know that you appreciate them making great (and well tested) software then the mentality of software development will change. Right now everyone in the development world (and video game world) thinks that “We just need to push something out there, we can fix it later”. NO, do not let them get away with that mentality. Do not buy that software package, demand a refund for it. We as consumers hold the power to change how the developers are acting.

The same thing can go for people working in-house. Force them to use Test Driven Development if they have to. Bring in people who would use the software to get their input, even giving a few of them jobs to help figure out what they would want out of it. This is where education can come in and be effective, not education for certification, but education of the programmers that are already working for you. Bring in speakers for different paradigms, talk about agile development and create a cost\benefit list to see if it would work for you. There is so much that you can do working with internal software development that it is still mind boggling how much people are still willing to let it stay bad software.

(#1): Lean: http://www.qualitydigest.com/feb02/html/lean.html
(#2): Engineering-Matters wrote about “Where Lean goes wrong” already: http://www.engineering-matters.com/2011/03/where-lean-goes-wrong/
(#3): All three papers hinted at this in one form or another.
(#4): People who play videogames as a hobby.
Links to the papers:
"No Silver Bullet"
"Chimera of Software Quality"
"Errant Trades"

OUYA: The Open Source Gaming Console

If you haven't already heard the news a new KickStarter campaign for a $99 Android console has been fully funded in a day. Ouya originally asked for just shy of $1 million, and as I write this post it will be pushing the $3 million mark. With 28 days to go in the fundraiser we will now have an interesting competitor in the market for console dominance.

Here is the issue. We all know that Microsoft, Sony, and Nintendo are the current kings of the console wars and while I want Ouya to succeed we need to understand what this device should be aiming for. This device is not meant to kill the current console kings, but to allow indie developers with a tight budget to continue development on consoles without fear of paying for licensing and developer consoles. Have you noticed that most of the indie games are not on the console but and iOS and Android? It is because if you had the drive to make a game you could do it on a shoestring budget and a group from 1 to 10 people.

Ouya has already noted that all games must be partially free to play (demos, in game payments for items, subscriptions to higher level areas) and this is a good thing, but what the developers must keep in mind is that people will not want to play a game that is pay to win. Games like League of Legends and Guild Wars do free to play well. Stuff that can be bought with real money does not make the player automatically better, they can only help the player with things like more item storage (rune slots, and chests) which could be bought with in game currency. The other thing you can buy (that you can not with in game currency) are only cosmetic (skins and costumes). The moment that a developer on Ouya breaks this standard they will become a pay to win game, and no one will want to play it.

Now, this rule that Ouya put up means that bigger companies might not want to venture into this hardware because it might not get the full investment back that it put into the game. This is not a bad thing. I would not mind seeing more developers that don’t have much to lose and do something interesting that would normally not get funded (examples being games like Minecraft, Flower, Cave Story, Amnesia, and World of Goo). I can also see this turning into a service like Steam with all my favorite games on there (with free demos) that I could buy (TF2, Half Life, Portal) if I so choose.

But, the reason I think that the Ouya will work well? It is all open. Every system can be rooted (rooting: allowing a system to gain "root" or privileged access), every screw is standard (you can open the box by yourself), you can create peripherals that connect to USB or Bluetooth, and they might even give you the hardware design. You know those old plastic Rock Band/Guitar Hero controllers that are in your attic? Wouldn't it be awesome for a game developer to create the drivers and a game that allows you to control some aspect of the game with them? I think it would.

Cheers Ouya, and let us hope that you can bring back the fun of the living room.

P.S. I already put in some names of games I want on the system. Read more about that on their latest update here: http://www.kickstarter.com/projects/ouya/ouya-a-new-kind-of-video-game-console/posts

Why call it "Limit Equals One"?

When I first started learning how to program I felt like I would never be able to create things that everyone else around me seemed to be working on. Over time I started gaining experience and at the moment I still think of myself as novice at best. But I feel like I should chronicle my problems and solutions as well as my outlook on current events in the technology industry so I can look back on how I currently think and view my change over time.

The "Limit Equals One" problem is an inside joke of my first major oversight while working on a personal project. During my first semester of Python at CofC I was playing around with Google App Engine (a Platform as a Service computing architecture) and the Yelp API (use Yelp's data to search for restaurants) to be able to aggregate date ideas for people (me). After finally getting used to printing data on the screen, and grabbing data from Yelp I finally put two and two together to make seven! ... It didn't work. GAE and Yelp did not like talking like it did when it was just a local API call. After playing with the code enough I finally got it to spit out a single location when I called out to Yelp. Normally the Yelp response to a query though was to return 20 locations from a query. I could not figure out why it wasn't working as intended especially because it would return 20 locations when I did the query from a local machine.

During the first meeting of SHDH (SuperHappyDevHouse-Charleston) I found my problem. James (the person I dragged with me to the event) kept asking me the entire week I was frustrated with the problems if he could see the code. I denied him because it was actually a small part of a bigger project that wasn't my idea, and I didn't want to disclose information about it. But, during SHDH he finally got through and I showed him my code. "What is this Limit=1 mean?" he asked. I looked at the code and thought about it for a minute and remembered what happened. Originally when I got data from Yelp it was in JSON format, and I have never decoded something like it before, so in the call to Yelp I set a limit to only return one object so I can learn how to parse it. In my joy of parsing everything correctly and changing the code that ran locally I never realized that I still had the limit on the code in GAE. The entire time I thought there was a problem with the way I setup my system in GAE, when in reality the problem was a single line of code that just needed to be changed.

After changing the line of code and pushing it up to GAE it ran fine. James sat there smug as hell and said "I'll never let this down. You know that right? When you are helping someone and they get depressed for not getting it, I'm going to tell them about this so they know that everyone does something stupid at one point or another." And to this day he still asks me if the problem I'm currently trying to debug is a "Limit equals one" problem. He even admits that he had something that came "close" to it.

The few things I can say I learned from this are:

1. Always work on something else if you have been looking at the problem for a while.

I figure that looking at it with fresh eyes and a clear mind will be better then looking at it thinking you know something works the way it is supposed to.

2. Ask for help (or at least accept it when someone really wants to)

My problem was one that I still have today. I think that if I hit my head against the wall enough I can solve every problem. And while this may be true it might be better to fail a few times then ask for a better way then to fail a hundred and still working for a solution. While I do agree that failures will teach you more then right answers, there is a limit before you start getting disheartened and feel like it isn't even worth it.

So I haven't had a limit equals one problem in a while, but I have still had eureka moments that I think are worthwhile to me at least. Coming up with an algorithm to find prime numbers for Project Euler just to find out that I have recreated the Sieve of Eratosthenes without knowing about it was interesting and made me go learn about the enhancements people have made to it....

But more on that later.