Hacker News new | ask | show | jobs
by kamaal 5286 days ago
The problem:

As it is mentioned in the email. People tend to believe, being great is about knowing a lot of facts and stuff from memory. Having information about stuff others don't know. While the fact is intelligence and knowledge only acts as catalyst in the path to success. They are not success or don't lead to success in themselves. Unless you don't understand this you will keep wondering why you are not getting successful while some guy you consider mediocre is winning.

What matters in real world is productivity. Ability to discover things quickly. Learn quickly. Learn to understand and properly state problems. Search for solutions quickly. And then use the best tools at disposal to build things in as little time with acceptable quality in the problem domain. Intelligence and knowledge of facts in this system at maximum fastens your rate of success nothing more nothing less. But yes practice helps. But practice in the right areas.

If you believe reading algorithm and data structures text books and searching for puzzles online will make you a good programmer, then I'm not sure. It may prepare you for interviews, it may also get you a job a bit web giant. It may make you look super intelligent in front of a panel or your team. But in terms of producing software for solving business problems, those facts from memory and even their practice at maximum serves as a catalyst not a crucial ingredient to success.

Apart from practicing writing programs. Learning API's, best practices, tools, techniques and your other usual day to day programming tasks. You also need to practice to be a better team player, you need to learn design, you need to learn customer interaction skills, you need to learn how to gather requirements.

You need to learn how to manage resources - time, money and people effectively. You need to learn effective ways of running software teams. The list goes endless.

Its no longer "Can write awesome code" == "Success". There are a gazillion parameters that will decide you success. And programming is just one of many of them.

Here is the shocker. You don't really a 1000 years of life to give 10 years to each. And even if you had a 1000 years of life you would be bored of giving 10 years to each and you would keep forgetting what you did decades back.

So, just be more productive and iterate your work endlessly. Find flaws and fix them. Do it in iterations. You will be taken care of.

4 comments

So, just be more productive and iterate your work endlessly. Find flaws and fix them. Do it in iterations. You will be taken care of.

I think, somewhere in there, you have to learn how to make sure you're taken care of, even if it's just learning how/when to ask for things you deserve for your efforts. Every workplace isn't a strict meritocracy.

"If you believe reading algorithm and data structures text books and searching for puzzles online will make you a good programmer, then I'm not sure. It may prepare you for interviews, it may also get you a job a bit web giant. It may make you look super intelligent in front of a panel or your team. But in terms of producing software for solving business problems, those facts from memory and even their practice at maximum serves as a catalyst not a crucial ingredient to success."

I call this the difference between being functionally and theoretically great. After finishing my undergraduate, it dawned on me that my education gave me a theoretical ability. Outside the classroom application is what yields functional ability.

"So, just be more productive and iterate your work endlessly. Find flaws and fix them. Do it in iterations. You will be taken care of."

Absolutely agree here too, refinement I think is a big factor to success.

Great post. Reminds of a recent interview I had. After we discussed my resume and a myriad of topics on tech, software, time management, and people the interviewer gave me a programming problem to solve in order to get a second interview. I asked about gotcha questions or if I was going to need to code with someone staring over my shoulder and he said that none of his employees would ever code that way while working there so what would that test?

It makes complete sense. So what if someone can answer how many ping pong balls are in a school bus, if they can't produce or get along with the team they will not be a good hire (unless of course the job is figuring out how many ping pong balls are in a school bus).

This sounds a lot like Joel's Duct Tape Programmer: http://www.joelonsoftware.com/items/2009/09/23.html