What if money was no object?

Currently Listening to:
Noisestorm - Solar
Love Automatic - Save My Soul 

One of my favorite things to do in this world is problem solve. Other things that I love to do include teaching peers. These two passions of mine come together quite often, helping fellow students learn new technologies, or helping them understand something they didn't quite understand in class. I've quoted some of my favorite people in the past like Daniel Pink and Sir Ken Robinson, but today I'm going to talk about Alan Watts. One of my favorite lectures included the "What if money was no object" talk.

How many of you reading this actually like what you do at work? Maybe the environment is bad, maybe the people are annoying, but do you actually like what you do? Most people that I've talked to seem to not enjoy their job. This baffles me. They go to work day in and day out trying to make money but they don't like their job. They have the "fun" on the weekend. "All rech and no vomit" is the phrase Watts used to describe this mentality of forcing yourself to do this, "... you will spend your life completely wasting your time. You will be doing things you don't like doing in order to go on living. That is, to go on doing things you don't like doing... Which is stupid!"

Personally I love what I do. If I lived in a post-scarcity utopian society, I would still do what I do now. I may not be the best person to come up with an algorithm, I may not be the best coder, but at least I can say I love what I do. Asking students in the computer lab about what they want to do, I get plenty of answers that have nothing to do with coding, and to those students I've started asking why they went into computer science. "For the money" is a typical response I get. These students are about to graduate and they either don't know what they want to do for a living, or actively don't want to go into software development. I understand that knowing how to code can improve almost everyones problem solving techniques as well as help them with the day to day for their job (knowing how to script a mundane task saves you in the long run), but I have problems when the students seem to despise what they do.

Another issue that I've seen recently is the lack of effort on the part of the individual to better themselves. Ignoring the population that does not like what we do, we are left with those who I would assume are like me, motivated to better themselves over the weekend by working on a project, reading a book on the subject, contributing to a big open source project, or attending a conference/seminar. I've tried to put on events for my fellow students and peers in the area, including BarCampCHS, local programming competitions, helping with the Hack-a-thon, teaching teachers how to teach, and so on. However, when I start telling everyone to attend these events for the learning experience, or the meet and greet that they would have with local gurus in the community as well as people in a position to hire you, I get the same students every time. I've started referring to these students as "my go getters". They are the ones that attend/plan/promote all the events. All in all that is about 30 students that seem to enjoy what they do enough to want to better themselves. I can't say that the other students are bad, because honestly I haven't met them. They don't want to hang out in the lab (understandable, I know that I'm a very extroverted person and most of my peers would define themselves as introverted), or they don't think that going to these things are very important.

When I'm talking to some of my friends who do things in the local community I'm normally asked to give recommendations to them about who I would hire, and to pass on the message that someone is hiring to them (remember it is who you know, not what you know). Why would I recommend someone who I've only met once in the classroom who never speaks out. I would rather recommend someone who I've dealt with outside the classroom in a professional manner. The planning team of BarCampCHS sits pretty high on that list seeing as how I saw on a weekly basis their problem solving techniques as well as planning and execution of running a big event. Students who talk to me on a regular basis about interesting problems or new technologies are right behind them. The conversations I've had range from talking about ICPC problems, new technology stacks, hosting of web apps, design issues, high performance computing, low level hardware coding, open source licensing,  and many other topics that range from an individual problem to problems spanning the entire field of software development.

I've had conversations about why students don't want to do these things, and the mutual agreement is to just not even care about them, so consider this my last plea to those who don't seem to care (and honestly, if you are reading this either you do care, or you just like me): Instead of that one game of league maybe you could solve a problem on UVa, instead of going to r/funny you can instead read an article from r/learnprogramming or r/programming, instead of complaining about your grade in advance algorithms maybe you can implement your own library containing sorting algorithms and different data structures. I promise you, if you do these things you will feel better about your choice in degree/job. You will start to hone in on the part of programming/computer science that you enjoy most, because as Alan Watts said, "Better to have a short life that is full of what you like doing than a long life spent in a miserable way. And after all, if you do really like what you're doing, it doesn't matter what it is, you can eventually become a master of it. The only way to become a master of something is to be really 'with it' and then you'll be able to get a good fee for whatever it is. Therefore it's so important to consider this question. What do I desire?"

Contributing to Open Source, Mentoring Improves Knowledge

Currently Listening to:
GoldFish - One Million Views
Approaching Nirvana - 305 

I've been working at Sparc for almost eight months now, and I can honestly say that having responsibilities outside of class related to your major will increase your skill level exponentially. I'm not talking about an internship where you are just fetching coffee for the people, but actually contributing to the workload in a meaningful way. This is what should be encouraged by academia, jobs that actually push you to try to maintain a work/life balance where work is split off into academia and a career.

My parents have always told me that I needed to take a job during the school year. I've done the jobs that were not related to what I wanted to do during high school (bouncy castle birthday party place), but during my senior year of high school I realized that I could get a job for what I wanted to do for a career (at the time), computer repair. During my senior year in high school, as well as the next 5 years of college (2 at Trident Tech for an Information Systems degree, and 3 years at College of Charleston working to a Computer Science degree) I did everything from go to peoples houses repairing computers, working at a chain store repairing computers, and being a systems administrator for almost three years. But I knew that after those 6 years of doing I.T. work, I wanted out. The grind of doing the same thing ("turn it off and on again") was becoming old hat. Sure I was good at what I did, and could make a nice living off it, but it wasn't what I wanted to do.

That is where software development comes in. During my time working on small projects (and some not so small projects) at school I realized that I enjoyed the problem solving that coding brings. Working on open source projects (the class that made me keep this blog/work on open source) showed me that I could make money solving challenges that I enjoyed working on. I applied to a few different places to see if I could get an internship around town for my last year of college, a few places responded back but I had friends who worked at Sparc, so I eventually decided to work there (I'll write a post about working there soon).

Working on a big project that you didn't help create is a humbling experience. Everything seems to be a jumbled chaos, you don't know why everything is written the way it is, and you don't know where to look for the simplest bug fixes. Reading other peoples code and understanding the flow is a gained skill, and thankfully my work on open source projects helped me gain those skills. After working at Sparc for about 4 months, they introduced a game to the company (on top of the Hackathon that they already did). A bingo board was produced with the top 24 most starred GitHub repos with 5 spots (4 repos and a free square) already claimed. The rules were simple, get a pull request in, receive bragging rights (as well as cash). The moment I saw the board I ran over to my computer and created a pull request to GitIgnore for a project type I knew they didn't have. After not hearing back within a few days my enthusiasm dwindled for that project, but I decided that I would want to work on projects that A) I use at work or home and B) would sharpen the skills I wanted to improve (Javascript specifically).

Eventually finding the Brackets project and using it at home I found a few solutions for bugs and worked on them over the weekend. I talked to a few people on the project and most of my pull requests were accepted! I was excited. Talking to Jeremy at work I learned I was the first one to get a request pulled. The feeling was great, I found something that I could help with outside of work that will help me with work. Around a week later I learned that my request for GitIgnore went in (Another one bites the dust goes here). A second spot on the board? My bragging rights just increased more, as well as my knowledge of software development in general.

I wanted needed more more knowledge. Sparc was helping me learn Angular/Play/Design and other things, but working on these other projects helped reinforce all the things I was doing at work. Turning working on open source projects into a game made me want to learn more, to share more. Eventually I had to modify part of our code to implement Modernizr to check if the browser would support our new feature. Modernizr was also on the bingo board. During that weekend I learned a lot more about the Dom as well as how to create tests to see if a browser supports a feature. I decided that I wanted to work on implementing a test for the Keygen tag. But for the life of me I couldn't figure out why everything wouldn't work for me. Eventually seeking out help from Calvin at work, I learned about something called the Shadow Dom. I've never even heard of it because I didn't know where to look. Just having a mentor there who can point you in the right direction is a godsend.

After a few more days of banging my head against the wall Calvin and I had another talk, this time he told me that he was also working on a pull request for Modernizr. Game On. We spent a few days working on different things, me on my Keygen problem and Calvin his own feature detection bugs. We both opened up a second pull request around the same time because we wanted to gain the bragging rights (and with both of us working on two different bugs it means we still have the same chances of getting ours selected). Then it happened, "guess what? ;p" was the message. I've lost. But just because he got his request in first to me wasn't as bad when I thought about everything I learned over just that short period of time. Having someone there forcing me to try and become better by being a rival was one of the best things that I've ever done. I know that competition helps with the competitive "I want to be better" spirit, which is why I've started the coding competition practices at College of Charleston. It is what I believe to be the reason Sparc does the Hackathon, to help create a collaborative, yet competitive stage to help people become better at their craft.

So why tell you all of that? To help make a point. Students who seek out knowledge/mentors/competition will most likely have more fun than their counterparts. Attend events like POSSCON and BarCamp to improve your knowledge and find a mentor. Compete in competitions like the Hackathon and ICPC to be in an environment that will make you want to be better. Work on projects outside of the classroom (Open Source ones for community, personal projects for the itch (first lesson) that you will get to write something for a problem you know of). Those are the type of students I want to see more of.

Preparing for POSSCON

Currently listening to: 
Kettel - Boekebaas 
Bassic - Daydreamer

Adding a currently listening to. I think I'll start adding that to my blog posts from now on seeing as how some of my friends ask me for new music to listen to all the time, I might as well give them a easy way of finding new songs ;)

Finally the blog where I get to pick the speakers I'll be going to attend during POSSCON. A few of my friends are actually going to be presenting at the event and I have been asked to attend their talks, but I'll list the talks that I'll be attending for the sake of the class instead.

The first talk that I want to attend is one that I already signed up to do with my current boss Clay. There is a special workshop held on the second day where SparkFun is going to be teaching us how to solder, and then later in the day teach us how to program our newly made simon says game. The class is going to be held by a few people from SparkFun and should make an interesting second day to POSSCON (that and I get to annoy Clay on the ride back by playing simon says the ENTIRE ride back to Charleston. I'm sure he would love that).

The second talk that I want to attend is actually a SparkFun employee who is giving a talk on how to teach STEM in schools. Lindsay Craig will be leading the session. I have already talked about my wanting to work in education here, here, here, and here. So I feel like this is a class that is almost required of me to attend. Hopefully he talks about motivational techniques like gamification and other types of external and internal motivators that we can instil in the younger generation.

The third talk that I want to attend is "Javascript: the language every developer should know" by Tom Wilson from Jack Russell Software. Seeing as how I have met Tom a few times (BarCamp, Code workshops for test driven development, Hack-a-thons) I feel like I should trust him with a title that has an absolute, "Everyone should know". The abstract for the talk indicates that Javascript has matured to the point of being something beyond just a scripting language, and I feel like I should look into it more than I have in the past.

Other than attending the talks my job during POSSCON will be to sit at the Obsidian booth giving out stickers and showing off the functionality of the project. I can't wait to see if there is any hype or feedback from them. Besides, I'll be keeper of the stickers that everyone in our class wants so bad >:D

What's Happening?

For this blogpost we had to grab a recent article from an ACM or IEEE magazine and talk about it. I chose to write about "The Great and Terrible Oz" by Grady Booch from the January/February 2013 edition of IEEE Software.

The article expresses the importance of education of the public when it comes to computers. As technology use increases and gains momentum the public seem to be getting further and further from how software actually works. Everyone from your parents to politicians are losing touch with how technology works, and this is a problem. The further the curtain puts people out of the knowledge the less they understand about technology and the prevalence of "magic" in the system will increase. I have seen this gone awry many a time. People think that they "just get viruses" because lack of knowledge. People pay a prince in Nigeria to be part of the rich. People steal software because "it is already made". Without the proper knowledge people are going to get more and more lost.

The problem with this day and age is that technology is growing faster than the population can adapt. Sure the tech savvy know what is going on, but the rest of the world will blindly go out and buy iPad's because of targeted advertisements. My parents in particular still ask me for computer help from time to time, but I have trained them to a level where they only ask if they really need help. Another thing that I have done to help them be more educated is to send them videos of scams and tutorials of different technologies. They won't be falling for a 419 scam anytime soon because they know a little bit about electronic banking.

I have also noticed that with education the amount of viruses on a given machine approaches zero. Switching my parents from IE to Chrome (admittedly by tricking them into thinking Chrome was IE) drastically reduced the number of phone calls asking for help. Now, I'm not saying that everyone has to do what I did to my parents (that was for my own personal gain), but a little bit of education goes a long way. With acts going through congress like SOPA and PIPA an education of the public would go a long way of protecting the internet and my job security in the future.

How to teach Programming

Subversion Under Control

Our team had a dinner meeting tonight. Hunter told us that we would be receiving our source code later in the evening. Everyone was excited to head back to the lab to talk about the source code. I now have on my hard drive a working copy of Obsidian. We talked briefly about the different main parts of Obsidian, but the main idea is for each of us to go in and explore the code ourselves. We came up with a list of functionality that is needed for completion of the project as well as some possible areas of extension that we could work on. To learn the source code we decided that going through the source and creating class diagrams of the packages and how everything interacts would be best. This way we are forcing ourselves to look at every file and method in the project and understand their connections. We might even get a good class diagram that we can use to teach other people about the code at a faster pace then them just looking around.

Programming Education

I have advocated that the educational paradigm that we have currently (not just for programming) is broken and needs to be drastically changed. Sir Ken Robinson is one of my favorite public figures who shares very similar viewpoints on how education should be changed. The main problem with school is the fact that it hasn't evolved since its growth during the revolution. The level of importance on each subject is very skewed to catering to "creating professors" as Sir Robinson puts it. By this he means that we put Math and Sciences first, followed by everything else, with any type of art usually being at the bottom. Now, this might be all well and good for anyone who wants to go to what we know of right now as higher education (Math and Sciences being the main competitors while liberal arts colleges being the only schools who entertain the thought of an art major) but it isn't the best if we want to be able to start seeing problems from different angles. I'll talk more about general education in a later blog post, but for now lets talk about programming.

The main idea behind learning different paradigms like Object Oriented and Functional languages is for the expanding of our cognitive self, to be able to see the problem from different ways. This is also the same reason that we learn about different ways of solving the problem (recursive solutions vs iterative solutions). So with this reason well established I must ask, why do I feel like most of the people who try to go through a programming degree switch? Why do some students really struggle with the problems? I remember specifically when learning about linked lists and our teacher taught at a high level (concepts) and wanted you to figure out how to program it by yourself. The problem was that most of the students around me seemed to not understand how to code it. When I would sit the student down and try to get them to explain to me what a linked list is they could draw the diagram, and how to move though it, but they never made the connection that "currentNode = currentNode.next()" is the way that you can move to the next node. Why did so many students not seem to grasp the concept? I honestly don't have a concrete answer, but I can say that the students that didn't get it the first time seemed to grasp the concept a lot better when I used real world code examples and a visualization of what happened step by step. I feel like if we want to teach programming more we need to change the way we tackle the situation. And this doesn't mean just teaching the syntax either! I remember being in another class where we learned syntax for most of the class and then for the final I was asked questions about higher level concepts that (again) some students didn't seem to grasp. It seems that no matter how you teach there are just going to be students who don't understand parts of concepts. I know a full range of programmers, ones who know many different ways of solving the problem, but they couldn't program the simplest of solutions to a problem. Others who if given the method signatures could program everything, but couldn't come up with their own solution to the problem. How do we bridge the gab so we don't have this large whole in our talent.  

Bret Victor (former interface designer at Apple) says that the "new" ways of teaching programming by using tools like Codecademy and Khan Academy are doing everything wrong. In his interactive paper he explains that both the environment and the language should be able to allow the student to learn the way of thinking that is required of us to get our creative ideas into code. He emphasizes that Code and Khan Academy are just teaching the "rote skill" of programming, which as he puts it, "Learning about 'for' loops is not learning to program, any more than learning about pencils is learning to draw". The goals of a programming system should be, "to support and encourage powerful ways of thinking, as well as to enable programmers to see and understand the execution of their programs". His paper has started influencing developers to help create his vision of a new programming system that would allow students to easily pick up the theory of programming without getting lost in the syntax that teachers seem to want to push under the rug until a later time (I had to go look up what the main method in Java actually meant because of the lack of explanation in class to keep the smoke and mirrors afloat until after people learned syntax). For me and the other students who have both a strong skill-set in programming as well as problem solving seems to stem from the fact that we continue to learn outside the classroom. These are the students I would want working with me on any project. The ones who stay here late at night solving a programming problem because they want to and not because it is just the day before the homework is due. I want the ones who work on projects outside of class, who work on projects that are not their own, who help teach other students. Those are people who I think go to class to get the grade, but they are also the ones who if given the opportunity to make their own curriculum of what they want to learn would choose bigger and harder challenges. THAT is what we need to change our current students into. And the only way to do that, is to change the way we think about teaching. 

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.