The Process
	I am a software engineer, so the majority of my writings will be code. Code is based on real language, but there are many, many differences between code and language to the point where code often needs to be explained using language. There are three key ways that programmers use language and writing to explain code. In order from the shortest to lengthiest, these methods are “Comments,” “Pseudocode,” and “Write-ups.”

	Comments are often used for one or few lines of code, and offer a short statement about the purpose of the code. To demonstrate this, here is an example from a program that I am currently working on:

		stats[1] = ((5 * (rand() % 6)) + 90); //Health: 90-120

	The blue part is the code, and the green part is the comment. The comment states “Health: 90-120” and means that “stats[1]” refers to health, and “((5 * (rand() % 6)) + 90);” picks a value from 90 to 120. This by no means explains the entire program, but instead is intended to be scattered throughout more confusing parts of code.

	The second type of writing that programmers use with code is “Pseudocode.” This usually explains a function and all the steps that happen inside of it. This writing is unique due to how it is usually written before the program is written, as it gives the programmer guidelines for what they can do. As an example of how pseudocode can be used, a function that generates statistics for health, strength, and defense may have pseudocode that looks like this:

	generateStats()
{
		Health (stats[1]) = random # from 80-100
		Strength (stats[2]) = random # from 8-11
		Defense (stats[3] = random # from 8-10
	}

	This pseudocode can then be used as a guideline for the programmer to later write the arithmetic and variable declaration that is needed to accomplish this. The pseudocode can also be kept even after the program is done so the programmer can be reminded of what the function does, and other programmers can learn what the function does.

	The third and most lengthy type of writing that programmers use is a full write-up. Write-ups are usually for entire programs, or at the very least, for large chunks of a program. They often go into the program in detail, going over nearly every line of code and explaining its function. Usually, write-ups are meant for people that know how to program. Because of this, the writer can use the readers’ knowledge to make the write-up as short as possible while still sufficiently explaining the code. My product is a write-up, but the audience is altered to someone who does not know how to program. This will result in a lengthier write-up than what would usually be written.

	The main goal of writing for programmers is to be able to explain something using as little words as possible sufficiently. Comments are rarely more than a sentence and are often just 2-5 word phrases. Pseudocode is usually one phrase per line and gives the most basic description that is sufficient for its given purpose. Write-ups focus heavily on not explaining what a reader should always know and try to explain code using as little words as possible. So, for my improvement, I need to focus on keeping my writings short while still giving a sufficient explanation of the code.

	Audience is also an essential factor to consider when making writings for a program. The examples that I used to demonstrate comments and pseudocode were from my own project that I am writing entirely for myself. I am aware that my audience is only myself, which is why “Health: 90-120” describes so little. If my audience for my program’s comments were to be someone that doesn’t know how the program writes, I would write “Sets the health to a random number from 90 to 120.” This is a quick and easy fix for comments and small sections of pseudocode, but larger writings such as entire write-ups can change drastically depending on who it is meant for, and adapting to the audience requires practice and proper planning.

	I chose to do a write-up for my project because I know that it is the area of programming-based writing that I am least experienced in. It is also the hardest form of writing that I will commonly do. In the future, I will be writing programs that have thousands upon thousands of lines of code, so it is best to get experience in write-ups by starting small. I chose “Tic-Tac-Toe,” a program I wrote that only consists of around 100 lines of code. There are not many functions in the program when compared to the larger projects that I will create in the future, so there is less that I need to explain. Additionally, what I will have to explain will be simpler because I wrote it in a way that it should be relatively easy to explain to an audience of someone who does not know how to program.