There's a tendency among some writers to think that sprinkling a little Latin - or worse, Greek - in their writing makes them look like a learned scholar.
It doesn't.
Instead, it indicates either a lack of confidence (hence the need to bolster the text with Latin to prove your erudition to yourself) or gross over-confidence (hence the need to bolster the text with Latin to prove your erudition to others). Either way, Latin is not the right tool to prove yourself.
Reasoned argument, written in clear, concise English will always win out against stylistic flourishings that do more to highlight your self-esteem issues than your argument. Writing is a demonstration of the clarity of your thinking; adding phrases from dead languages merely muddies that clarity in unflattering ways.
That being the case, there are of course exceptions where Latin expresses a concept far more concisely or commonly than the equivalent English. If these expressions are in regular use, you may use them. Otherwise you may not. Acceptable Latin phrases in general communication are:
- ad infinitum (if for no other reason than the equivalent "to infinity" will now inevitably be suffixed in the reader's mind by "and beyond!", which is probably not what you intended your writing to inspire)
- ad nauseam
- annus horribilis (but only ever for a British audience, as it is famous in these isles but not necessarily elsewhere)
- a.d., a.m., b.c., p.m. (but never expanded)
- bona fide (but bona fides should be left for small time American hoodlums)
- carpe diem
- caveat emptor
- deus ex machina
- emeritus
- et tu, Brute?
- etc (but only rarely et cetera for emphasis)
- e.g. (but never exempli gratia)
- in extremis
- in flagrante delicto (but only when discussing the nocturnal activities of those who should know better)
- in loco parentis
- in memoriam (but only in formal writing such as an engraving or death notice)
- in situ
- i.e. (but never id est)
- lorem ipsum (although this is almost a proper noun nowadays, and yes, it is Latin despite the widespread belief that it's gibberish)
- magnum opus (but only where what you are referring to is truly such)
- momento mori
- modus operandi (M.O. is also acceptable)
- non sequitar
- N.B. (but never nota bene)
- per se
- persona non grata
- post coital
- P.S. (but never post scriptum)
- quid pro quo
- Q.E.D. (quod erat demonstrandum should not be used unless making a specific point in an academic or scholarly article)
- sic
- sine qua non (but only if you must, and only if you wish to risk pretension)
- terra firma
- vice versa
These may be used in general writing; in technical writing you may only ever use a Latin phrase where not only is that phrase lacking an English equivalent, but also where the phrase is common enough that it is considered to be vernacular. 156 A.D is a good example where the equivalent - "in the year of our Lord 156" - is so anachronistic as to be less understandable than the Latin. The only time that Latin is otherwise acceptable is when your work is for the Catholic Church and only for the Catholic Church, in which case the more Latin you use the cheaper your translation costs will be.
If there is an equivalent English phrase that is just as concise, use that. Inter alia means "amongst other things" or "in amongst". Both of these are as clear as inter alia and are preferred. Similarly, exempli gratia can be replaced with "for example", whereas e.g. has the advantage of both concision and common usage. Sui generis translates as "in a class of its own" or "stands apart on merit" and either could be used instead. Tabula rasa can be replaced with "blank slate" unless actually discussing Enlightenment philosophy.
Re is a curious case where thanks to email parlance it has come to be seen simply as an abbreviation of "regarding". As such its use in the formal sense is almost entirely unknown and therefore should be avoided in any context that is not purely communicative. Similarly, semper fi(delis) has been used so much in TV and films (thank you, NCIS) that it should be considered as reserved for United States Marine Corp personnel only.
In technical fields you can use as many Latin phrases as are proper - cogito ergo sum, habeas corpus, in utero, primus inter pares, vox populi, etc - but again only where an equivalent English phrase does not exist, or where it does exist but does not carry the same weight of bundled meaning (the cogito being an exemplar of this). Do not use words from within these phrases out of context; there is no need to use ergo when "therefore" will suffice.
There are also many words which are so ingrained in our language that most people wouldn't take them as Latin words - agenda, circa, post mortem, versus. These may be used freely, as may titles of literary works such as Dulce et decorum est. Excelsior! may also be used, but only ironically. Proper nouns, such as Opus Dei should be treated as any other proper noun.
Any other Latin phrase (sic transit gloria mundi, vini, vidi, vici, etc, etc) should be avoided on the grounds that the majority won't understand it, and the English equivalent is perfectly acceptable. And again, for clarity: No Latin phrases in technical documentation, except a.d., a.m., b.c. and p.m.!
I had an interesting conversation recently regarding the order of sprint meetings, and whether it mattered what order the review and retrospective took place. This lead to a wider conversation about whether you could do review, retrospective and planning in only 1 or possibly 2 meetings. That all sounded a bit "dirty agile" to me, which is normally a good cue to re-examine my assumptions to see if I've been thinking too rigidly.
In my head, the sprint ceremony order is one of the inviolable "rules" of scrum, so much so that it didn't really occur to me that people might think differently. It's just one of the default assumptions I have about how scrum is done, rather than a subject for debate. After discussing the matter I still don't think this is something about which you can be flexible, although this is not stubbornness so much as the lack of a compelling argument to the contrary. I'm open to persuasion if such an argument exists though.
The agile mantra of "Inspect and adapt" is high on my list of principles, so to that end I'll lay out the order of sprint meetings and why they need to be discrete meetings, and if anyone wants to chip in with counter suggestions I'm all ears.
First, the facts as I see them:
- The Review should happen on the last day of the sprint.
- The Retrospective should happen on the last day of the sprint.
- The Retrospective should take place after the Review.
- There should be a break between the Review and Retrospective of at least an hour.
- The Planning should happen on the first day of the next sprint.
- The Planning for the next sprint should never happen until the Review and Retrospective from the previous sprint have been completed.
And now the justification for each of those points:
1. The Review can only happen once all of the sprint stories have been completed and not before. Therefore the Review needs to happen at the end of the sprint. If all of the stories in the sprint have been completed before the end of the sprint then either additional stories can be added - if there's adequate time to complete them before the end of the sprint - or the team can groom the backlog, triage support requests, refactor code, and any other tasks that don't impact the sprint velocity. (If a task impacted the sprint velocity it would be story-pointed and as such be a story that was added to the sprint.)
The Review will already be a recurring appointment in the stakeholders' calendars and as stakeholders are often in demand it shouldn't be assumed that bringing the Review forward will be simple case of sending out an updated appointment. This is especially true where stakeholders are many and/or senior. But this a practical objection, albeit a sensible one, and as such doesn't have the force of compulsion. The compulsion should lie in the fact that moving the review forward serves no purpose. Assume that the Review is moved forward. Either the Retrospective is moved forward as well or it is not. If the Retrospective is not moved forward then moving the Review has served no purpose because the team still has to wait for the Retrospective. If the Retrospective is moved forwards as well then the end of the sprint must be moved forward, otherwise the team will have to wait for that instead. If the end of the sprint is moved then the next sprint must be started. This means that your sprint will start on a sub-optimal day. Any teams working on the same sprint cycle will now be on a different sprint cycle. The team's velocity calculations will no longer be valid. Your customers - assuming you release an increment at the end of each sprint - will have to change their processes to accommodate a different cycle. There are other issues that will arise depending on circumstances, but all of them revolve around disturbing the cadence and rhythm of the sprint cycle. Scrum is predicated on having this cycle as part of the methodology for successful teams; there appears to be no benefit to disturbing it.
2. Assuming that the arguments for the timing of the Review ceremony hold, the same will apply to the Retrospective. Therefore let's look at the order of the Review and Retrospective meetings.
3. There is an argument that holding the Retrospective before the Review allows the team to deal with what went wrong and then finish the sprint on a good note with the Review where they can show off their work to the stakeholders. I like the sentiment, but not the logic. The argument hinges on 2 unfounded assumptions, namely that the Retrospective is all about what went wrong and therefore is a necessarily less than enjoyable meeting, and that the Review will always go well. Neither of these assumptions stand up to scrutiny, regardless of personal experience. That's not to say that for some people Retrospectives are a generally unpleasant experience, nor to suggest that every team has had a Review that didn't go well. But my assertion is firstly that a Retrospective should neither focus purely on what went wrong, nor be an unpleasant experience, and secondly that the assumption of future Review success based on past glories is hubris that will inevitably bite the team at some point in the future.
The long and the short of it is that the Retrospective should be honest but not unpleasant. It's true that if you are the kind of person who doesn't take criticism well then you might not like hearing that something you were responsible for didn't go well, but frankly that's your problem and you owe your team a more mature attitude. Likewise, if there is a team member who revels in shoving failure down the throats of their team-mates that's not pleasant either, but the group should combine to shut that person down (or in extremis remove them from the team). Being part of a scrum team means learning and growing through an iterative process. You have to be open to that.
Likewise, Reviews can go wrong. More importantly, they can teach you things you didn't know if you have active stakeholder participation (which you should have!). Either way, the Retrospective is where these things should be discussed and actions created. This can only happen if the Retrospective happens after the Review.
4. Ok, fine, we do the Review then the Retrospective. We'll do them in one meeting and get it all out of the way, ok? No, not ok. The Retrospective should be a separate meeting, because what comes out of the Review needs to be thought about before having the Retrospective. Also, people work better when they've had a break, and the Review can be tiring if you've got a lot of questions to answer from stakeholders. Give people a break for an hour or two, let the Review comments sink in, then do the Retrospective. You'll all get more out of it that way
5 If points 1 - 3 are assumed, then the timing of the Planning meeting becomes self-evident. You can't complete any stories unless you've got stories to work on, and to get your stories you need to have a Planning meeting.
6 Well, why can't we plan our next sprint if we've got some spare time? Because actions will come out of the Retrospective, and quite possibly the Review, and these should be captured in your task management system and might need to go into the next sprint. You can groom items on the backlog, and that includes estimating story points and task time, but you won't know what the final priorities are until all of the previous sprint has been completed and the Product Owner has updated the backlog with the latest priorities.
Hopefully that explanation provides solid reasoning for you, but don't be afraid to drop a comment below if you disagree!
There is a fair amount of disdain amongst some writers for using Microsoft Word to produce documentation of any size. I use the word "disdain" because the people that "hate" Word normally type "Micro$oft" as a mark of how edgily anti-establishment they are (while using an iPhone). There's no point engaging with these people in any meaningful way, because they're either teenagers trying to look cool (because all the ladies love a man who knows bash, right?) or adults who have a lot of unresolved issues (seriously, why don't women understand how cool I am???).
Very few writers actively hate Word, and when we do, it's oddly got nothing to do with whether Word is actually any good. As it happens, even writers who use variants of SGML every single day and never go near Word will acknowledge that if you just want to whip up a one page letter then Word is the tool to use. However, that doesn't mean they'll use it to whip up a one page letter, because they're professionals.
And there it is. That, dear reader, is the problem that a lot of writers have with Word. It's snobbery. But before you get all hot under the keyboard and splutter indignantly in the comments, I need to contextualise that snobbery a bit.
Word is an astonishingly polished and powerful writing tool. I've been at this professional writing malarkey for over a decade, and in that time I've used Google Docs, Open Office, Libre, Zoho and a few others I can't even remember and none of them come even vaguely close to matching Word's functionality, intelligence and integration points. This is especially true for Office 2013 and the desktop version of 365. No matter how one-eyed you are about Word and it's faults - and it does have faults - if you deny that Word is the single most capable word processing tool around then you're wrong. Fact. It's not even a matter of opinion. It's not like arguing about whether the Aston Martin DB9 or Jaguar F-type is the prettier car where there is room for subjective opinion, it's about plain facts. Word can do more, do it better, and do it more intelligently than anything else out there.
So why the snobbery? Why don't some writing professionals give Word the love it deserves? They don't use it everyday, because there are better tools for things like single sourcing, topic based authoring and so on and so on and that's fair enough. Word is designed to allow you to write everything from a 1 page shopping list to a 500 page book, and it will do those and everything in between very well, but it's like buying a Range Rover. You can drive over almost any terrain in a Range Rover, and do very illegal speeds on the motorway, and be very comfortable, and fit a lot in the boot, but it's not as good as a tank off-road, or a Ferrari for high speed or a Rolls-Royce for comfort or a van for load capacity. But it's still the best all-rounder by some distance. That's Word. Other writing tools offer specialist functionality, but is there a single PC user who hasn't used Word to write something at some point? Unlikely. And if there are, their numbers will be vanishingly small, because Word is just the best all-round package available and therefore the most ubiquitous. (There are additional reasons to explain the Office hegemony, but that doesn't change the facts about Word's pre-eminence.)
If you want to understand the snobbery about Word, it can be boiled down to that pre-eminence. It's not the fact that Word is popular, otherwise writers would never visit Starbucks, and it's not that Word isn't the best tool for the job, because in some circumstances it demonstrably is.
No, the reason a lot of writers don't like Word is that it's made it so easy for Billy Bob Developer to write a decent looking document that people now think technical writing is easy, and oh my God is that fricking annoying!
No-one likes to feel that other people think their job is easy when you know that it's not. It's fair to say that some jobs are easier than others, and some jobs require more training that others, and I'm not going to suggest that writing a help file is more intellectually demanding than writing a compiler. But by the same token, I know someone who has written compilers, and his opinion was that writing the documentation for them was the most difficult part, because he could see everything in his head but he didn't know how to communicate it in writing.
As a professional writer, this pleases me. I like the validation that my job is not easy for some people. I like the fact that someone who does something I have no idea how to do considers my job the hardest part of his working day, when I find it the easiest. It's a nice feeling.
And then along comes a bozo who thinks they can do my job because they've worked out how to add headers and footers to a Word document.
It's
very easy to develop an irrational hatred of Word when you constantly
hear "Can't you just whip up a quick Word document?", or "Why can't you
just write it in Word?" and of course our particular
favourite, "Why is it taking so long? I could do it myself in 10 minutes in
Word!". There are many, many variants of these phrases and every
single one adds a small straw to the camel's back. Eventually, the
camel breaks down and from that point Word becomes "The Enemy". So
writers subtly, or not so-subtly, point out that "Of course Word is
good, but as a professional I use something different", the implication of course being that using Word is fine for amateurs, but not "proper" writers. The dislike of Word, ostensibly because it's not a professional tool, becomes a way of setting ourselves apart from non-writers.
It's a tribal thing, and snobbery about the way that people outside of your tribe do something is a key part of all tribes. For many writers, being snobbish about using Word is an identifier that marks them as a member of a tribe they want to belong to. It differentiates them, gives them an identity and a sense of collective, whilst letting them rail against Word as a proxy for all of the non-writers who don't understand what writers do and treat them accordingly. It doesn't matter how good Word actually is, it matters that it's a stick that some people use to beat us with. Or at least that's how it feels.
I'm not going to spell out the myriad reasons:
a) why Word is not always appropriate for what we do,
b) why Word doesn't have all of the functionality that we really, really, really need, and
c) why you can't do something better yourself in Word.
If you're reading this the chances are you either know the answers yourself or at least are smart enough to know that the answers are good ones. But next time you hear a writer railing against Word, just remember that once upon a time we were all Word fans....until it got too good.
