Do you see any common traits among the rockstars?

Did you see any common traits among the rock stars you interviewed? If so what were the top 3 traits? I would imagine passion and Commitment would be one of them. How about being creative?

@Arul,

Oh...though Ed would be the best to answer this, I just wanted to share my opinion!

According to me, the following 3 would distinctly identify rock stars

1. Creativity.
2. Simple but effective way of approach.
3. Out of the box thinking.

Today, technically everyone can get himself/herself equipped, but thinking capacity and logic should be from within.

Waiting to hear what Ed has got to say.

I agree with Ramaswamy, but I would put out of the box thinking on the top of the list. I would really love to see Ed's answer on that

Hello Aruk,

Alaa hit some big ones, and I don't want to give too much away here but...

Knowing when to walk away from the keyboard

Strong mastery of computer science fundamentals

First-person network of other top-notch programmers

Ability to know what questions to ask

Ability to ask them.

Ed

Thanks Ed.

Do you think some of these traits are intrinsic? Can these traits be developed and cultivated? If the answer is yes, do you cover this in your book as to how one could develop these traits?

It is always inspiring to learn from the successful people. It is a very good idea to come up with such a book that is different and all the best with the book promotion.
[ March 25, 2008: Message edited by: arulk pillai ]

Ed in your answer i am unable to get the following 2 points, can you please explain me again?

Knowing when to walk away from the keyboard

First-person network of other top-notch programmers

Originally posted by Abdul Kader:
Ed in your answer i am unable to get the following 2 points, can you please explain me again?

I believe I can answer this. I'll start with the second one' since it's easier. Your first-person network consists of the people you directly know, so having a first-person network of other top-notch programmers, means knowing top-notch programmers directly in person, and being able to contact them directly.

As for knowing when to leave the keyboard, it implies a lot of things. You should leave the keyboard when you get what you want, and not just keep adding unneeded features causing an unneeded clutter of code for no reason just because you think that those features are nice to have.

You should leave the keyboard when you face a problem that needs for you to stop for a while to make a good design to approach this problem as efficiently as possible, and don't just complete your coding directly to solve the problem which may cause you a lot more trouble.

You should leave the keyboard when you are tired and can't concentrate, which would lead you to write unreadable buggy code, that you won't know why you wrote it in the first place.

Finally, you should leave the keyboard when your post reply gets too large, take the mouse, click on a smiley face and click on the "Add Reply" button

Originally posted by Ed Burns:
Hello Aruk,

Alaa hit some big ones, and I don't want to give too much away here but...

Knowing when to walk away from the keyboard

Ed

I like this one the best.

Originally posted by Alaa Nassef:

You should leave the keyboard when you face a problem that needs for you to stop for a while to make a good design to approach this problem as efficiently as possible, and don't just complete your coding directly to solve the problem which may cause you a lot more trouble.

You should leave the keyboard when you are tired and can't concentrate, which would lead you to write unreadable buggy code, that you won't know why you wrote it in the first place.

That's something I've learned first hand in the last months - often the best solution to a problem is to stopp thinking about it and go to sleep. The idea that solves the problem will come to you when it's time for it (assuming that beforehand you did the job of analyzing it properly) - to me, that's often under the shower the next morning.

I've once heard the term "Contemplative Programming" used for this approach, which I think is highly appropriate (and surprisingly effective).

There is a great interview with Linda Rising at http://www.infoq.com/interviews/linda-rising-agile-bonobos where she also talks a bit about why and how this works.

Originally posted by Ilja Preuss:

That's something I've learned first hand in the last months - often the best solution to a problem is to stopp thinking about it and go to sleep. The idea that solves the problem will come to you when it's time for it (assuming that beforehand you did the job of analyzing it properly) - to me, that's often under the shower the next morning.

I've once heard the term "Contemplative Programming" used for this approach, which I think is highly appropriate (and surprisingly effective).

There is a great interview with Linda Rising at http://www.infoq.com/interviews/linda-rising-agile-bonobos where she also talks a bit about why and how this works.

Yup. The really creative solutions to problems cannot be forced. They'll emerge in their own sweet time. An eternally vexing matter to the executives that think that if you just turn the handle a little faster and a little longer, the solution will pop out like another pound of hamburger.

Totally agree with "stop to think". Also I want to add that sometimes the best solution for a problem is not to write code

(maybe is already solved, or there's an easy alternative, or you can approach it in a different way, etc)

Totally agree with "stop to think". Also I want to add that sometimes the best solution for a problem is not to write code

Totally agree and that is why it is vital to look at the "Big Picture"

maybe is already solved, or there's an easy alternative, or you can approach it in a different way, etc

Also some problems/issues can be simplified or solved by changing the business process itself.

there's an easy alternative - The detailed design documents should always analyse pros and cons of number of alternative solutions and the reasons for the recommended solution.

Originally posted by arulk pillai:

there's an easy alternative - The detailed design documents should always analyse pros and cons of number of alternative solutions and the reasons for the recommended solution.

That's what's recommended by standard software engineering procedures, but the problem is that lots of companies don't apply them. As Tim so elegantly put it:

An eternally vexing matter to the executives that think that if you just turn the handle a little faster and a little longer, the solution will pop out like another pound of hamburger.

I really loved that expression

there's an easy alternative - The detailed design documents should always analyse pros and cons of number of alternative solutions and the reasons for the recommended solution.

@Arul,

I absolutely agree with that point! One should definitely make a detailed design before he can proceed to write some code. The learning part lies actually in the design. Alas, unfortunately, as Alaa points out, most of the companies do not abide by these documentation.

Actually, we can take one more approach! There's something called thinking aloud. One can follow this approach.

There's another thing...that I loved and it has worked for me, many times. Talk about the problem....either to yourself, better done, with your pals. That actually invites more ways, rather interesting ones to solve it!!

Originally posted by Gabriel Claramunt:
Also I want to add that sometimes the best solution for a problem is not to write code

Yes. And I would even take that a step further - we shouldn't see ourselves as selling software, but as selling solutions. And not always the best solution is software.

I'm reminded of a story of a software development team - I don't remember what kind of software they developed, but it was a project for a client that would use it on a couple of workstations.

One of the (later emerging) requirements was that the users had to do some simple ad hoc calculations. The team decided that the best solution would be to install a hardware pocket calculator at each workstation. The users were pleased. As was the customer - it was a very cost effective solution, too.

Originally posted by Ilja Preuss:

The team decided that the best solution would be to install a hardware pocket calculator at each workstation. The users were pleased. As was the customer - it was a very cost effective solution, too.

This one always kills me. I see people grab for their calculators all the time while sitting in front of a computer.

I press the "Window key", select "Program/Run", enter "calc" and hit enter. Presto, a calculator pops up on the screen and I can even paste the results into whatever document needs it. No batteries required.

Of course, since this is the Microsoft calculator, I do occasionally have to verify that it's giving the correct answer.

Originally posted by Tim Holloway:

This one always kills me. I see people grab for their calculators all the time while sitting in front of a computer.

I press the "Window key", select "Program/Run", enter "calc" and hit enter. Presto, a calculator pops up on the screen and I can even paste the results into whatever document needs it. No batteries required.

Grabbing a calculator may still seem easier to some people. Another advantage is that it doesn't take up screen space. And you are certainly aware of solar-powered calculators?

Mind you, I'm not arguing that hardware calculators are always the better alternative. But we need to take a close look at the context.

Yes. And I would even take that a step further - we shouldn't see ourselves as selling software, but as selling solutions. And not always the best solution is software.

I'm reminded of a story of a software development team ...

I'm also reminded of a tale from a group of code gorillas:
Would you sell your software to your friends or a company where your friends work?

Aloha,
Doug

-- Nothing is impossible if I'mPossible

why installing a hardware calculator is a best solutions, as it will costing more...

Why can't they teach users how use calculators in Computers, that will also solve the issues right..

I am sorry i not very clear with the discussion about installing calculator, if i was wrong please correct me

Originally posted by Mohammed Yousuff:
Why can't they teach users how use calculators in Computers, that will also solve the issues right..

I don't think DOS had a calculator, and there were still plenty of people running DOS without Windows a short 15 years ago.

Originally posted by Mohammed Yousuff:
why installing a hardware calculator is a best solutions, as it will costing more...

I don't remember the exact situation, but I'm sure they calculated that installing the hardware calculators was in fact less costly than installing a software solution on this specific platform.

Also, hardware calculators being so cheap, it may well have been less expensive to ship one with each copy of the software, than to explain to even just a handful of people who don't know how to use the software calculator how to do so...