Ricky Sanders

Final Paper
11/23/2015
My Journey as a Programmer
Portfolio Link http://rickysanders2000.wix.com/rickysanders

I read an article from Viking Code School titled Why Learning to Code is So
Damn Hard - What every beginner absolutely needs to know about the journey ahead
(Trautman) that attempts to give some insight into how programmers tend to follow a
general pattern of confidence compared to their competence over the time of their
programming career. The goal of the article is to explain what to expect and what the
journey will be like to new potential programmers. I came across this article while
reading a number of others about how confidence can be just as important in a career
as competence due to my curiosity of how the human mind works and just how
influential your mindset is on your ability to do any number of tasks. This got me thinking
about how my own confidence influenced my abilities and pursuit of knowledge as well
as how my speed of progression compares to others. Programming seems to have
come naturally to me and I am curious to see how this compares to the norm. I plan to
compare myself to this study in an attempt to find out if I follow the same pattern as the average
programmer.

(Figure 1)
Before I can begin comparing myself to the study, I must first explain the study in
sufficient depth for all readers to be able to understand the relationship I am making
between my work and the study by Trautman. The above combination graph is from
Trautmans article and aims to express this relation of confidence to competence from
when someone begins to learn programming and when they are ready for a
programming job. This combination graph is composed of three different graphs that all
relate to each other in some way.

(Figure 2)
The first graph, Figure 2, is the main focus of the somewhat confusing
combination graph. It outlines the general journey from start to job-ready of the
programmer, with the other two graphs being related supporting factors for this one.
Figure 2 focuses on the correlation of a persons confidence to their coding
competence. As stated by Mr. Trautman: This is a relevant relationship because your
confidence is highly correlated with your happiness and because the point where your
confidence and capabilities match is the best proxy I have for the sweet spot when
youre officially job ready.
There are four stages identified in the combination graph that spans to all 3
individual graphs. First,The Hand Holding Honeymoon in Figure 2 is a very enjoyable
journey through completing your first or first few low level programs often with access to
a large amount of documentation, examples, or tutorials that leaves the programmer
feeling great about their accomplishments. This first program is usually written using an
easy programming language such as one that is based on drag and drop sections or by
using a step by step tutorial. The Cliff of Confusion is a major event in the
programmers quest for knowledge where they become painfully aware that they are not
as knowledgeable or capable at programming as they believed they were. This often
happens when they are presented with challenges such as not being able to find good
documentation, examples, or help on what they are attempting to do. The Desert of
Despair can have a number of different challenges such as never being able to find the
documentation you need, being stuck on the same problem for a long period of time,
trying a large number of solutions to a problem with none of them working, or even

being so stumped by an issue that you have no idea what to do or how to get help. The
one thing this desert almost always has, however, is self doubt that makes the
programmer consider leaving the profession or even others who vocalize the possibility
that programming may not be the proper profession to pursue. If the programmer is able
to navigate through this desert they will happen upon an Upswing of Awesome where
they solved their previous problems, are capable of debugging basic or intermediate
issues, and creating usable programs that others think are cool and useful, but the
programs are not production ready due to intermittent crashes caused by improperly
handled input or misunderstandings of some data structures.

(Figure 3)

Figure 3 is about resource density, which is magnified and labeled above. It is

important to note that the line segments in this graph are not individual sources, but
simply a visual representation of the amount of available data. If it helps, they can be
visualized as source types. Most anything is incredibly easy to do when there is ample
documentation on the subject and even easier if there are detailed tutorials or
instructions for everything. As you can see in this density graph, the programmer does
not hit the Desert of Despair until they run into a problem that has little documentation
and the documentation that does exist is long and often written for advanced users,
leaving the programmer more confused or frustrated than before they found the
resource. This resource scarcity usually happens for a person when they need to use a
very old, very new, or underused programming language and when a person runs into a
unique problem while attempting to do something that is not commonly attempted by
others such as trying to use one programming language within another or trying to get
two languages to communicate in some way.

(Figure 4)
Figure 4 is the scope of knowledge section. This graphs the breadth of new
topics in each stage. When someone begins learning about code there is only a need
for a narrow understanding of syntax and data structures to form low level working
programs. Just after learning the basics of syntax and data structures, creating a few
simple working programs, and learning how to debug these programs, things begin to
become complicated. There is a rapid broadening of the Scope of Knowledge
immediately after learning the basics and moving into making more complex programs
and understand the errors and bugs associated with these complex programs. At stage
three, The Desert of Despair, the Scope of Knowledge is at its peak; this is when the
programmer must know what tools, languages, and design pattern to use and how to
use them for each project they are working on. Every time the programmer researches

any of these, they find a number of items in the explanation that they do not understand,
requiring them to look for more explanations usually continuing into a large number of
page hopps just to understand the first thing they were researching. This is the area
where a programmer learns the most about their art, but also the where they begin to
falter in their resolve. It feels like you know very little and that you are not learning very
much, when you learn more in short periods of time than you earned previously. It
diminishes over time, narrowing out much faster after exiting the Desert of Despair and
narrowing quite extensively at the point where the programmer is job ready.
Figure 2 will be the main focus of this paper and is the graph I am referencing
unless otherwise stated. The other two graphs are mainly used to give context to the
different stages.As explained above, I am curious to see how I compare to Trautmans
study and if I am as job ready as I believe I am; to explore this, I will attempt to plot
some of my major projects on the graph to form a sort of timeline of my understanding
of programming and I will be explaining my level of confidence during the given projects.
Trautmans study on the subject provides ample information for me to work with and
measuring my competence at the time will be relatively easy, but the challenge will
come from attempting to consider my confidence at the time.
Trautman labels the first developmental stage as the Hand-Holding
Honeymoon. As previously explained, this stage is the completion of the programmers
first or first few low level working programs. Comparing myself to this, I realize that my
first program was much different than the average programmers. My first coding
experience came from modifying a video game called Warcraft III, a project that I
undertook during the sixth grade, roughly at age eleven. I took an existing custom mini

game and modified it, added some music, and distributed it. This was done using a
fairly simple system, but it was far more advanced compared to what most people start
out with. The game used a graphical user interface (GUI) programming system,
meaning most of the programming is done by selecting or dragging options and it
utilized a minimum amount of code. The real challenge in this came when I had to set
up triggers. These were added by selecting them from a list and then modifying the
variables within the trigger. These triggers could be as simple as moving a unit from one
location to another or as complicated as setting up a complex collision and camera
system to turn a top down game into a side scrolling platformer. Using all of these
triggers to make things work as intended could be a challenge at times.
Considering all of this, I can begin to conclude that I am not an average
programmer. I began with a much harder task than most people, which resulted in me
coming out with much more confidence as a programmer and at a very young age. This
project is hard to properly place on the timeline because of this. The author states the
Hand-Holding phase as a joy-filled romp through highly polished resources teaching
things that seem tricky but are totally do-able You will primarily learn basic syntax
and my first project was joy-filled and there were enough resources to help me figure
out what I needed for what I wanted to do, but they were not highly polished or plentiful.
The language was GUI based though and was mostly linear so it made making errors
difficult. Because the language itself was so hand-holding, I believe it can fit on the
graph at this point. Truthfully, most of my work on it was trial and error with little
knowledge of actual programming, but I had a general understanding about how a
program flows and interacts with other systems. I became very curious as to how far I

could push the limits of the game and began digging deeper, eventually finding a way to
bypass the GUI editor entirely and create with actual code for the game. This is where I
learned some information about programming, but I only got as far as making small
edits to existing code, not creating a full game with the code. I was able to do things
within the code that the editor does not allow, giving my mini games a more unique feel
to them. I was incredibly proud of this and it made me feel like I was a natural
programmer, almost like I was born to do it. I enjoyed my time working on these items,
but I had not yet considered a career in the field. I made a number of different minigames over time using this same system. I grew more confident with each one, but my
programming competence did not progress very much past what I initially learned.
I learned a small amount more as I played with different code systems, but I
never got too in-depth with anything until I hit high school. This next event also falls
between the Hand-Holding and Cliff of Confusion stages, but was one of the most
amazing and influential experiences of my life. At about age 14, during my freshman
year of highschool, I began another major project as a member of a FIRST Robotics
Competition (FRC) team. FRC is a robotics competition at the high school level where
students build 120 pound robots to compete in a number of different tasks that change
every year. I worked on a number of different systems while on the team, including the
robot programming. We had a programming mentor that did the programming for us, but
he had to leave after that first year of working with us so someone had to figure out how
to program the next robot and I was the only one willing to do this.
This system was called LabVIew and was GUI based like the one I spoke about
in my last project, but much more complex. It took many attempts and a lot of reading,

but I managed to get whatever we needed working. I had trouble setting up the
extremely advanced systems such as autonomous movement, but I was never able to
get autonomous target tracking to work due to the complexity of visual tracking with a
camera. This was a huge milestone for me because I did more than just play around
with something, I managed to program a massive robot that weighed more than I did
and it worked like it was supposed to. I was amazed at my capabilities. This system was
GUI based, but this was an industrial grade GUI system that was in use on high level
systems so it took significantly more understanding than the last project I worked on.
After four years of FRC I understood loops, comparisons, and code progression. These
are general things that every programmer must know, but it made me incredibly
confident in my skills.
I learned all of this on my own during those four years and it gave me a lot of
confidence in my ability to program and to learn new things. During my last year I had to
teach others how to do this before I left. I made them write their own programs while I
watched to be sure things were done properly and they knew how the system worked. It
feels good to be teaching people how to do stuff at a young age and makes you feel
incredibly confident in your abilities and makes you feel older. At this point, I felt
unstoppable as a programmer, like I could learn anything and everything if the
challenge was great enough. I wasnt just confident, I was cocky.
The next major point in my journey as a programmer was also in the gap
between the hand-holding and cliff of confusion stages, my first official programming
class which came during my first year of college. This class was Intro to Computer
Science in C++, which is what you would normally think of when thinking of

programming. The C++ language is entirely code, so there was no hand holding GUI
system like the last two, but there was an instructor and a number of simple tutorials I
could have used if needed. I didnt know my level of competence was so low, but it sure
felt like it was four or five times that of most of the other students. Most of this was due
to the cockyness from the previous project. I felt so successful from that project, that I
felt and hoped that this class would be informative, but easy for me to follow. The first
few classes made me even more confident because it was on material I had a general
grasp of and it was going relatively slow. I got too bored to to follow the lecture due to
the slow progression and used the class time to learn things myself. I passed this class
without any issues and had no trouble with any of the assignments. I went as far as to
learn things beyond the scope of the class and play with programming in my free time. I
was relatively disappointed with the speed of the class progression as they would spend
weeks on material that took me a single day to understand to a point where I was able
to use the material. This speedy progression in knowledge set me apart from most of
my classmates and shows that, according to the reference article, I am not an average
programmer. My progression in competence was faster, thus having a longer build up to
the cliff of confusion. The C++ class did increase my confidence a good amount when I
found that I understood things much faster than others and that I knew most of the
information. My competence was pretty high for a freshman college student, but I would
come to know that my knowledge at the time was not even a fraction of what it would
come to be.
The following semester I took the next programming course: Intro to Computer
Science II, which covered JAVA. This was important because the JAVA language is one

I had not interacted with and was structured differently than the languages I had worked
with previously. I was also dissatisfied with the speed of progression in this class
because the first few weeks were a review of the previous class. By the time the class
finished reviewing things from only a few months ago I had already covered over half of
the course material on my own. I was given the option to do work online rather than
continue attending the lectures, which allowed me to progress quickly through my
studies on the language without the distraction of others around me. I progressed so
quickly that I was ready for the final before the second test was given. I was happy with
my ability to learn a new language so quickly, but I realized that courses often
progressed too slow for me and decided that I would benefit from online classes more
as they would allow me to finish my work as fast as I want, giving me time to sustain a
job. I had still not hit the Cliff of confusion and, at the time, I would have thought I
never would.
I had not yet noticed, but my success and speed of learning was due to the
extensive amount of documentation and tutorials available for the languages I had been
using. These were all relatively popular languages and most of my questions were
easily answered by a simple search or two. There were times where I never had to
change resources to be able to learn everything I needed for a project even though
there were thousands of other resources I could use. Looking at Figure 3, you can see
that there are a large number of line segments in this section showing a high resource
density, so it corresponds to my own experiences. This is important to consider and
understand because programmers often depend on resources written by more
advanced programmers to help solve problems. Attempting to keep the most up to date

literature and reading through each of them to attempt to solve a problem is expensive
and time consuming, so we depend on the coding community to remedy this problem.
The next semester I decided to get a job to allow myself to get more of the things
I wanted. I got a teaching assistant (TA) job at the university starting out as a C++ lab
instructor. I am placing this experience here on the timeline because it is when I first
became a TA. Over the years I moved around to keep things from getting boring,
working with teaching algorithms, data structures, and even an ethics class about the
impact of technology on society. I had always loved passing knowledge to other people
and I felt like teaching or assisting would be a great way to do it. During the time I
worked with the C++ course I ran a two hour lab session twice a week where I taught a
number of things that were not covered in the classes or reviewed subjects that the
majority of the students didnt understand. I realized just how good I was at this when
my office space began to overflow with students from other labs during my office hour
times. This is about the time I began to consider becoming an instructor myself. My
experiences as a TA did not increase my competence very much, but it did increase my
confidence a large amount. You feel much more confident about your abilities when
others trust you to teach them what they need to succeed. Because this was more of
just a confidence builder, it still happens before the Cliff of Confusion section on the
graph (Figure 2). The interesting thing about this experience is that even though it must
fall before the Cliff of Confusion, I had enough competence to teach others. This
seems to exceed the competence point on the graph (Figure 2) of where this would be
placed, but not the confidence point.

The next major point in my programming career was when I decided to take an
advanced programming course called Symbolic Programming. This course was about
learning how to program Artificial Intelligence (AI) using the languages Prolog and LISP,
two languages I had never used or heard of before. The main focus of the class was a
few tutorials and then a main project that would be completed by groups where each
group was required to create a complete artificial intelligence of some sort using either
LISP or Prolog. My group chose a Connect Four game as the final project where the
player would play against a computer AI at different difficulties. The finished project was
not only a good display of my programming skills, but a great display of my ability to
adapt and learn a new language. Truthfully, I didnt think this would turn into such a
project for me. By the time I took this class I had already learned four languages and
worked with seven languages in total so I expected this class to be just as easy for me,
but Prolog and LISP are relatively old languages and are not similar to any of the
languages I had previously worked with. As time went on with the class, I began to
encounter more and more instances of not knowing what to do. Older languages are
typically much harder to grasp, more ambiguous, and require a special way of thinking
to solve problems due to their lack of data structures or their incredibly odd way of
implementing the data structures that they do have. I took a few hits to my confidence
previously, but this was the only time where I felt I didnt know very much about what I
was doing. The main issue was that the provided material was so basic it didnt help
with any of the assignments or the project and the provided IDE often had a number of
issues including crashes. This meant I had to learn things myself again, but the
languages were relatively confusing and the little bit of documentation I could find on

these old languages were not very clear or too complex for me to comprehend. I hit my
cliff of confusing about a fourth of the way through this course and the entire last half of
the course was my desert of despair.
After hitting that cliff I fell pretty hard in confidence and I took to the internet to
learn more about the languages I was using, other important languages that were once
mainstream, and all of the languages I had already worked with. I wanted to know if I
could do upper level programming or if I was just wasting my time in a field I could not
fully grasp. I began to realize how little I knew about programming, but also how much I
had already learned. There are over 600 noteworthy languages and over a thousand
known languages for programming. This basically means I havent worked with a
fraction of those in existence and never will. No one could ever master every
programming language in their lifetime, but mastering a few is all that is needed to
perform a job well. My confidence jumped back up a little bit after this research, but did
not return to its previous level until after we finished our AI project. My confidence
returned to its previous level because I found that we were one of two teams to produce
a working product, which meant that everyone else had just as many problems learning
the languages as I did.
This is where I differ greatly from the graph (Figure 2) I am comparing myself to. I
did have a cliff of confusion and a desert of despair, but it was not nearly as rounded or
as long as the one shown. My cliff and desert were the same project, the desert was
much smaller, and these were sharp changes, not gradual. I hit the ground hard from
my cliff, but I moved through the desert quickly. I think this fast progression was caused

partly by deadlines for the project, but the main motivation for me to progress was that I
didnt want to be that person on the team that contributes nothing to the project.
Now that my Cliff of Confusion and Desert of Despair were over I flew into the
Upswing of Awesome. This upswing came upon me during the start of my next
semester of school. I took a number of required general courses and learned a few
more languages so my programming competence continued to steadily increase, but
none of what was going on at school for that year had a big influence on me. The real
highlight during that time was a project I began to work on outside of school, an open
source mod for the video game DayZ Epoch called Epoch Admin Tools (EAT). This is
an anti-hack and administration mod for the game that allows server owners and their
server administrators or moderators to run server events, fix glitches and errors, enforce
server rules, and prevent cheaters from causing problems. This project started when I
needed administration powers for my personal server and the only one I could find cost
$40, which was four times the cost of the game. I found a free and open source one that
was abandoned with only a few functioning parts so I worked to debug it and get it
working properly for my server. This was the first time I had programmed in the
language used by the game (SQF), but I was so good with it that I began adding new
items. After I got the mod working well and added some new things to it, I decided to
share my changes with others. I kept the project free and open source and developed it
to be even better than the one you had to pay for. I have been working on this project
for over a year now and I have learned a great deal about how the programming
language for the game works and have been able to do some really interesting things
that most people didnt know was possible. It is important to know how this project

progressed because as I continued to work on the project and more people began to
use it, it drove me to improve the project more, which helped to build my confidence and
competence over time. I was driven to improve the project by my ever growing fans and
I learned some very interesting things, such as being able to adapt one programming
language to work within another using a dynamic link library.
This project progressed quickly due to a very well documented API and a great
community of people who were willing to help. I think the EAT project was so influential
on me because it was a project that became a hobby and eventually evolved into a
community project. EAT is now used on over three thousand ARMA 2 servers and two
thousand ARMA 3 servers in over 20 different countries. It has become so popular that
people have translated the install guide into a number of other languages including
Chinese, German, and French. It got to the point where people were asking if I could set
up a way for them to donate money to me to compensate me for my time. I have even
had some people donate the $40 that they would have spent on the competitors mod
since mine was not only free, but offered constant support for potential issues. This
project accounts for most of my upswing of awesomeness because of how popular it
was with the community and just how good it made me feel. Nothing makes you feel
more confident in your abilities in a given subject than when large numbers of people
use and prefer your work over others and constantly offer compliments and gratitude to
you.
I felt job ready after months of working on the Epoch Admin Tools, but I was sure
I was ready for a full time job after completing my computer science senior project
course where me and a team of people created a study aid website called x Note Plus.

The project team originally consisted of five people and the project was to be a
semester long one. The team pitched a few ideas and we settled on the idea for the
study aid site which would use SQL, HTML, PHP, and CSS languages; we knew this
would be a challenge as only one of the team members knew these languages with the
exception of SQL. We decided that the rest of us would begin learning the languages
while the one who knew them would begin the project. The complications that followed
this point and how we overcame them is what gave me enough confidence in my
abilities to know that I was job ready.
The first big issue we faced was that the only member who knew the languages
for the project left a few weeks into the project without any notice and left us nothing
that was usable so we had to start over. Two of us began working on the project while
the other two finished learning the languages, which was hard for us as these were new
languages. We decided that one of us would work on the base code and I would go
through and correct any errors and get things looking nice. Mid-way in the two of us
began working on implementing the bootstrap framework while the other two would
begin work on some new pages for the site. After we finished implementing the new
framework, we found that the other two had not actually learned the languages to a
point where they could use them properly. The two of us who knew the languages to
some extent had planned our schedules around distributing the work four ways evenly
so we had to rush everything for our other classes to make sure all of our work would
get done. We decided it would be best to move the other two to the paperwork that was
required and have them give input rather than actually working on the code because
cleaning up and explaining the code to them was taking longer than it would for the two

of us to make it ourselves. This was very straining on us both, but I began to realize just
how well I could work under pressure. I had just learned 3 new languages and began
using them in less than a month to create a project that would have to be functional for
me to earn my degree. We ran into a number of other issues along the way, but the real
point here is that me and one other person managed to complete a five person project
in the same time as all of the other teams in our class did.
We were surprised at the outcome of the work as it did not seem like it was
created by people who had never used the language before. When I look back at how
things went, the code followed a general progression that is common for programmers
that I had never really given much thought to. A famous quote by Donald Knuth about
programming states that premature optimization is the root of all evil, which is
something none of us thought about during the project, but we followed it
subconsciously. This quote basically means that optimizing code before it is finished is
a waste of time and effort. There are a number of reasons for this such as code will
constantly be revised or even deleted, so if you spent time optimizing code that was
eventually removed, it would have been a complete waste of time and if it is revised, it
will need to be re-optimized. During our project, we started with a pretty rough draft of
the site which looked blocky and could not resize to the browser window or even work
on a mobile device. Midway through the project we had all of the ground work finished
so we figured it would be best to begin optimizing just enough to get the general visuals
we want and get rid of all of our bad code which was there due to our lack of knowledge
on the languages when we began the project.

Implementing the framework was hard work, but would never have been a waste
of time as we knew we wanted the Bootstrap framework and it applied to the entire site
so it would not be a waste unless we deleted the site itself. The most interesting thing
about this is that I did most of the framework implementation and I am only now
realizing just how efficiently I did it. I began with the home page to be able to show
everyone how the site would look after full implementation, later moving to other
important pages that were mostly finished and only needed a few tweaks. The last
pages converted to the new framework were not converted until their main function was
working reliably. This is very interesting to me as I dont usually think about how I
actually do my work; I just get it done and move on.
Looking back at all of this, the senior project most of all, I realize that I follow all
the general coding rules that people talk about without even knowing them or thinking
about them. I have a very methodical and logical way of doing my work where I form an
idea of what needs to be done, draft it out to see if it works, then improve the efficiency
and look of everything. This is what every programmer is supposed to do, but I had
been doing it before I was ever told to. All of the programming work I had gotten done in
all of the projects I have talked about has increased my confidence to some extent and I
felt job ready after completing that senior project because I knew I was capable of doing
just about anything I had to because I had the drive to succeed and the ability to learn
what I need to know in a short period of time. I knew I was gifted at programming, but
looking at everything put into a timeline like this, I begin to realize that I am not just
gifted at programming; I have an affinity for it. My general thought process is much like
a well structured program and for whatever reason, I find programming relaxing and

very enjoyable. My code flows out of me much like a novelists words do and is handled
in the same general way. The product is planned, written, reviewed and revised a
number of times for efficiency and correctness, and then published.

One thing I have noticed during my general programming classes is that I learn
much faster and easier than most of the other students which makes me feel like I am
not an average programmer; when considering the Figure 2 and the one I have mapped
out using the projects I have talked about in this paper, I can see that I did go through
the same general stages as others, but only loosely. As I have stated before with my
earliest programming endeavors I began by jumping right into the work and skipping
any tutorials, text books, or classes. I think this was possible because I always learned

very quickly and loved learning new things, but I still started differently than the article
had stated in the first phases. I might not have followed the phases closely in terms of
knowledge and ability, but I did follow it in terms of confidence levels as I definitely had
a cliff of confusion and desert of despair which were the only points where I actually
considered my confidence levels at the time of the event. I feel like my cliff was a much
steeper fall than the article talks about and my desert was much shorter than stated in
the article as well, but in terms of confidence I believe they are quite accurate except for
these small differences.
Before this project began I knew I was not an average programmer in how
quickly I progressed and learned, but like many others I never considered the larger
picture of how everything flowed together and just how it compared to others. One
interesting thing I think is missing from the study is a bit in the future for me. Looking to
the future I can see another large confidence hit coming on at my first job. I know I am a
good programmer, but when programming for a large project that contains code from
hundreds of others you can begin to feel less intelligent when you encounter code that
may be foreign to you. Considering that I hope to have my first job with Google, a place
that employs some of the greatest programmers around, I can expect to see code that I
will not understand and might have even thought impossible before. This study only
follows programmers from the start of their journey to the point where they are job
ready, which is where I am now, but it would be very interesting to see it continue on
until the end of the first year of the first job.
Looking back at everything I have always enjoyed learning new things so a field
like computer science that has more information than anyone could learn in multiple

lifetimes is perfect for me and I am pretty happy with my choices so far. Considering all
of the projects I have worked on and some of the amazing things I have been able to
produce really makes me wonder just what I will be a part of in the future. I would love
to work on some of the space exploration crafts or even some of the neural interfaces
for biomechanical prosthetics. Who knows, I could even be one of the people who
creates the first self aware artificial intelligence. The future is going to be a wonderful
crazy mess of technology and I will be right in the middle of it. My discussion of my
journey as a programmer has ended, but the journey itself will continue for many more
years.

Bibliography

FIRST Robotics. (n.d.). FIRST Robotics Competition. Retrieved from

http://www.usfirst.org/roboticsprograms/frc

Trautman, E. (2015, 2 4). Why Learning to Code Is So Damn Hard - What every
beginner absolutely needs to know about the journey ahead. Retrieved 2 14,
2015, from vikingcodeschool: http://www.vikingcodeschool.com/posts/whylearning-to-code-is-so-damn-hard

Sanders, R. (n.d.). Epoch Admin Tools. Retrieved from

https://github.com/noxsicarius/Epoch-Admin-Tools

Sanders, R. (n.d.). LISP Connect 4 AI. Retrieved from

https://github.com/noxsicarius/Connect4-Lisp

Sanders, R. (n.d.). X Note Plus. Retrieved from

https://github.com/noxsicarius/4155-Class-Project