cloversnotes:

cloversnotes:

cloversnotes:

This is my first coding assignment for my software engineering class that started today. It’s going to be a really good semester.

UPDATE: I got my grade back and

“100″

Since this post has gotten some attention, I feel like it’s worth mentioning that this was just the first half of the assignment.

The second half, which we weren’t made aware of until the day we were meant to turn this one in, was to trade USB drives with the person sitting next to us and MODIFY their “unreadable” code without getting any help from them.

This was to teach us two things:

1) In this field, you’ll spend more time working with code written by other people than you will writing original code from a blank slate. The people who wrote the original code will probably not be around to help you. Learning to read code is IMPORTANT, even if it seems unreadable.

2) There is a strong brotherhood/sisterhood among programmers and software engineers. Respect that bond when you’re writing code and documentation. In my professor’s words: “When you write code, pretend that the person who will have to maintain it after you’re gone is a homicidal maniac who knows where you live.”

This class and professor are incredible.

As someone who had Big Thoughts about writing and now still writes constantly but not that kind of writing that was exciting back then, and is now pursuing a new kind of writing used to tell a computer what to do, Justin Wolfe’s recent thank you note on the subject strikes some chords:

i’m thankful for how it’s ultimately, at least for the kind of writing i do, it’s not about equations and algorithms (even if you’re using them), it’s about how do you write in such a way that your lines best represent your intended meaning for multiple audiences (both to the robotic interpreter “reading” your code now in order to run it and to the humans reading your code now and later and much later to try to understand it and borrow from it and build on it) and how do you do that with clarity and efficiency (though that’s complicated, since what’s efficient might not be readable and vice versa) and how do you bridge between your individual stylistic choices and the different choices your teammates might make (i’m thankful for the engineers who are like formalist poets creating elegant (but sometimes opaque) structures of abstraction and i’m thankful for the people who write in a slightly shaggier but more immediately readable free verse and i’m thankful that i can find virtues in both and can stretch myself in either direction) and how do you manage the fact that these little parts you’re working on (because a person can only hold so many lines in their mind at one time) are part of ever-scaling networks of other parts, a tower projecting into the sky—how do you name things and organize things in such a way that those formal choices communicate the most meaning now and will continue to do so into the future.