The art of getting help

We use a lot of open source software at work, and I subscribe to user-group lists.

(Some) users of the sub-continent have an amazing ability to annoy user-group lists by posting stuff like:

• I am new. Where do I start? (There is a well setup website with LOTS of examples to get your feet wet AND start swimming)

• This is my situation. Please help. (Without having searched archives)
  

• This is my situation. Send me some code I can use. (Why should someone else do *your* work?)

• Repeated requests for help on the SAME topic. (Open source mailing lists comprise of other users who *volunteer* help and not paid tech-support)

• I am getting an error. Please help. (With no attempt to troubleshoot or debug)
  

• Incoherently asked questions with incomplete information.

Is it too much to expect "engineers" (yes, that is probably what most of them carry in their titles) to be able to post queries that:

• Are clear and concise
• Display what attempts the seeker of help has already made to try and solve the problem - - yes this implies that you DO try and look for a solution instead of running to others for help immediately
• Do not beg for help
• Do not expect a ready made solution that can be swallowed as-is in the next 20 minutes
• Are grammatically coherent?

My dream job

In order of priority:

1> 20 hours a week
2> Flexible working hours, with occasional work-from-home days
3> Pays ALL bills
4> Smart peers
5> Mentally challenging work

I should just ask for the moon and be done with it ;-)

What nice homework

My 6 year old gets a pile of homework each weekend, but once he starts, he actually enjoys doing it. Given that his Literature textbook is Cat in the Hat by Dr. Seuss, it is no surprise.

Inspired by Cat in the Hat, this weekend, he had to write some of the rules of his house. This is what he came up with:

1> Do not go out alone.
2> When you come from any place wash your hands with soap.
3> In a shop dont get lost.
4> Do not eat much junk food.
5> Do not break toys.
6> Do not tear books.
7> Do not throw things.

Work Culture and H1N1

I've been part of the Indian corporate world for over a decade. In this decade, I have seen that, without exception, showing up at work when sick (particularly with fever) will get you rated as a star performer and great team player.

I always fail to understand how you are a team player if you can potentially make every other person fall ill or a star performer if your productivity is seriously compromised due to a fuzzy brain. Then again, such are the ways of the world...

Until ... H1N1 :-)

Somebody I know trooped in to work after having had a 102 F fever (no it wasn't H1N1) the previous evening and was asked to go back by the Project Manager for fear of passing it on to other people :-D

It took something like H1N1 to rock the foundation of Indian work culture. Does that say something?

Netflix' Corporate Culture

Just finished reading through all 128 slides of Netflix' corporate culture (I have to admit the first time I just skimmed ;-)).

When I skimmed through the presentation, the impression I got was that of a high-pressure workplace. A detailed read-through, however, makes it seem like an enabling environment as opposed to a pressurizing one.

A belief that I have encountered of late is that mediocre performers make better team players. However, I completely agree with Netflix: Mediocre colleagues or unchallenging work is what kills progress of a person's skills.

"Wonder" Tool

I received in my inbox an email about "a scriptless, easy to use, accelerated test environment to enhance quality, that brings power of test automation tools to every tester’s desk irrespective of the understanding of the test Automation tool" (emphasis mine).

The email went on to describe the benefits of the "Wonder" tool which included "productivity gain of 200%"! Wow! And here I thought the maximum possible percentage was 100! Silly me.

"Wonder" tool also "encapsulates the non –coherent complexities of test automation and eliminates the need of highly skilled resources".

Here's my question: Are there still people out there who fall for such drivel? Can I sell them some snake oil, while we are at it ;-)?

Age of Agile

Over the last few days, my mandate has been to read extensively about process in general and CMM(I) in particular (it seems I already read enough about Agile ;-)). I have also been interacting with proponents and practitioners of both processes.

One trend that I see among CMM(I) proponents is to forcefully point out that Agile is not new and has been around as Iterative Development for the past 75 years.

Why do process-heavy proponents seek to grandfather Agile? What am I missing here?

Karate, Tennis, Music, Dance or something else?

I have a bright 6 year old who, apart from being at school from 8 am to 3.30 pm, periodically expresses desires to learn other stuff.

Last (academic) year, he learnt tennis, vocal music and went for a weekly "Success" camp. This academic year, we already have on our plate karate, a weekly "Success" camp and (intermittently) vocal music. He wants to add tennis and dancing.

Karate takes away 3 afternoons a week. Camp is on Saturday morning. Tennis if added is another 3 afternoons and dancing will be 2 evenings. When I do the math I wonder how I am going to fit all this in.

Oh and did I mention skating, yoga and Western vocal music that gets learnt in school?

I sometimes wonder, is it useful to be sending him to so many different activities? How will he ever get in the practice needed to excel at ANY of them? Or is this exposure time -- let him dip his feet into many different things for a few years and then select a couple to pursue?

Process or Competence?

These days I spend a lot of my time reading about process. More specifically, about "Agile" AND Cmm(I).

The context: I am in an org, managing the "QA" team (I, me and myself), and senior management is pulling in the direction of "process" ISO, and CMM(I). We are a software organization, and have been building software for over 5 years, 4 of which were without "process" and the last 1 where we dabbled in "Agile" with extremely uneven results.

Yes, we have a problem. The symptom is that our quality is not where it should be (or even close).

Here is where the disconnect begins. Senior management feels that the "Agile" process is not working and we should go back to a "more stable waterfall". In short, it is a process issue. *I* believe that no matter what the process, if there isn't a certain basic minimum competence at ALL levels of the software hierarchy, the quality of the software is doomed to failure. A competence issue.

Senior management acknowledges the competence issue, but believes that it can be resolved with training. On the other hand, I believe that training is an input that you give a smart mind get started and cannot be a replacement for lack of aptitude.

Is process a substitute for competence?