SING as if no one is listening
DANCE as if no one is watching
LOVE as you've never loved before
LIVE as if heaven is here on earth
Search This Blog
Monday, August 27, 2007
Sunday, August 26, 2007
Quotation
Telling the future by looking at the past assumes that conditions remain constant.
This is like driving a car by looking in the rearview mirror. - Herb Brody
Experience is a comb which nature gives to men when they are bald.
Minds are like parachutes; they work best when open. - Lord Thomas Dewar
Experience is a dim lamp, which only lights the one who bears it. - Louis Ferdinand
This is like driving a car by looking in the rearview mirror. - Herb Brody
Experience is a comb which nature gives to men when they are bald.
Minds are like parachutes; they work best when open. - Lord Thomas Dewar
Experience is a dim lamp, which only lights the one who bears it. - Louis Ferdinand
Friday, August 10, 2007
Quotation
Dream - is not what you see in sleep ...
....is the thing which does not let you sleep !!!!
....is the thing which does not let you sleep !!!!
Tuesday, August 07, 2007
Hiring Programmers and The High Cost of Low Quality
Why is it so hard to find good programmers?
The simplest reason is when a company finds a good developer they do more to make sure that person is happy which leads to longer tenures. Better salary, more flexible working conditions, good tools, interesting projects, and better perks can often keep a programmer working for you longer.
Another obvious reason is that experts in any field are small in number, so your possible talent pool is limited. This leads managers and HR departments to settle for average or even below average developers. I believe this is the single biggest mistake a technology oriented company can make, regarding developers, just short of not using a good version control system.
We're not talking about customer service representatives or sales people here. Just having a body to fill the seat is not, I repeat not, always a win for the company. Sub-standard programmers drag down the efficiency of your other developers with beginner questions, poor comments/documentation, and bad code that someone else will later be forced to spend time fixing.
Companies need to stop thinking about their developers as cogs in the machine. They are more akin to artists, authors, designers, architects, scientists, or CEOs. Would your HR department rush to find the first person who would willing to take on the role of Chief Scientist, Art Director, or CEO in your company? Of course not, they would spend the time to do a through talent search for just the right candidate, court them, and then compensate them appropriately. They realize that having the wrong person in that seat is much worse than having the seat empty. It is absolutely the same with programming.
Anyone who has been a developer or managed developers can tell you that an expert can accomplish as much as 10 average developers. However, companies typically pay only a 10-20% premium for an expert over the average programmer. Whether or not their title is Lead, Architect, Development Manager, Guru or whatever nomenclature the company uses. I am not saying that if your average developer is paid $50k/year that you should pony up $500k/year for an expert. The employer/employee relationship never works like that, but what employers don't seem to realize is that in the end paying more saves them more.
What is an expert programmer?
Experience is key, but not necessarily in ways you might imagine. Time in the saddle, with a particular language is not as important as diversity of experience. Someone who has worked in several disparate industries, a generalist, is often a much better developer than one who has spent years in the same industry. There are exceptions to this, but in general I have found this to be the case.
Experts use better tools and care deeply about their craft. They aren't assembling bits on an assembly line, they are crafting a unique product to solve a unique problem. Experts are lazy, they work smarter rather than harder. Experts prefer the easiest solution that gets the job done. Experts aren't interested in creating complex solutions simply to have the complexity, that misguided egoism is the territory of more junior developers. They often get it right the first try and almost always on the second one.
The simplest reason is when a company finds a good developer they do more to make sure that person is happy which leads to longer tenures. Better salary, more flexible working conditions, good tools, interesting projects, and better perks can often keep a programmer working for you longer.
Another obvious reason is that experts in any field are small in number, so your possible talent pool is limited. This leads managers and HR departments to settle for average or even below average developers. I believe this is the single biggest mistake a technology oriented company can make, regarding developers, just short of not using a good version control system.
We're not talking about customer service representatives or sales people here. Just having a body to fill the seat is not, I repeat not, always a win for the company. Sub-standard programmers drag down the efficiency of your other developers with beginner questions, poor comments/documentation, and bad code that someone else will later be forced to spend time fixing.
Companies need to stop thinking about their developers as cogs in the machine. They are more akin to artists, authors, designers, architects, scientists, or CEOs. Would your HR department rush to find the first person who would willing to take on the role of Chief Scientist, Art Director, or CEO in your company? Of course not, they would spend the time to do a through talent search for just the right candidate, court them, and then compensate them appropriately. They realize that having the wrong person in that seat is much worse than having the seat empty. It is absolutely the same with programming.
Anyone who has been a developer or managed developers can tell you that an expert can accomplish as much as 10 average developers. However, companies typically pay only a 10-20% premium for an expert over the average programmer. Whether or not their title is Lead, Architect, Development Manager, Guru or whatever nomenclature the company uses. I am not saying that if your average developer is paid $50k/year that you should pony up $500k/year for an expert. The employer/employee relationship never works like that, but what employers don't seem to realize is that in the end paying more saves them more.
What is an expert programmer?
Experience is key, but not necessarily in ways you might imagine. Time in the saddle, with a particular language is not as important as diversity of experience. Someone who has worked in several disparate industries, a generalist, is often a much better developer than one who has spent years in the same industry. There are exceptions to this, but in general I have found this to be the case.
Experts use better tools and care deeply about their craft. They aren't assembling bits on an assembly line, they are crafting a unique product to solve a unique problem. Experts are lazy, they work smarter rather than harder. Experts prefer the easiest solution that gets the job done. Experts aren't interested in creating complex solutions simply to have the complexity, that misguided egoism is the territory of more junior developers. They often get it right the first try and almost always on the second one.
Friday, August 03, 2007
Quotation
If you cant convince them, confuse them :)))
Never argue with a fool, people might not know the difference !!
Never argue with a fool, people might not know the difference !!
Desirable Difficulty
If students don't test themselves when they read a chapter, they can easily think they know the material when they don't. When you test yourself as you study, you may feel like you're making it harder on yourself, but on the test, you will do much better. This can be termed 'desirable difficulty'. If you want to learn something well, when you're reading, stop and think about what you've read, and test yourself; you learn by testing yourself. If you make it more difficult for yourself while you study, you feel like you're doing worse, but you're learning more..
Subscribe to:
Posts (Atom)