Building Reputations Online

I’m currently a member of LinkedIn, a social networking service for professionals that targets executive-level professionals primarily but is open to anybody. I’m also (in passing) a member of OpenBC — a more internationally focused version of the LinkedIn concept. Between the two, my time is most definitely spent on LinkedIn, primarily because I have no real international connections. I’m also a member of Facebook and MySpace, though I don’t use either of those seriously either.

On the non-social networking side, I’m also a member of eBay. What do these five sites have in common? They all provide tools to network with other people (though eBay is really more about commercial transactions, it is still fundamentally networking). In addition, they also all provide a method to build an online reputation. eBay is the most obvious of these, since it provides its users with the ability to rate a transaction as positive, neutral, or negative – the more positive-rated transactions you have, the better off you are when you attempt to purchase or sell. The second most obvious one is LinkedIn, which, in a way, measures reputation by how many connections you maintain.

But is that really what LinkedIn connections mean? Not necessarily – in fact, in my case, that’s not really true at all. My strategy on LinkedIn is precisely this: connect with as many people as possible when I feel that having that connection would be beneficial to my work and future goals. Along the way, this has provided me with an opportunity to converse with several interesting people and to engage in conversations that were personally enriching. But none of this was based on my reputation – instead, it was based on my interest for their field of work and my desire to ask questions.

So what is an online reputation, really? I’m buidling one right now by typing this, and I will certainly be judged by my past posts, some of which are not always professional (this is a personal blog, after all). My tentative answer is this: your online reputation is definitely an extension of your real-world reputation, but only insofar as people know about your online work. I have a good reputation with a number of people offline who know nothing about my work online and cannot be influenced by it because of that, so the two are separate entities. This is certainly an open question, and one I’m considering as I utilize LinkedIn to grow a network.

Poetry Exercise of the Day

In case people are bored and want to do some writing, here’s the exercise I did during the Writing Center’s staff meeting this morning. Grab a literary journal (any one of sufficient length will suffice) and use the lines from random parts of that journal to create a new poem, called a cento. A cento is essentially a poem constructed using the words of other authors (our boss called it a “plagarized poem”, which is accurate enough, except that it’s cut from multiple authors). This is a very interesting exercise, and some of the other people that tried it came up with pretty good results. Another way to do sort of the same thing is to take a very old copy of a book, take a page out of that book, and randomly paint on the page so that some words are painted over and some aren’t. The words that aren’t construct a poem. It’s best not to read the page before you do this and just semi-randomly take out words. I suggest doing this with really old, run-down paperbacks – it reduces the shock of tearing pages out of books.

The Writing Center director is a poet, hence all the poetic exercises that she throws at us tutors from time to time!

Mr. Peabody’s Wayback Machine

It can be quite interesting to look at past work that you’ve done as a web designer, even when you don’t actually expect to run into that content.  I recently discovered the Internet Archive’s Wayback Machine (yeah, I know, where have I been all these years), which allows me to bring you the following nuggets of only partially-complete archive sites.  Some of this stuff does actually show more than just some broken links:

  • darkfusion.net
    This web site, which has had various incarnations in the past.  It started off as the domain for my web design company Dark Fusion Internet before I changed the name to naturalaxis.
  • naturalaxis.com
    I would be remiss not to link to my own company.
  • www.willworkfora.tv
    My really, really bad attempt at a SatireWire-like site – imitation being the best form of flattery.
  • www.insidelogic.net
    Way back when I was a teenager, I participated in a series of software companies, none of which were any good, but they did provide me some experience and a playground of sorts.  This was one of those sorts of projects.
  • students.overlake.org
    One of my bigger learning experiences in high school was creating and running a UNIX web server so that students could create web sites and host them on one of the school’s own servers.  The project died shortly after I graduated since nobody else there knew UNIX, but while it was up, people found it useful.
  • runicsys.tierranet.com
    Another one of those really old software company projects.  One of my first web page hosts that I had, but not the first.
  • runic.simplenet.com
    My first subdomain, hosted by what used to be Simple|Net (now Yahoo’s Web Hosting services).

My work has definitely evolved since I created some of these sites, but it’s still interesting to look back at the progression of the work.  The only exception to this was students.overlake.org, where not all the work was done by me (the later leaf logo was my work, and some other students did the main layout work for a couple of those incarnations).

The Importance of Copyediting

It may be interesting to see a headline for a $5 civil lawsuit, but upon closer inspection, it’s clear that this is actually a $5 million dollar lawsuit regarding the wrongful death of a prominent political leader. Normally, this would not be something I would bother to highlight on my blog, except for the fact that the topic really has nothing to do with what this triggered in my head: what does it mean when people are so quick to get things out the door that they fail to completely proof their documents?

There’s really two ways for me to approach this question: as a web site designer and as a writing tutor. Really, the answer here is much the same, but the perspectives on the issue are different.

Commentary from Both Roles: Being hurried in your writing is never a good thing, whether that’s for the web or for any other purpose (professional, academic, and so forth). Grammatical mistakes have cost people lots of time and money (and, in some cases, jobs), and factual mistakes can almost be far worse. In today’s world, though, it’s highly acceptable to shove out content before it’s anywhere near ready for public consumption. The New York Times used to (and still does occasionally) publish articles on their web site rife with grammatical errors and signs of bad copyediting.

This is a cultural phenomenon and a symptom of our high-paced society where, if we don’t get instant gratification, we’ll go elsewhere. The ones that win at the professional game of copyediting chess are those that are careful and don’t put information out there until it’s polished to a soft sheen.

Web Designer/Developer: This can be death to a web site depending upon whether it’s a major site (like our ongoing example of the New York Times) or a small one, such as the ones maintained by many of my past and current clients. There is, of course, a range of copyediting: the completely rough draft to the obviously polished, well-articulated statement. But carelessness when your web site shines in other places can really stick out like a sore thumb. Making sure that the text you put online is free of grammatical errors is to your benefit, since it not only strengthens your message, but also ensures that the reader keeps reading.

That said, please don’t forget to copyedit not only text, but images. I’ve seen many an image on the Web where it’s a beautiful piece of work, but its beauty is completely marred by one glaring grammatical error that should have been corrected before the image was completed.

Writing Tutor: I see a lot of students come in with grammatical errors (in fact, in my three years of working at the Writing Center, I’ve only ever had one paper come in the door that was literally perfect and needed absolutely no changes whatsoever). Since this is an academic environment, those grammatical errors don’t matter so much and don’t have as much of an impact on life. It is to the benefit of these students to understand how to properly use commas, dependent clauses, and modifiers, but it’s rarely as important that all the details be absolutely perfect before a paper is handed in. This is a very different approach to copyediting than in the professional world. This is a learning environment, so you are expected to learn something about how to properly write a paper, which includes grammar.

Yet, still, grammar is one of those things that literally nobody gets right 100% of the time. Especially in English, there are niggling, obscure grammatical rules that only apply a very small percentage of the time that can come back and bite you later (assuming that someone who actually knows that rule notices the error and points it out). That doesn’t mean you should throw up your hands and scream out to the Heavens for mercy on your poor, grammar-impaired soul; in all these situations, it merely means being cautious and observant about how a document is written. The example of the image I linked to above was an obvious, glaring error that could have been fixed if they had bothered to read their headlines before they hit the “Submit” button. Copyediting is as important as ever, and it’s important to remember this.

Ruminations on Separating Work and Work

It’s been a long, hectic quarter this time around – I’m not complaining when I say that, though I admit that there are some aspects of this class that make me wonder why I’m bothering with it. The bulk of my work is being focused upon our yearlong project, which, for me, consists of creating a new appointment system for the Writing Center.

Creating an application for a place that you yourself work is an interesting experience because it requires two hats. The first is the hat of the know-it-all business user: the one who knows how things are typically run, knows that certain procedures are executed in order A and not order B, that certain business rules are never enforced properly, that certain parts of our work are highly dependent upon the smooth operation of one part of the Center, and so on and so forth. The second is the hat of the non-expert applications developer: the one who questions every business rule and tests for its validity, the one that, when faced with a choice between efficiency and practicality, is forced to consult with the client to get their opinions properly registered, the one who needs to maintain some distance in order to keep an objective view of the work involved.

The whole “two hats” thing is both beneficial and a curse. It means that I can quickly answer business questions posed by my project partner (who is in no way connected to the Center and is the blissfully oblivious, inquisitive half of this team), but it also means that I always must be certain that the answers I give are framed in such a way that they are reflective of the operations of the Center rather than my opinion, whether that is an opinion of how the Center does or should operate. It means that clarifying logistics with our project sponsor is much easier because I work for her and can translate into her language, but it denies me the objectivity that my project partner has.

Frankly, it also means that I must be extremely careful not to let the wires cross, for fear that it will compromise my ability to effectively work in either environment; yet, for whatever reason, that has been unavoidable. Even if I’m not working on the system, I’m working on the system – in my head, I’m processing what goes on in terms of appointment scheduling and considering logistics. But here again, I must be careful: my visualization of what goes on and the snippets that I catch are not necessarily reflective of reality. I sit on the periphery of the appointment scheduling process that goes on daily because I am unable to participate in it – my hearing impairment bars me from effectively fulfilling a vital part of that duty.

So, in our process of peppering people with questions, convening focus groups, meeting weekly with both project sponsors and program faculty, I find myself now listless. It’s as if I have all the information in front of me, but because of the sheer concentration of the last several weeks, that information has transformed itself into a language I can no longer understand. I have not lost momentum; instead, I have lost my ability to sequentially address issues as they arise. It is not that I will simply stop. We are at the point where we cannot stop – we are close to a first-cut implementation of this program, and stopping now would mean severe delays further along.

How do you navigate with a foreign map in familiar territory? Intuition and memory. That’s what I must now rely on.

Seminar Summary of Classic ACM Papers: Part II

Here is another of my seminar summaries from Student Originated Software on one of the classic ACM papers we have been reading.

As with my last summary post, please don’t bother stealing this.  It’s immoral, unethical, and usually just plain rotten.  If you don’t understand the paper but you are required to turn a summary in, you need to read the paper carefully – this summary comes straight from the paper text, as with the summary posted in Part I.

PARNAS, ON THE CRITERIA TO BE USED IN DECOMPOSING SYSTEMS INTO MODULES

Parnas utilizes the example of a KWIC system to demonstrate how programs can be constructed by utilizing a series of different modules. By way of this example, he demonstrates how different modularizations yield different results in the level of information hiding available. He suggests criteria that might be used to properly construct these modules in order to ensure that modules may be developed independently of one another. He claims that the managerial and development time should be drastically reduced and that it should drastically increase the comprehensibility of the program for coders.

Parnas explicitly defines a module as a “responsibility assignment” rather than a subprogram, which may actually limit his argument. In larger programs, subprograms could in fact be fully modularized via responsibility assignments controlled by a master module called by the remainder of the program – the level of decomposition he discusses here can be more widely applied than is implied by the remainder of the paper. He creates two different modularizations for a KWIC index system: the first is based upon the stages the program steps through, the second is based upon discrete units of functionality. The first modularization utilizes five modules: input (reading in data), circular shift (finding the location of each circular shift), alphabetizing (alphabetizes the shifts), output (prints the shifts), and the master control module, which controls the operation of the program. This first module, Parnas argues, is the approach that would be used by most coders in creating a modularized system.

The second modularization utilizes six modules: line storage (responsible for the management of information regarding circular shifts), input (reads in from the input media), circular shifter (manages anything to do with shifts), alphabetizer (manages the alphabetical ordering of shifts), output (prints circular shifts), and master control (same function as the previous modularization). Parnas then begins to compare the benefits and drawbacks of each modularization. Both modularizations ease the ability to program each section individually, but only the second appropriately hides information so that the other modules do not need to rely on or replicate knowledge provided by other modules. After assembly, each module could be analytically identical, but the second module has more potential to be developed in an inefficient manner due to the information hiding available in this approach. Parnas also extensively discusses the changeability of each module and areas that could be modified and the impact that such changes may have on the programming of each module. Parnas is also concerned about the comprehensibility of code.

He proceeds to give an analysis of the impact of changing a particular portion of the design on both modules, isolating the circular shift algorithms. He gives examples of advisable decompositions for the system: creating data structures as a single module, pairing routines with their calling instructions is a single module, control structures are a single module, and information about the inputs are a single module.He also discusses the difference between hierarchical structures and modularization. He states that having a partial ordering of modules that allows different modules to use lower-level functionality and stand alone is beneficial; higher levels can be pruned to create a new program with the same base functionality.Thus, he concludes, a combination of modularization and hierarchical ordering can be greatly beneficial to a program.

In his conclusion, Parnas disdains directly correlating program modules with steps in a flowchart, instead urging the usage of a list of design decisions that could change and to press for information hiding whenever possible.

Agh, Technical Support!

I hate dealing with tech support people, over the phone or otherwise (though I have problems with the phone in general). At least part of this is because I am tech support, to a certain extent – my client work requires me to play that role (and, sort of offhand, so does my job in Evergreen’s Writing Center). So any example I can find that aptly illustrates just how stupid tech support people can be is just further proof to the whole situation.

Case in point. I’ve heard dumb stories from both the customer and the support technician’s perspective, but that one quite possibly takes the cake. My previous discussion regarding our experiences with Comcast not withstanding, this one’s pretty bad.

Seminar Summary of Classic ACM Papers: Part I

Student Originated Software, my yearlong software development program at Evergreen, requires us to write a weekly summary of the reading assignment for that week. I thought I might share some of these summaries, as well as links to the papers themselves.

I shouldn’t have to say this, but in this day and age, better safe than sorry – plagarism is a very bad thing. As a writing tutor, I condemn it, and if you steal my summary and pass it off as your own, then you are likely in violation of some sort of ethics code (more than likely academic, but possibly professional). Save yourself the trouble – don’t do it. If you need to steal a summary instead of reading the paper, perhaps you’re in the wrong place in life.

WIRTH, PROGRAM DEVELOPMENT BY STEPWISE REFINEMENT

Programming, according to Wirth, is too often taught in the abstract; rather than providing specific, concrete examples for students to follow and build on, students are crammed with abstract facts and information about a language, rather than focusing exclusively on methods of design and construction in the context of those languages. Thus, Wirth puts forth a problem by which to construct an ongoing example of how to design a program. The Eight Queens problem states that eight queens must be placed on an 8×8 chessboard in such a way that no one queen endangers the others. Wirth puts forth that the best way to develop a solution to this problem is, first, to develop an appropriately abstract notation in which to discuss the program’s development and evolution. He first posits an approach that is essentially “brute force”; try every possible combination until generating an acceptable result by examining every possibility in the problem domain. The issue with this solution is that it takes seven hours to come up with a single solution, much less multiple possible board layouts!

Wirth’s second solution is to generate two subset predicates from the overall result. Thus, the join of those two subsets yields the full domain of problem results. Through preselection, he reduces the problem to only a 100-second execution time. However, this second result isn’t beneficial either; rather than taking 2^32 tries to find solutions, this algorithm takes 2^24, an improvement of 0.003% – negligible! Wirth then proceeds with a third, far more elegant solution: treat each column on the board individually. As a queen is placed, she invalidates certain positions on the board: no queen may be placed on the same column, the same /-diagonal, or the same -diagonal. Since queens are being placed sequentially left to right on the board, you are only ever dealing with N queens in the Nth step. Therefore, place a single queen on the board; as that queen is placed, track in three arrays the diagonals and columns where other queens may no longer be placed according to a set of coordinates. If necessary, be able to backtrack from a particular solution so that all possible solutions within the problem domain are tested. Under this algorithm, the full solution set is found within 15 minutes.

Wirth then steps through the development of the code behind each of the possible solutions, showing how each step in generating the code is merely a refinement of the previous possible solution; he does so by developing a series of primitive operations and refining their definition step-by-step. By defining these instructions in the abstract and waiting until the last possible second to assert data representation, Wirth is able to create a solution that utilizes the same functionality in slightly different ways.

Wirth concludes that the best way for programs to be designed is through stepwise refinement which waits until the last possible step to determine data representation and to commit to a particular structure. This is the only way to do careful programming that yields a clean and efficient result.

Libby Arrives!

Libby has arrived in her new home as of about 4:30 or so today, completely knocked out by the anesthesia she was given. However, she didn’t actually have any surgery. Apparently, while the vet was prepping her to be spayed, they discovered a previous scar that suggested that she had been spayed previously. When we picked her up, she yowled rather plaintively when we put her in the car, but then went right back to sleep. She started waking up an hour or so after she got home, but she’s still somewhat numb – she’s not walking in a very coordinated way, and it’s obvious that she has yet to regain feeling in her tail, since it’s dragging on the ground. She’s already dragged it through her water dish twice without even noticing!

The vet did notify us that she needed an additional treatment for distemper in a couple weeks, and also that they had detected signs of tapeworm and had already treated her for it. She also needs to have some drugs to prevent ringworm, which need to be given in the next day or so, so Amanda and I will need to go to the grocery store and get some deworming medicine. We have scheduled her initial vet appointment with a Dr. Mitchell at the Westside Olympia Animal Hospital on Harrison – I may report back on that visit in a few weeks.

She’s a very gentle and currently somewhat timid cat. We have her downstairs in our combination guest bathroom and laundry room, and we’ve been alternating between leaving her alone and visiting her. She has discovered that she’s small enough to fit behind our washer and drier, and she crawls behind it, then peeks out at us from the little crack between the machines. The crack is big enough that it almost looks like she could fit through it, and she has tried, but alas, she must go around, then jump over herself to get back out! She was also very tolerant of my camera and our attention – hence the photo. I have yet to hear a peep out of her beyond her initial yowl in the car, but Amanda claims she’s meowed twice.

She’s going to be an indoor cat – many thanks to Sean to reinforcing my suspicion that confining her during the times we’re gone isn’t a bad idea. This is part of the initial introduction of a cat to a home anyway – give them a limited territory, then gradually allow them to expand that territory. That may not work too well in a place like this where most of the house has an open layout, but we’ll let her roam in a day or two after she’s adjusted to using her litter box and where her supplies are.

Meow.

At right is our newly adopted cat, Libby. She’s not home yet (she’s due to be spayed tomorrow and will be transported to the vet by Thurston County Animal Services, which is where she’s being adopted from), but we’re looking forward to it.

What we know: she’s a year and a half old, FELV negative, and up-to-date with routine shots. Past that, she’d have to tell us.

Perhaps we can teach her sign language…?