Professor,

How is this a violation of Academic Integrity?  I posted them after the initial due date, and very clearly state that these are not to be used in lieu of a student doing their own homework, nor are they likely reliable enough to be used in a corporate environment.

You may ask, then, what the point is - the point is that I'm starting to create a repository where my future employers can see code I've written easily, something that is more important for the interview process in our modern world than ever.  The work all semester was difficult enough that I felt it warranted being included.  Additionally, sharing code with the world at large, in the spirit of the Open Source community, is not incorrect when the code is your own - even if no-one ever looks at it.

According to the Academic Integrity Policy of SJSU [accessible here], I do not qualify for any of the terms of Cheating or Plagiarism.

According to the Student Conduct Code of SJSU [accessible here], I do not qualify for any of the terms of Section B.  Any arguments for Section B Item 14 are invalid, because they are not being disseminated for commercial purposes.

According to a statement by the SJSU Student Senate on April 20, 1990 [accessible here], "Academic institutions exist for the transmission of knowledge, the pursuit of truth, the intellectual growth of students, and the general wellbeing of society".  My actions are within the spirit of this.

Finally, according to the same Senate Resolution, students have a right to freedom of speech (which this is classified as), "So long as a student demonstration does not interfere with the classroom".  Having posted the code after the due date, I did not interfere with the classroom.

Thusly, I do not see a need to remove my code under threat of grade penalty.  If you disagree on any of these points, or wish to discuss it further, I will be more than happy to bring this discussion to Dr. Louden's attention.

• what were cited are examples, not a full list


• he had expected me to cooperate, otherwise he would have filed a Cheating claim against me


• take down his PDF files due to copyright (note: I did; they're being retooled for reposting as my own content)


• does everything need to be stated as acceptable or not?  spitting on the classroom floor was mentioned.


• future classes will expressly prohibit the public posting of code solutions at any time

Professor,

I understand that they are merely examples, but I thought it was important to point out what the spirit of Cheating and Plagiarism is, since this may very well result in a new definition set.

I will remove the problem descriptions.

I appreciate that you didn't file a case, because, as you said, it was not my intention to help others cheat or facilitate it.  In fact, I still don't believe this could be considered cheating, since it is a very different situation than passing a Final around the room.  Perhaps I could have posted the code at a later date than I did for each assignment, but the principle remains the same.

There is no reason to not make homework solutions public at an appropriate time, and what I have done is no different than sharing answers after they have been turned in for grading - or reviewing graded homeworks in groups before a Final Exam.  I merely used the Internet as my distribution method, instead of a paper-and-ink solution.

Finally, I believe spitting on the floor is completely unrelated.  That would fall under basic actions of human decency, whereas what I have done over the previous months is more intellectual in nature.

Thank you for the consideration of my response.

Hello Dr. Louden,

I have been contacted by Dr. Beeson today regarding the posting of my homework solutions for CS146, past due date, online as a reference for my future employers as well as the general public (if they were interested).  He seemed to think this was a violation of Academic Integrity, and considered it Cheating.  While we still disagree, he has agreed to not penalize me because he didn't explicitly state it was forbidden.

However, this is still a concern to me, as he has indicated this will be a tenet in all of his classes henceforth.

The code I have posted is code that I wrote, and posted past the due date.  As such, it cannot be considered cheating.  But for a Professor to prohibit post-grading distribution of solutions is ludicrous.  What I have done is, essentially, no different than students comparing answers after handing in homework, or comparing graded solutions of a semester's work prior to the Final Exam.  Neither of those are considered Cheating, or any manner of an Academic Integrity violation, so why should mine be considered different?

To prevent it would not only be destructive, prohibitive, and harmful, but potentially a violation of Freedom of Speech as well.

I have included the emails between myself and Dr. Beeson as an attachment.  I hope that you can review these details and make an appropriate decision as to whether the prevention of such sharing is both legal and intelligent.

Thank you for your time, and I hope to hear from you soon.

• the Office of Student Conduct and Ethical Development was contacted for a ruling


• Dr. Louden did not believe Dr. Beeson can unilaterally prohibit the public posting of code


• copyright issues could arise if the problem sets were highly unique or code from Dr. Beeson was used (note: not the case)


• Dr. Louden disagreed with the assertion that posting code online was the same as sharing homework solutions, because of the medium in which they were posted (note: the Internet)


• Dr. Louden stated he thought the claim of Freedom of Speech would be a stretch

"I have now heard from Debra Griffith, Judicial Affairs Officer of SJSU, and she agrees that what you have done does not in any way constitute a violation of the University Academic Integrity Policy, and that Dr. Beeson cannot claim otherwise."

In the world of computer programming, stress is well understood to be a factor of daily life for its practitioners. Generic computer users understand what it means to be frustrated with computers, and architecting the software itself is merely an extension of the same frustrations by an order of magnitude. However, despite the common knowledge of the high levels of stress for programmers and software engineers alike, the very corporate structures that employ them tend to plead ignorance, as if the problems would solve themselves – even if a majority of the stressors are corporate-inspired.

The most crucial point in understanding computer programming is that it requires a level of concentration, intelligence, and broad-base knowledge alien to most other professions – a deadly combination of engineering precision and abstract artistic creativity. The reasons are broad and many, not to mention technical in nature, but such activities are extremely demanding and “can strain the limits of human cognition, stress, and fatigue” (Galinksy et. al 1993). Architects of software come to expect this over their training and careers, many of which begin during the teenage years, and therefore internalize it as a job hazard, rather than an issue potentially worth addressing in a concrete manner.

The interactions between users and the software must be accounted for, requiring large volumes of study and analysis of humanity’s tendencies, and is not accomplished overnight. In these days of modernity, the act of programming has evolved significantly from the days of punch cards a half-century ago, but is still limited: every action, analysis, and reaction must be hand-written, lest a bug appear to only frustrate the end user. Development is typically done inside a special environment that facilitates software creation and debugging, but encourages a reactionary coding style: write, test, fix, and repeat until deemed functional. A growing movement is interested in what they have deemed “ahead-of-time” programming, which would “allow the programmer to offload as much of the memory burden and mental work as possible”, with the intended effect of “greater satisfaction and lower levels of stress and fatigue” (Snell). While it has proven helpful in limited studies, as well as achieving granular adoption in some development environments, this solution ignores what many consider to be the exacerbating stress factor: management.

In various studies of programmer stress, a common theme of high stress levels, causing various problems, appeared. Depending on the stage of the project, the symptoms varied: project planning saw high anxiety and depression, code writing saw irritability and low morale, and debugging/testing saw all possible manifestations. The problem, it seems, is one that most programmers could have easily articulated without the need for costly research. Management of programmers is not typically effective, and tends to cause unnecessary problems. Many believe this is because the management theories used are based on “techniques derived from the manufacturing industry” (Glass), and revolve around arbitrary value markers such as lines written per week, features implemented, or percentage of debugging completed. One such researcher, Fujigaki, states that “the software process is a learning and communication process”, implying that the employee-manager relationship should have a more fluid model, since software itself is very fluid in its creation.

Others may argue that programmers themselves are the cause, since they are a different brand of individuals, as previously mentioned, with character traits apparent across the board, regardless of employer, industry, gender, nationality, or even generation. If an average person were asked at random what the characteristics of a programmer were, they are likely get it right: a high need to achieve, to reach high levels of job satisfaction and personal accomplishment, with very little emphasis on socialization (Zawacki). With these traits in mind, it would appear that managing structures based on a need for social appreciation would be problematic, leaving some to suggest moving such individuals with a higher valuation of social life to leadership positions, as a middle-man between the personality clashes.

Regardless of the true source, the fact remains that stress for computer programmers tends to reach high levels that are often maintained for their entire careers. With minor deviations, such as modern Internet giant Google (“Top 10 Reasons to Work at Google”), most organizations ignore the stressful conditions under which their employees operate, refusing to help alleviate these problems even when they can, and do, easily escalate into larger situations. In the interviews with the two employees at CIENA – one a former programmer turned specialized support analyst (Mike), another a high-level programmer with customer-facing duties (Shawn) – they echoed similar sentiments regarding the dearth of stress management options, regardless of whether they believed such options would prove useful.

Both individuals expressed personal methods through which de-stressing was possible, such as exercise, but that the daily worklife did not allow for such luxuries – no massages, no guided meditation, and no yoga rooms. Despite not having corporate-sponsored stress management options, Shawn and Mike both expressed a love for what they are involved in, even going so far as to say that perhaps the stress factor was not novel and could be considered part of the job description.

As the world becomes exponentially more digital with each passing year, the need for the software industry to evolve becomes even greater. Whether the issue is employee management, development methodologies, or the job itself, computer programming will continue to become more difficult and stressful, and the projects ever larger, more complex and grand. If a middleground is not reached for those involved in the production and architecture of software, the consequences for the humanity’s technological future, and the world-at-large, could be momentous.

References

Fujigaki, Y. (1993, July). Stress analysis: A new perspective on peopleware. American Progress, 6(7), 33-38.

Galinsky, Traci L., Roger R. Rosa, Joel S. Warm, William N. Dember. (1993). Psychological determinants of stress in sustained attention. Human Factors, 35(4), 603-614.

Glass, Robert L. (1997, April). Practical programmer: The ups and downs of programmer stress. Communications of the ACM, 40(4), 17-19.

Google. (2009). Top 10 reasons to work at Google. Retrieved April 30, 2009, from http://www.google.com/intl/en/jobs/lifeatgoogle/toptenreasons.html

Snell, James L., Ph.D. (1997). Ahead-of-time debugging, or programming not in the dark. International Conference on Software Technology and Engineering Practice, July.

Zawacki, R. (1993, November). Motivating IT people in the 90s: An ‘alarming drop’ in job satisfaction. Software Practices, 3(6), 4-5.