Wednesday, 20 May 2015
10:58 PM
I forget how I found this, but a couple of days ago I ended up on a blog dedicated to writing fiction. Name? The Fictorians. That's a nice play on Victorian, and it's a clever use of the combining form -(t)arian (or a version of that), which Merriam-Webster defines as "believer" or "advocate" (vegetarian) or "producer" (disciplinarian).
And earlier this week I was at a conference for technical writers, where I discovered that we seem now to be calling ourselves by a new name: documentarians. Here's a slide that was presented at the conference.
I asked around about this term, because it was new to me. People noted that it was a known term for someone who creates documentary films. It seems that this new sense— documentation + -(t)arian in its "producer" sense—arose about a year ago, perhaps at last year's edition of the very conference that I was attending. Or so I interpret a thread on a tech-writing list.
One of the people I asked was Ben Zimmer, word guru. He wondered whether documentarian had been inspired by the cluster of words that was spun off from vegatarian: pescetarian (fish), fruitarian, nutatarian, flexitarian, etc. A quick peek into the Corpus of Contemporary American English (COCA) for *tarian also got me pastatarian, pollotarian (chicken), and pizzatarian.
These would fall under the "believer/advocate" use of the –arian particle, I suppose. Even so, new terms like this might be helping the –(t)arian particle become a more widely used cranberry morpheme or libfix (as Arnold Zwicky might call it), and helping along new and imaginative uses for it.
Update (May 24, 2015): Nancy Friedman noted to me today that the A.Word.A.Day site listed futilitarian as its word for May 7—"Devoted to futile pursuits" or "Holding the belief that human striving is useless."
[categories]
language, work
|
link
|
Wednesday, 23 July 2014
12:04 PM
I share an office with a fellow writer—let's call him Colleague B. We work on the same team, and thus we do joint planning and work and reporting. For example, every Monday afternoon we have a look at the upcoming week and plan our work. And on Fridays, we put together a joint status report that rolls up all the things we actually worked on.
The nature of our work, however, adds a certain chaos factor to our planning. On Mondays, we can certainly attempt to plan out what we need to do for the week. But every day—literally every day, and sometimes more than once a day—something new pops up. People send us email requesting a review of some documentation, or a developer will stick his head in the office and want input on some UI, or a bug will come in from a customer, or ... well, the possibilities are wide and varied, but there's always something.
Now, Colleague B is, by his free admission, a bit OCD. He is consistent and orderly both about our planning and our reporting, and he has that thing where he intuitively understands the delta between today and some upcoming date. Me, I'm a bit more on the other side, and my sense of time and dates is referred to around our household as "magical thinking."
 Colleague B is not a big fan of the daily dose of chaos. Here we've planned out our week on Monday, and people keep coming in and asking for stuff. As he says, in his ideal world, people who have something for us would get in line, and we'll get to them when we're done with what we're working on.
 On the other hand, I don't mind nearly as much the drop-what-you're-doing interruptions. I'm apparently happy to put aside the thing I'm working on in order to work on this new thing, or at least, till some other yet newer request comes in.
The world of computers has an analog for us: Colleague B is FIFO: first in, first out. Take a number, and we'll service you in order. In computing terms, FIFO describes a queue. Me, I'm LIFO: last in, first out. Like stacking trays in a cafeteria—the last on the stack is the first one off, and indeed, in computing terms, LIFO describes a stack.
Happily, it turns out that this combination of work styles works out well. Colleague B works his way through our Monday list, odds are good that by Friday, items can be checked off. But at the same time, we've handled a half dozen or so new jobs that came up during the week, things we had no idea about on Monday. In fact, Colleague B says that occasionally he'll finish up something and go read email, and by the time he's become aware of some new request, I've already handled it.
Of course, there's a certain amount of literary license here. It's not as if Colleague B won't handle ad-hoc queries with alacrity, and it's not as if I'm unable to handle anything other than whatever the most recent emergency is. Still, programmers know that sometimes the right data structure is a queue and sometimes it's a stack. As long as there are two of us, and as long as we divvy up the work correctly, we can handle pretty much all of it.
[categories]
personal, work
|
link
|
Saturday, 5 January 2013
12:34 PM
I spent over 17 years at Microsoft, and for most of that time, the company went to extraordinary and expensive lengths to try to give every full-time employee his or her own private office space.[1] The company kept building new buildings, and every office move — and there were many — involved a substantial effort to sort out seating arrangements so that people could both have their own offices and had some reasonable proximity to their colleagues.
The company's focus on office space presumably was based on an implicit acceptance of the idea that people engaged in concerted intellectual work need to be able to work in peace. In the widely read Peopleware, a book from the mid-1980s about managing software projects, authors Tom DeMarco and Timothy Lister addressed the need for this type of space: Before drawing the plans for its new Santa Teresa facility, IBM violated all industry standards by carefully studying the work habits of those who would occupy the space. [...] Researchers observed the work processes in action in current workspaces and in mock-ups of proposed workspaces. They watched programmers, engineers, quality control workers, and managers go about their normal activities. From their studies, they concluded that a minimum accommodation for the mix of people slated to occupy the new space would be the following:- 100 square feet of dedicated space per worker
- 30 square feet of work surface per person
- Noise protection in the form of enclosed offices or six-foot high partitions (they ended up with about half of all professional personnel in enclosed one- and two-person offices)
 For a few decades, it seemed that Microsoft was taking this advice to heart. About 5 or so years ago, however, it became evident that the company had changed its mind about space requirements. As buildings were added or remodeled, new layouts were introduced that emphasized open spaces and that featured areas (nicknamed "fishbowls" and the like) that seemed intended to foster interaction: a physical manifestation of the "collaborative workspace." Some years ago, all the technical writers and editors for a major division were moved to a new building and were presented with their new space, which was a cubicle farm (with 4-foot walls) inside an enormous, high-ceilinged open space. Old-timers were horrified.
I moved to Amazon in 2012. The space I'm in is a somewhat curious hybrid of semi-private offices (2 people per) and clusters of cubicles. Aside from obvious seniority/hierarchy, I can't tell exactly how the space is doled out; even as a new employee, I have half of an office. Developers who've been there longer than I have sit across the aisle from me in cubicles. There are open spaces that contain tables and chairs, and I very frequently see one developer or other sitting on a beanbag chair among the cubicles, tapping away on a laptop.
Certainly the space arrangements do encourage the kind of collaborative work that open-space proponents believe in. There's a constant hum of conversation, stand-up meetings, people popping into one another's offices, and so on. Every single person has a laptop, and people carry them everywhere. No one on my team is more than a short walk from my desk, so it's almost as easy to just buttonhole them as it might be to compose an email with a query. And there's absolutely no doubt that the mingling that occurs in offices and hallways and common areas fosters communication; hardly a day passes when I don't have a useful conversation with someone who I just happened to have run into in passing.
This has made me ponder the question of private space versus collaborative space. Were the studies that IBM did incorrect about the need for private space? That doesn't seem likely. Yet all around me I saw people working all day, and clearly getting things done, in an environment that would have made the space designers for the the Santa Teresa facility throw up their hands.
What's different now? Well, here's some speculation.
One obvious difference is that many of the people occupying the cubicles are young, by which I mean considerably younger than I am. (It is one of those milestones of a long career that I now routinely work with people who are about the same age as my children.) To be clear, the average age of software developers has probably not changed significantly in the last 30 years, and I would absolutely not claim that there's something evolutionarily different about youngsters today that somehow makes their brains different or anything like that. I would suggest only that many folks who are developers today did not come up in a corporate environment of private offices, hence are used to working in an open-space plan; it might be the only type of office space they've ever been in.
 Another difference is that people today might be more used to creating what we might term "psychic privacy" (as opposed to physical privacy). One thing you do see a lot as you pass cubicles is people wearing headphones, often noise-cancelling models. I can see this as a privacy measure in two ways. One is that it creates an exclusionary environment for the person wearing the headphones, who can tune out the otherwise very close ambient noise. Two is that I for one am less inclined to lean over a cubicle wall and make an inane remark to someone wearing headphones, which is to say, headphones become a signal that someone is in fact trying to work — a kind of metaphorical closed door.[2]
And finally, I think that in some ways things haven't really changed. I was chatting to one of the beanbag-chair-sitting developers not long ago (a serendipitous meeting in the kitchen) and asked him about his ability to sit in the midst of bustling activity and get things done. His answer was instructive: when he has to get real work done, he said — by which he meant serious, heads-down coding — he stays late and works after other folks have gone.
This last, I think, is probably an answer for how to reconcile the IBM findings with the current fashion in open-space design. People do get benefits from open space in terms of collaboration, and then can carve out small niches of privacy in order to encourage flow-type experiences. But they also still hide themselves away when they need physical privacy in order to perform concentrated work. This is made easier also by the portability of laptops, which let people find an environment they prefer and to work there. Many people do work at home, where they presumably have spaces that they've structured for personal productivity, and of course let them work during the hours when they're most productive.
I suppose the conclusion is that if you're IBM in 1982 and you're going to chain developers to a desk so they can work at their non-portable terminals, you'd better give them some private space in which to do that. If they need to collaborate, give them a meeting room. The current environment seems to have essentially turned this on its head: put people together so they can work together, and if they need to, they can slink off and find some private space in which to work on their own.
Even tho I'm old-school, generationally speaking, I don't mind this new environment. Since the beginning of my career I've split my work between collaborative and secluded, with the secluded portion usually done at home late at night. It's certainly become a lot easier to make work portable in the last 30 years. That other people might not find the new space arrangements as conducive as they'd like, however, I can easily see.
More reading:
[categories]
work, general
|
link
|
Wednesday, 3 October 2012
06:39 AM
I'm working in a new job, and I was surprised not long ago to get an email from one of our senior developers that read something like this:[1]
To: [whole group]
From: [senior developer]
Subject: I love kittens because they're fluffy
This would be one of yer more wtf new-job moments. A few minutes later we got this:
To: [whole group]
From: [senior developer]
Subject: re: I love kittens because they're fluffy
I stepped out of my office for 30 seconds and I was in the office next door!
 There was a reasonable explanation for all this, as it turned out, which involved security. Every company has security policies for computer use, of course, and larger companies might have dedicated IT folks who enforce such policies. One way they might enforce policies is to perform security audits of people's workspaces. For example, has someone written their password on a yellow note and stuck it on their monitor? Fail.
Another policy that the security folks might audit is the practice of locking your workstation when you step away from your desk. Obviously, if you walk away from an unlocked machine, anyone can jump on your computer and start hunting around for sensitive information.
Even a vigilant security audit team, however, can't watch everyone every minute. But I happen to work with a bunch of security-minded developers, so a protocol emerged that if they could catch you with your workstation unlocked, you were fair game to have a fluffy-kitten email sent from your computer. Our senior developer guy, in spite of his protestations, had been caught sneakily when he stepped out for the quickest of conversations.
I got filled in on this by another guy in the group (in fact, the guy who'd gotten the drop on the kitty-loving developer). He explained that the group—as I say, a security-minded bunch—had started it as a kind of game in order to help enforce security policy. The remarkable thing, he noted, was that once the kitty emails started, compliance with the rule about locking workstations had gone from around 10% to over 90% in just a few weeks.
Everything about this business amused me, from the kitty theme itself to idea of security enforcement by (mild) peer pressure. And it's certainly effective—you can bet that before I run to the kitchen or step next door for a wee meeting, I make sure that I've locked my computer.
[categories]
work, technology
|
link
|
Thursday, 8 December 2011
06:19 PM
The standard model for creating large documentation sets pretends, in essence, that the content springs from a single faceless source, namely <Your Company>. This is one of the concerns (not the only one) of a style guide, namely to define an overall tone for a content set that originates with different authors. And of course corporate-created documentation is generally not credited, and certainly not at the article level.
 We're starting an experiment with changing this for our own docs. For our last couple of big tutorial sets, we're attaching author names and bios to the bottom. Here are a couple of examples:In both cases, the author info is at the bottom.
We're also going to be experimenting with adding this info to MSDN topics. Here's an example (actually still a prototype) of what that might look like:
We reckon that adding author attribution has these benefits, in no particular order:- Authors help develop their "brand".
- Readers can learn to associate an author's name with a specific level, quality, and focus of work.
- Content will get a personality and human face.
- Readers get the (correct) impression that documentation is created by actual people.
- Writers get public acknowledgment of their work — the company in effect puts its own stamp of approval on the writer's work, by name.
There is of course lots of precendence for this. Blogs have author attribution, obviously, and blogs have long had the benefits listed above. Books have prominent authorship, same benefits. The Patterns & Practices group at Microsoft often (not always, oddly) includes attribution (example).
It's actually interesting to contemplate whether there's any downside. The original idea of a monolithic corporate voice was probably of concern in the pre-blog days when such a voice was perceived to have more authority, perhaps. But the plethora of high-quality, attributed content on the web has probably gotten people very used to the idea that every article is written by somebody. And so it is.
[categories]
writing, work
|
link
|
Wednesday, 9 March 2011
11:59 PM
Over the years, when I told people I worked at Microsoft, a common reaction[1] was "I hear they make you work long hours!" Depending on how useful it seemed to engage the conversation, one of the answers I had was "No one makes you work any number of hours." This was a slightly disingenuous response, but it is in essence true: most jobs at Microsoft, and in tech generally, are not punch-clock jobs, and I literally cannot recall a boss asking me whether I'd put in my 40 (or 50 or 60, haha) hours.
 Long before my Microsoft gig, I wiled away my 20s working lots of 60-hour weeks, happily writing and coding late into the night. Even these days I still like the adrenaline and focus of crunch mode, although as I become, er, more mature, my recovery time from extended days of long hours has become longer.
I was thinking about this because of a piece in Forbes titled Job One for Leaders, in which the author, August Turak, discusses how to motivate employees. "As CEO I always told job applicants that my primary job was increasing pressure while decreasing stress." He goes on to explain the difference:
As leaders, it is our job to increase pressure by giving people reasons to care. We decrease stress by empowering people with all the tools necessary to successfully influence the outcome. [...] Maximum pressure combined with minimum stress produces passion, and passionate organizations full of passionate people will accomplish well-nigh anything. The most important leadership task is providing the ‘whys’ so that others can provide the ‘hows’. Managers get things done, but leaders must decide what is worth doing in the first place and get everyone else to buy in.
This is easy to understand if you reverse the conditions: ask people to do something they don't care about and give them no control over the outcome, and you've got a recipe for stress and its attendant manifestations, like depression and burnout.
How do you increase pressure? One way it to give people a stake in the outcome. Money is one way, but one of the tasks of management is to understand what motivates individual employees — money, peer recognition, whatever[2] — and make sure they're getting that from the job.
The goal has to be meaningful, of course. That's certainly a theme you hear from people who work at Microsoft is how much impact their work has (#, #) — it's by no means a stretch to think that something you do will be used or seen by millions of people.
Another motivator is deadlines. Deadlines are, of course, the classic motivator for anyone prone to procrastination, which is most of us[3]. I love this quote from Duke Ellington: I don't need time, I need a deadline." (Or this one from Sam Johnson: "Depend upon it, sir, when a man knows he is to be hanged in a fortnight, it concentrates his mind wonderfully.")
But this only works if the goal to be achieved is attainable in the allotted time and the deadlines are real. Artificial deadlines, set only to motivate people, are weak, and deadlines that are impossible to achieve are counterproductive. Many of the projects I work on have deadlines that are keyed to things like annual tradeshows, which provides a framework and, as they call it, a hard stop.
Then you have to reduce stress. For starters, you have to make sure people have the means to achieve the goal that you've now motvated them to go after. What do those consist of? Skills, tools, and, as noted, time are all essential. (In Turak's case, because he led a sales organization, one of the essentials was sales leads[4].)
Then something important you can do is get the heck out of the way. A surprisingly effective productivity tool is autonomy. Some companies practice ROWE (results-oriented work environment):
In a ROWE workplace, people don’t have schedules. They show up when they want. They don’t have to be in the office at a certain time — or any time, for that matter. They just have to get their work done. How they do it, when they do it and where they do it is up to them.
Although Microsoft is not formally a ROWE-embracing corporation (at least, that I've heard), in practice it often seems that way. On the teams I've worked on, people generally manage their own schedules within the loose constraints imposed by the company. And given especially the latter-day mobility of email on small devices, it sometimes seems as if there's no time of the day when people are entirely off the clock.
The company lets us connect to work from our home computers and work that way, which is of course a brilliant tactic — if I were limited to working only when I was sitting at my desk in the work office, I'd probably work only 50% of the hours that I currently put in. As it is, I'm basically free to work any time, including evenings, on weekends, and even during bouts of insomnia. And I do.
I think the gist of the question that people would ask about Microsoft was implicitly about what Turak addresses. Many people, I suppose, equate long hours only with stress, with being forced to work at unpleasant tasks. But for the most part, I worked (work) long hours because of pressure, in the motivational sense that Turak explains.
To be clear, it's not as if everyone is always super-motivated and never feels stress. Even if you have leaders who hew closely to Turak's philosophy, various conditions can arise that reduce motivation and increase stress. (And of course, it's not as if there's never been a failure of leadership.) But Turak's general observations feel right to me, based on my (thankfully) overall positive experience in the software industry. It's difficult for me to imagine working for a company that didn't follow his principles.
[categories]
work
|
link
|
Friday, 14 January 2011
08:55 AM
As I’ve noted before, when spelling-checker software gets attention, it’s because something went wrong. And I’ve also noted before that lots of people think that spelling checkers, and the spelling checker in Word in particular, are not very good.
That isn’t me. I use the spelling checker[1] in Word all the time. In fact, even if I’m writing something in some other editing tool, and even if that tool has a spelling checker, I will often copy the content to a Word document and run the spelling checker there. (This is especially true when I work with HTML documents.) When I found myself doing that again recently, I thought I should sort out why exactly I find it so useful. So here are some thoughts on why the spellchecker in Word works so well for me personally. (As they say, YMMV.)
It’s overwhelmingly right. I am in fact a wretched typist. One of the reasons that this isn’t quite as obvious as it might be is that Word finds the two or three words per sentence that I’ve mistyped and scolds me. People like to harp on cases where Word misses a misspelling (10 Common Errors “Spell Check” Won’t Catch [2]) or suggests some absurd replacement for a misspelled word ("Cupertinos"). But realistically, the percentage of times that Word is right versus these oddball cases has got to be in the high 90th percentile.[3]
It works both in real time and in batch mode. By default, Word flags misspelled words as you type. (You can disable this if you don’t like it.) You can also press F7 and invoke the spelling checker at any time, which you can use to check with the whole document or the current selection—see also next point. I rely on both modes heavily.
It starts checking from where the insertion point is in the document. Some batch-mode spelling checkers always start at the beginning of the document (or selection). In long documents, this is actually quite annoying.
It can check multiple languages. When I was taking Spanish and had to write for class, I found that the spelling checker not only could proof Spanish, but that Word would auto-detect the language of a document or even paragraph, if I was alternating languages. (Proofing my Spanish homework caught a heck of a lot of errors, let me tell you.)
It’s reasonably smart about matching the capitalization of words it fixes. When it suggests replacement words, Word tries to match the case of the error it's found:
This isn't perfect by any means, but it's often right.
It lets you edit both the word and its context live in the spell-check dialog box. In the Spelling and Grammar dialog box, the error is displayed in context in an editable window. Your choice for a fix isn't just what it suggests, and you're not limited to correcting just the misspelled word -- you get a useful snippet of the word's context to edit.
It distinguishes words by case that you've added to the dictionary. This is both a plus and a minus, actually, but on the whole, it's a better-safe-than-sorry plus. I've added a lot of product names and programming keywords to my custom dictionary. These are almost always case-sensitive, so it's helpful that Word finds casing errors in these terms:
The spell-checking dialog box isn’t modal. This one is big for me. When the Spelling and Grammar dialog box is open, you can click back in the document and edit there. (In many spelling checkers, you have to close the dialog box in order to return to the document and fix something.) This is useful to me if the spelling check has either found something too complicated to fix in its live-edit box, or if Word has uncovered some other, non-spelling-related error that I want to fix right now.
You can disable it by style. Another big one for me. I constantly work with documents that have long code examples or HTML listings, both of which contain many oddball words that aren’t normal English. When I spell-check the document, it's tedious to Ignore my way through these and it's dangerous to choose Ignore All for these weird terms. I can pop out of spelling checker dialog box (see previous point), skip over the code examples, and resume at the next bit of real text (see different previous point). This helps, but is still a little tedious. The best solution is to define a Word style and apply it to that text. Then as part of that style, you can tell Word to ignore it for purposes of spell checking:
I suppose an even more ideal solution here would be to be able to tell Word that the text is code or HTML, and then have Word somehow be able check the spelling in that context. HTML editors like Expression Web use spell-check-type flagging to mark unrecognized HTML keywords; Visual Studio can find both bad HTML and bad code:
As I say, nice to have, though not of course a mainstream scenario for the spelling checker in Word.
Admittedly, I spend more time in Word than most people, and my job involves some spell-checking challenges that probably aren't that widespread. Still, I think that the combination of spell-check smarts in Word and the way they've implemented the check is better than anything else I've used.
What other spelling checkers do you love?
[categories]
writing, editing, MS Word, work
|
link
|
Thursday, 1 July 2010
05:52 PM
Last time I talked a little about the interviewing process and investigating the technical side of technical writing in our group. If you don't pass a technical screen, we're unlikely to pursue the interview. But assuming you do get over whatever bar is set, comes now the writing side.
 A diversion. As I will touch on later, there's a difference between a person who can write and a person whose job is writing. A programmer who writes the occasional blog entry is not (yet) a technical writer, who in contrast spends week after week documenting not just the interesting and cool things that are fun to write about, but also the seemingly endless APIs, the unsexy readme files, the installation instructions, and all the other stuff that users need, and who do this on relentless schedules. (As people sometimes say, "that's why they call it work").
Ok, writing. How do you assess writing skills, and specifically technical writing? If anyone's developed a foolproof way, I haven't heard of it.
What about writing samples? A good start, and indeed, a necessary condition, but not a sufficient one. It's hard to imagine a candidate with no writing samples at all getting far in the process. On the other hand, impressive writing samples are always nice, but it's never clear how much of the work actually is the candidate's and how much was contributed by (for example) editorial review. In this regard, blog entries are (IMO) actually good writing samples. If a good blog is added to a sample that shows experience writing API docs, I definitely sit up and take notice. (FWIW, I haven't seen this a lot.) A writing sample can also become an interesting point of drilldown, as I'll explain in a minute.
Writing test? This idea has always been bandied about (you'd never hire an editor without an editing test), but it's never really come to fruition, at least that I've seen. Decades ago I used to administer a writing test that consisted of listing a handful of SQL-like statements and the resulting output and asking the candidate to sketch out the documentation for this "language." However, that's a pretty intensive effort that we don't have the time for in our brisk process. (We might also have some constraints associated with having to administer the same test the same way each time, but I'm not sure about that.)
So we do a lot of our assessment via questions. If I indeed have the charter to investigate the candidate's writing skills (I don't always), during the interview, I ask some questions that are fairly broad, along these lines.- I see that you did some writing for [Product X]. What does that product do? (I just pick something off their resume.) To me this is a pretty simple test for writing ability. Can you describe something to me that I don't know about? Did you bother to establish what I might already know about it? Can you tune your description to my knowledge and interest? Like that.
- You're given a 1.0 product to work on, and six weeks to do it. What do you do? Here I'm looking for thoughts on how to plan, how to prioritize, how to use available resources creatively, what to produce, whether they consider non-writing avenues (e.g. video), how to think beyond the next deadline, maybe how to negotiate with other teams, etc. If they've been in the business for a while, they've faced this one, so I'm all ears about how it went and maybe what they learned.
- What's your experience with editors? Tell me about a time when you and the editor disagreed about something. Obviously, I am leery of people who either have not been edited or who are grumbly about editing. (To be fair, I know writers who are justified in their skepticism about technical editors. Still, a response like "My editor was an idiot, so I just ignored them" is, as you can imagine, not encouraging.)
- How do you know if you've succeeded? I'm looking for some insights into things like getting reviews, checking customer feedback (or otherwise interacting with customers) — whatever they might think of. This might also tell me something about whether the writer is actively interested in doing a good job or has a "it's published, I'm done" attitude.
- What skills do you think make a good technical writer? If "good grammar and spelling" seems to be a focus, I start to have my doubts.
- What's the best kind of documentation? The winner here is "the best doc is doc that's not needed," but I'm interested to hear whether they've thought about the purpose of documentation, how it's used, by whom, etc. For our context, I also like to hear about code samples and other programmer-centric thinking.
- If you could do any job tomorrow, what would it be? This seems like a transparent snare, but an open tech-writer position can attract people who think they might want to look into this writing business because they're tired of what they're doing and hey, they wrote a whitepaper once and that was fun.[1]
If I have a decent writing sample, I might also ask some specifics about the sample -- what was the thinking, why this approach, what were some of the issues, how was it received, etc. I also hope to get some sense of whether they were using a style guide/sheet and had a formal editing and publishing process. I'll also ask what tools they've used, not because I care specifically about those tools, but because I am interested if they've worked in a professional environment and how they feel about that.
If they've provided multiple samples, I might ask which is their favorite and why. What I'm hoping to elicit here is some enthusiasm and pride for their work.
Hmm. I see that these are questions about writing skills in a very broad definition. But that's what we're after.
There's a million more questions (I have a 6-page document full of them), but the specifics aren't really that important. The important point is that what I probe for is to determine whether the person sitting across from me is, in fact, a writer. As Chris Sells once said, "Don't prepare. Be yourself. If you're not a fit for MS, no amount of preparation in the days before an interview will help." (Read his whole interview.)
There are times when it's obvious, either pro or con. There are other times when it's just not clear. (An odd case that I've learned to trust is the person who seems to be -- in fact, is -- a good writer but is not driven to it compulsively, and would not write except as a job.)
I know from experience that it's quite a bit harder to find a really good programmer/writer than I would have imagined in my younger days. As you might expect (?), I've worked with folks where the programming skills definitely were the stronger half of the binomial. That, I suppose, is where my job comes into it. :-)
[categories]
work, writing
|
link
|
Tuesday, 15 January 2008
08:22 AM
My friend P called me up the other day and asked whether I knew of anyone who could program Paradox, which is a database program for personal computers that was released in the 1980s. If this doesn't mean anything to you, you can think of it as perhaps the PC software equivalent to asking your friends if they just happen to have a repair manual for an AMC Hornet, or an LP of the Cowsills.
Friend P doesn't know Paradox, so he called me. I don't know the product either, but I did offer to help find someone. I forwarded Friend P's inquiry to about a dozen people who I thought might either have PC history that goes that far back or who know databases. About two hours later someone replied who had indeed worked with Paradox long ago, and I hooked him up with Friend P.
 Frankly, I was not entirely surprised. Naturally, I was not surprised when most of the people I contacted responded with "Nope, not me!" (altho people did remember the software, so I knew my selection of recipients was not too far off). But I was also not that surprised that someone I kind of know proved to be the right contact.
The famous "six degrees of separation" comes from an experiment that was done in the late 1960s in which the experimenter asked people to get a packet to a person in a distant city. The idea was that you could hand the letter to someone who might know someone who ... and so on. There were some surprises that came out of the experiment; the most well-known was how short the chain was from the original sender to the recipient. Nowadays -- and very much as a result of this experiment -- we kind of understand this, but before this trial, people thought that it would take many, many more people to connect you to some remote stranger. As it turned out, on average it took between 5 and 6 intermediaries to reach the ultimate recipient.
Thus the power of social networks. What my recent experience underscored, however, was that a lot of the power of social networks comes via the "weak ties" between people. Malcolm Gladwell (from whom I crib most of this info) recounts a study that looked at how social networks work when you're looking for a job:[A]lmost fifty-six per cent of those he talked to had found their jobs through a personal connection [...] This much is not surprising: the best way to get in the door is through a personal contact. But the majority of those personal connections did not involve close friends. They were what he called "weak ties." Of those who used a contact to find a job, for example, only 16.7 per cent saw that contact "often," as they would have if the contact had been a good friend; 55.6 per cent saw their contact only "occasionally"; and 27.8 per cent saw the contact "rarely." People were getting their jobs not through their friends but through acquaintances. In some senses, the weakness of the tie is actually a critical factor in leveraging a social network:[W]hen it comes to finding out about new jobs -- or, for that matter, gaining new information, or looking for new ideas[1] -- weak ties tend to be more important than strong ties. Your friends, after all, occupy the same world that you do. They work with you, or live near you, and go to the same churches, schools, or parties. How much, then, do they know that you don't know? Mere acquaintances, on the other hand, are much more likely to know something that you don't. When Friend P contacted me, he had already inquired without success among people in his immediate work circle, so he threw a line over to my network. When I got his request, I didn't just ask the people who have offices on either side of me; I sent his request to people I worked with years or even decades ago, or in some cases, to people I have never even met in person. My acquaintance with some of the people on the list is pretty slim ("we worked together once" or "a guy whose blog I read") -- some of those ties are pretty dang weak. But it worked, and as I say, I wasn't hugely surprised.
Think about this with respect to Facebook, say, or Linked in (whose slogan is "Relationships matter"). If all you ever wanted to do was talk to your immediate social circle or consult with your professional colleagues down the hall, there would be no need for a social-networking site. The premise of these sites is not that my bestest buddy can contact me, but that the network can capture people to whom I have weak ties. The sites expose chains of mutual acquaintance that result in friends (well, "friends") and professional contacts. (See also this great video explanation of social networks.)
There's lots more to social networks (another interesting outcome of the original study was in identifying "hub people"), but situation after situation reinforces the idea that we're just a few contacts away from a lot of other people. Next time you're looking for a job (or a date), let your social network, and the network it belongs to, help you out.
[categories]
general, work
|
link
|
Wednesday, 12 September 2007
09:05 AM
It's crunch mode again. OTOH, Hawaii in 19 days.
The Tech Battle in Seattle. On the O'Reilly blog, Brady Forrest shows a map of Seattle that indicates where various tech companies -- Microsoft, Google, Yahoo, and Amazon among them -- are expanding their Seattle-area operations. This is good for jobs. Probably bad for traffic.[1] Bad (or good, depending on your POV) for real estate prices.
How to optimize your power strip. I've done some of this (esp w/r/t the UPS) and can recommend it.
Lawyers are always bad PR. Charles Miller has a cautionary tale: "What started as the opinion of a small number of commenters on a medium-traffic Australian forum site is now a portrait of a corporate bully trying to silence critics, splashed over the entire Internet."
The 7 Top employee bungles using Office. Philip Su recounts some of the ways in which Microsoft people have screwed up when using Office. As for #6, a guy I used to work with acquired the nickname "Hotstuff" after he received a, um, personal IM from his wife ... while presenting to the entire product unit.
[categories]
roundup, seattle, work, funny
|
link
|