Written Communication @ Work – Part 1

In this day and age, most of us spend a fair amount of time at work sharing our thoughts and ideas in written form. Be it in emails, instant messages, presentations and what not. But not all of us could claim to be experts in written communication. Why not? Well, the same reason why we cannot be called expert speakers in spite of speaking on a daily basis for years since childhood. An expert in any field knows the DOs and DONTs of his/her craft.

This is my attempt to learn those DOs and DONTs and try to become an expert in something that I do on a daily basis.

  • Understand the purpose of writing
    • Know why you are writing. Know what you want the outcome to be.
    • Say clearly and convincingly, what the issue is and what you want to accomplish.
    • Focus on the reaction you are trying to elicit from the reader.
  • Understand your reader
    • Respect your reader’s time constraints. Understand that your readers have no time to waste: Get to the point quickly and clearly to ensure that your message gets read.
    • Use a tone appropriate to your audience.
    • Highlight the important thing “what’s in it for them”. If they can easily see how your message is relevant to them, they will be more likely to read it and respond.
    • Connect with particular reader to connect with larger audiences. If you focus on a smart nonspecialist who is in your audience, you’ll strike a balance between sophistication and accessibility. Your writing will be more appealing and persuasive.
  • Divide the writing into a series of 4 separate tasks using the MACJ method. (Madman, Architect, Carpenter, Judge)
    • Madman
      • gathers ideas and material first. Dumps all the best idea to come early by methodically brainstorming at the beginning of the process.
    • Architect
      • organizes the madman’s raw material into a sensible outline. Distills ideas into 3 main propositions.
      • Categorize the main points in sets of three (4 or more is too much)
    • Carpenter
      • Write the draft copy as quickly as possible using architect’s outline and madman’s ideas without worrying about perfecting the prose.
      • Don’t get stuck waiting for an inspiration. Try giving yourself 5 to 10 minutes for each section when drafting.
      • Don’t edit and perfect until the draft is finished.
      • If you are stuck with something, move to the next section.
    • Judge
      • assume the role of the Judge to edit, polish, and improve the piece. Do this in several distinct passes, each time focusing on only one element of your writing.
  • The Who-Why-What-When-How Chart
    • Who are you writing for? Consider your audience’s concerns, motivations, and background.
    • Why are you writing? Keep your purposes firmly in mind. Every sentence should advance it.
    • What needs saying? Include only the main points and details that will get your message across.
    • When are you expecting actions to be taken? State your time frame.
    • How will your communication benefit your readers? Make it clear to readers how you’re meeting their needs.


  • HBR Guide to Better Business Writing

About Groovy Binary Compatibility

Important information about Groovy binary compatibility

Excerpted from “Making Java Groovy” book.

How projects in the Groovy ecosystem include Groovy

One of the dirty little secrets of Groovy is that the major versions are not always binary compatible. Code compiled with one version doesn’t necessarily work with any other.

This means that projects in the Groovy ecosystem have a choice. They can either be compiled with different versions of Groovy and make the Groovy version number part
of their own version, or they can bundle in a particular version of Groovy.

The Spock framework (discussed in chapter 6) takes the former approach. Spock versions are in the form 0.7-groovy-2.0, meaning Spock version 0.7 compiled with Groovy version 2.0.

The Grails and Gradle projects take the other approach. Grails 1.3.9, for example, includes a copy of Groovy 1.7.8, Grails 2.0.3 includes Groovy 1.8.6, and Grails 2.2.1
includes Groovy 2.0.8. To see the Groovy version included in your Gradle distribution, run the gradle –v command.

Migrating from Google Site to Octopress

I finally decided to move my static personal site from Google site to Octopress, a static blogging framework built on top of Jekyll. Though I was happy initially with Google site, it is a pain to do few things in it like customizing layout, themes, fonts, etc.

Personally I was looking for the following features in a blogging framework to bake my site quickly. To bake a site or a blog, there are plethora of frameworks out there to choose from. Though I started with Jekyll at first, I decided to go with Octopress for its easy of use.

  • simplicity
    • ease of creating content like in markdown format
  • portability
    • local copy of the site source
    • host in Amazon cloud, Github or such
  • customization of
    • themes
    • layout
    • fonts, etc.
  • plugins for
    • source code formatting
    • mathematical formulas in LaTEX
    • search the site
    • table of contents on each page (like in Wikipedia)

To get a local site up & running in Octopress:

  • Download and Install Octopress, Ruby, Python, Git (watch out of version compatibility)
  • Update all ruby gems gem update
  • To create a new page rake new_page[name]. This creates a [name].md file where your enter your content in markdown format.
  • To generate static site in html files rake generate
  • To deploy locally rake preview. This starts a local server on http://localhost:4000/.

From my feature list above, most of them were in-built in Octopress except displaying math formulas. Octopress uses ‘rdiscount‘ markdown by default which does not support math formulas via MathJax. ‘kramdown‘ markdown supports this by default, but it does not have ‘table of content’ feature.

To get around this, I found a custom version of ‘rdiscount‘. (More details)

The personal site is now baked and working locally. To host it in github, create a repository named like reponame.github.io. Running `rake deploy` from the folder where Octopress is installed, deploys the static site to the Github repo under ‘master‘ branch. Voila, the site is now successfully hosted under http://reponame.github.io.

Now you don’t want to keep your site source locally in case of any disaster. You could check in the source code as well in Github in the same repository created above under a different branch called ‘source‘ by executing the following commands.

$ rake generate
$ git add .
$ git commit -am "Some comment here."
$ git push origin source

Book Review: The Secret to Peak Productivity by Tamara Myles; O’Reilly Media

The Secret to Peak Productivity: A Simple Guide to Reaching Your Personal Best by Tamara Myles; O’Reilly Media A Simple Guide to Reaching Your Personal Best

This is truly an excellent book to improve productivity in not only your work life but also the personal life.

Unlike other books, this one doesn’t throw productivity tools at you. It clearly prioritizes which is more important that the other, and how to approach it.

At the very beginning of the book, the author introduces a 5-point course called ‘Peak Productivity System’: (1) Physical Organization (2) Electronic Organization (3) Time Management (4) Activity-Goal alignment (5) Possibility.

Rest of the book goes in-depth talking about those 5-points with plenty of stories and examples.

Few of the things I liked from the book

4 TOs in sorting documents: To keep, To toss, To do, To Shred

3 Ps of time management: Plan, Prioritize and Perform

SMART goals – Specific, Measurable, Attainable, Relevant, Timely

6 steps to goal setting – Commit, understand, create goals, break down into tasks, schedule to work, assess and reassess

Though I enjoy story-telling in teaching new concepts, sometimes I felt the first few chapters were little stretched to explain very basic things. Few paragraphs could have been easily eliminated cutting to the chase right away.

Résumé Preparation Tips

1. Look and Feel


  • End each sentence should with a period(.)
  • Margins should be 0.75 to 1 inches.
  • Check for spelling mistakes in English words. For technical keywords, protect the Word document as read only before distributing to hide the red and green squiggly lines.
  • Resume should be between 2 to 4 pages based on the experience.
  • Avoid images


  • For headings use serif fonts 12pt like Times new roman, Garamond, Georgia, Goudy Old Style
  • For body use sans serif fonts 10pt like Calibri, Arial, Tahoma, Century Gothic, Lucida Sans
  • Don’t try to use fancy fonts. Readers may not have them in their system

2. Content


  • Start with a verb – avoid 1st person pronouns (I, we) and 3rd person pronouns (he, she)
  • Avoid articles that crowd sentences (a, an, the) e.g., use ‘trained staff‘ instead of ‘trained the staff‘.
  • Helping verbs (have, had, may, might): Helping verbs weaken claims and credibility — implying that your time has passed and portraying you as a job-hunting weakling. Say ‘managed‘ instead of ‘have managed‘.
  • Being” verbs (am, is, are, was, were): Being verbs suggest a state of existence rather than a state of motion. Try “monitored requisitions” instead of “requisitions were monitored“. The active voice gives a stronger, more confident delivery.
  • Shifts in tense: Use present tense for a job you’re still in and past tense for jobs you’ve left. But, among the jobs you’ve left, don’t switch back and forth between tenses. Another big mistake: dating a job as though you’re still employed (2008-Present) and then describing it in the past tense.
  • Complex sentences: Unless you keep your sentences lean and clean, readers won’t take time to decipher them.
    • Process this mind-stumper:
      • Reduced hospital costs by 67% by creating a patient-independence program, where they make their own beds, and as noted by hospital finance department, costs of nails and wood totaled $300 less per patient than work hours of maintenance staff.
    • Eliminate complex sentences by dividing ideas into sentences of their own and getting rid of extraneous details:
      • Reduced hospital costs by 67%. Originated patient independence program that decreased per-patient expense by $300 each.
  • Overwriting: Use your own voice; don’t say expeditious when you want to say swift.


  • Accomplishment-oriented resume packs much stronger punch than a responsibility-oriented resume. Recommended keywords: persuaded, influenced, contributed to, participated in, or helped out with.
  • Quantifiable results: Don’t just say ‘reduced cost‘ or ‘improved efficiency‘. Quantify them with technical terms like: seconds of latency, number of bugs or prod incidents, or even an algorithmic improvement in big-O time.
  • Targeted resumes: Tailor your resume according to the role and company you are applying to. e.g., if you’re applying for a technical lead position after years of being a software engineer, you’ll want to mention the time that you led the design of a new feature.
  • Avoid long sentences: Make every bullet point around 1 or 2 lines.
  • No outdated skills under technical skills.
  • Summary/Value Statement: State the role you are applying for and what values you bring to job; Explain why you should be hired.
  • Core Strength / Technical skill summary:
    • comes before chronological project experience.
    • No outdated skills
    • Avoid crowding with too many technical skills.
    • Avoid obvious ones like MS Office, Windows, etc.
  • Experience:
    • Accomplishments, not responsibilities
    • Highlight company names more than the title, project title and the duration.
    • Ensure no gaps in experience timeline.
    • A résumé does not need to be a complete employment history. Do not go more than 10 or 15 yrs back.
    • Reduce the older job descriptions to 2 or 3 lines
  • Always prepare your resume in both Microsoft Word & PDF versions. Some automated systems prefer Word.

3. References

7V’s of Big Data – Briefly

  1. Velocity – speed at which data is created currently is almost unimaginable. e.g., 2.5 million Google queries per minute
  2. Volume – enormous amount of data generated. e.g., airplanes generate 2.5 billion TB of data each year from the sensors installed in the engines.
  3. Variety – Data today comes in many different formats: structured data, semi-structured data, unstructured data and even complex structured data. e.g., Facebook, Twitter, etc.
  4. Veracity – Trust-worthy data. Analysis performed would be useless unless the data is accurate.
  5. Variability – Meaning of the same data could be different based on the context. e.g., Same tweet words can have different meanings and sentiments.
  6. Visualization – Visual representation of analysed data in a comprehensible way.
  7. Value – Data in itself is not valuable at all. The value is in the analyses done on that data and how the data is turned into information and eventually turning it into knowledge.

More detailed explanation: http://www.bigdata-startups.com/3vs-sufficient-describe-big-data/