Pencinta ilmu (Guna Chrome atau Firefox)

Isnin, 23 Julai 2012

I Won't Hire People Who Use Poor Grammar. Here's Why.

If you think an apostrophe was one of the 12 disciples of Jesus, you will never work for me. If you think a semicolon is a regular colon with an identity crisis, I will not hire you. If you scatter commas into a sentence with all the discrimination of a shotgun, you might make it to the foyer before we politely escort you from the building.

Some might call my approach to grammar extreme, but I prefer Lynne Truss's more cuddly phraseology: I am a grammar "stickler." And, like Truss — author of Eats, Shoots & Leaves — I have a "zero tolerance approach" to grammar mistakes that make people look stupid.

Now, Truss and I disagree on what it means to have "zero tolerance." She thinks that people who mix up their itses "deserve to be struck by lightning, hacked up on the spot and buried in an unmarked grave," while I just think they deserve to be passed over for a job — even if they are otherwise qualified for the position.

Everyone who applies for a position at either of my companies, iFixit or Dozuki, takes a mandatory grammar test. Extenuating circumstances aside (dyslexia, English language learners, etc.), if job hopefuls can't distinguish between "to" and "too," their applications go into the bin.

Of course, we write for a living. iFixit.com is the world's largest online repair manual, and Dozuki helps companies write their own technical documentation, like paperless work instructions and step-by-step user manuals. So, it makes sense that we've made a preemptive strike against groan-worthy grammar errors.

But grammar is relevant for all companies. Yes, language is constantly changing, but that doesn't make grammar unimportant. Good grammar is credibility, especially on the internet. In blog posts, on Facebook statuses, in e-mails, and on company websites, your words are all you have. They are a projection of you in your physical absence. And, for better or worse, people judge you if you can't tell the difference between their, there, and they're.

Good grammar makes good business sense — and not just when it comes to hiring writers. Writing isn't in the official job description of most people in our office. Still, we give our grammar test to everybody, including our salespeople, our operations staff, and our programmers.

On the face of it, my zero tolerance approach to grammar errors might seem a little unfair. After all, grammar has nothing to do with job performance, or creativity, or intelligence, right?

Wrong. If it takes someone more than 20 years to notice how to properly use "it's," then that's not a learning curve I'm comfortable with. So, even in this hyper-competitive market, I will pass on a great programmer who cannot write.

Grammar signifies more than just a person's ability to remember high school English. I've found that people who make fewer mistakes on a grammar test also make fewer mistakes when they are doing something completely unrelated to writing — like stocking shelves or labeling parts.

In the same vein, programmers who pay attention to how they construct written language also tend to pay a lot more attention to how they code. You see, at its core, code is prose. Great programmers are more than just code monkeys; according to Stanford programming legend Donald Knuth they are "essayists who work with traditional aesthetic and literary forms." The point: programming should be easily understood by real human beings — not just computers.

And just like good writing and good grammar, when it comes to programming, the devil's in the details. In fact, when it comes to my whole business, details are everything.

I hire people who care about those details. Applicants who don't think writing is important are likely to think lots of other (important) things also aren't important. And I guarantee that even if other companies aren't issuing grammar tests, they pay attention to sloppy mistakes on résumés. After all, sloppy is as sloppy does. That's why I grammar test people who walk in the door looking for a job. Grammar is my litmus test. All applicants say they're detail-oriented; I just make my employees prove it.

- Kyle Wiens is CEO of iFixit, the largest online repair community, as well as founder of Dozuki, a software company dedicated to helping manufacturers publish amazing documentation.

Khamis, 14 Jun 2012

Analisa NVivo - Panduan awal

Banyak maklumat boleh diperolehi berkenaan perisian NVivo dan cara-cara menggunakannya. Bagi saya, NVivo sangat mudah jika anda faham cara manual untuk menganalisa data kualitatif. Perisian akan memudahkan lagi kerja pengurusan data kualitatif yang begitu banyak berbanding data kuantitatif.


Buku yang saya mula rujuk pada awal PhD saya enam tahun lepas ialah tulisan Pat Bazeley. Di samping itu juga saya menghadiri kursus 2 hari pengenalan kajian kualitatif dan NVivo oleh pensyarah UUM di UIAM. Kursus itu nampaknya hanya sebagai ulangan dari apa yang telah dibaca kerana pelajar-pelajar yang hadir merupakan kosong atau permulaan pengetahuan mengenai kajian kualitatif dan NVivo.




Di bawah ini, saya sertakan tajuk-tajuk dalam buku Pat Bazeley:


1 Perspectives: Qualitative computing and NVivo
Qualitative research purposes and NVivo
Issues raised by using software for qualitative data analysis
What does an NVivo project look like?
About this book

2 Starting a project
Starting
Starting with software
Saving your project

3 Making data records
Data for your project
Data in cases
Data preparation
Data records in NVivo
Managing data sources in NVivo

4 Working with data
Goals for early work with data
Gaining perspective on the text
Building knowledge of the data through coding
Storing coding in nodes
Reflecting on the case

5 Connecting ideas
Development of the coding system
Making connections across trees
Coding in practice
Managing coding

6 Managing data
Managing data sources
Bringing demographic or other quantified data into your analysis
Scoping queries

7 The ‘pit stop’
Seeing data afresh in nodes
Searching text
Revisiting the literature
Pausing to ‘play’ with models
The periodic pause

8 Going further
The analytic journey
Queries in NVivo
Starting the journey…
Going further with cases
Going further with concepts
Going further with narrative and discourse
Using numerical counts
Going further into theory building
Moving on – further resources

Selamat menganalisa data

~yba~

Sabtu, 2 Jun 2012

Analisa SPSS - Permulaan

Di bawah ini saya sertakan nasihat, tip dan prosedur dari Julie Pallant yang perlu pelajar dan pengguna SPSS fikirkan sebelum memulakan analisa data.

Starting your data analysis

Most students get quite excited when they finish entering data and they have a data file to analyse. However, before diving in to address all your research questions there are a few things you need to do first. I have listed these below, along with the related chapter in the SPSS Survival Manual

Check the characteristics of the subjects that make up your sample. You will need this information for the method section of your report. Chapter 6
Check all the variables in your data file for errors (particularly out-of-range values). Chapter 5
Obtain descriptive statistics for each of the variables you will be using in your study. These should include means, standard deviations, kurtosis, skewness, and minimum and maximum values. Check that these values are appropriate. Chapter 6
Check the distribution of scores on each of your variables—depending on the variable, you will need to use histograms, boxplots, bar graphs or stem and leaf plots. Look out for very skewed distributions or any unusual pattern of scores. Also check for extreme outliers—these can affect some analyses and may need to be recoded or removed. Chapter 5, 6, 7
Perform the necessary data manipulation procedures (e.g., recode, compute) to create any new variables you need. This is important when creating total scores on a scale, or collapsing down a variable into a smaller number of categories. Afterwards, always run Frequencies on these new variables to check that the procedure has been done correctly. Chapter 8
Check the reliability of the scales you intend using in your analyses. What are the Cronbach alpha values for each scale? How do these results compare to those reported in the literature? Chapter 9
For your continuous variables, check the pattern of intercorrelations. How strongly and in which direction are your variables related? How does this compare with the results reported in the literature? You may also need to obtain scatterplots of the correlation between pairs of your major variables. These are useful for checking for linear relationships between variables. Chapter 11
When choosing which statistical technique to use for your analysis, always check that you have the right type of variables (categorical/continuous). Consider whether a parametric or a non-parametric technique is the most appropriate. Chapter 10
Check with your statistics books and the SPSS Survival Manual to ensure you are not violating any of the major assumptions for the analyses you intend to conduct. This might involve checking that you have enough subjects in your groups, that the variance for each group is similar, or that the distribution of scores on your variables is not too skewed. Parts Four and Five
Remember that SPSS will conduct the analyses that you ask it to do, whether or not these analyses are appropriate. The old saying 'Garbage in, garbage out' applies. It is up to you to ensure that you understand what you are doing and also what the output means. SPSS Survival Manual

A few additional tips

1. Save your output regularly so that if the computer crashes you have not lost too much work. All output files should be saved with a .spo extension onto your disk in the A:/ drive. Give your output file a suitable name so you will able to identify it later, for example 8aug96a.spo. Keep a list of your output files with details of what is included. SPSS produces a lot of output and it is very easy to get lost, so get organised—it will save you a lot of time. 

2. If you need to recode a variable, always create a new variable. Keep the original variable so that if there are any problems you have not lost the data. 

3. If you create any new variables, always check in your codebook that the name you intend to use has not already been used. Otherwise you will lose all the original information. Record the name and explanation of the new variable in your codebook. Keep detailed notes of everything you do. This should include details of cut-off points you use to recode variables, reasons for doing things, reminders to yourself about how to do the analyses, problems that might have occurred etc. 

4. Finally, make sure that when doing your analyses, you get up and stretch, walk around etc., at least every hour. SPSS for Windows can be addictive, a bit like eating peanuts—just one more, and then, just one more … Plan what analyses you intend to do, break your analyses into blocks, and give yourself time to digest the output.

Selamat mencuba dan menganalisa.

~yba~