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

Trautman’s 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 person’s 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

you’re 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

programmer’s 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 Trautman’s

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.

Trautman’s 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 programmer’s

first or first few low level working programs. Comparing myself to this, I realize that my

first program was much different than the average programmer’s. 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 mini-

games 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 wasn’t 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 didn’t 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 didn’t 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 didn’t 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 didn’t know very much about what I

was doing. The main issue was that the provided material was so basic it didn’t 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 haven’t 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 it’s previous level until after we finished our AI project. My confidence

returned to it’s 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

didn’t 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 didn’t 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 competitor’s 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 don’t 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 novelist’s 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/why-

learning-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