Please excuse my laziness, but I simply don't have time to respond to
each and every person who has E-mailed or left comments on digg, reddit,
or the original post itself. I would like to respond to a few of the larger themes
I've seen in the questions/responses:
This applies to more than just programming
I definitely agree that this can be applied to nearly any type of job,
not just programming. A great designer is worth much more than an
average one. And I honestly wasn't trying to single out sales and customer
service people. I do agree that a great sales person or customer service
rep is worth more than the average, and should be paid accordingly. And yes
every employee is important to the company.
Using customer service as an example, I've worked with the worst where
they would literally scream at the customer on the phone to the best. The
problem with customer service is that the metrics are against them in that
even the best customer service person can only take a few more calls/tickets
than the worst. Just because of the nature of the interactions. It is also
very difficult to measure if this person has pleased/retained more customers
than another. With programming it is often easier to see how an individuals
contributions impact the whole project.
Sales is a different monster, but hopefully this has cleared up what I was
trying to express.
Only experts?
Do I think it's reasonable to hire only experts? Yes, in many situations
a company can and should staff themselves with the vast majority being experts.
Is it possible for larger companies with larger products? Probably not. If
the problem simply demands 50 developers, it would be difficult to staff
that entirely with experts. However, I do believe they would see a boost if
they were able to have at least 10-15 of those developers be experts. Instead
most companies have 1-3 experts that lead the team of the masses.
If you can't find experts, you should attempt to hire staff that could become
experts over time as they gain experience.
How do you become an expert?
Everyone is correct in saying that experts started out as novices, I
was certainly a novice. In many ways I still am. Being personally interested
in martial arts I remember a story of someone, after years of training,
finally receiving their black belt in Aikido and being told, "Now you are
ready to learn." I believe this is true of programming, technology, and
most professions. The learning doesn't and shouldn't stop.
So how can you become an expert? I think the best advice I can give is to
read up as much as possible on your field. You don't become an expert
simply repeating what you did yesterday for many years until, poof, you're
an expert. You need to be learning new idioms, patterns, and tips from
your peers.
Too many developers sit in their cubes and pound out code and never look
up. You need to be reading up on your profession as much as possible, exploring
new languages/tools to determine if you could be doing something easier or
better.
An example of what I see far too often happened again recently at OSCON.
A professional Python developer did not know Django was the predominant
web framework for that language. I'm not a Python user, but even I know
this. Maybe it's because I'm friends with the core Django team, but even
if that had not been the case I would at least be aware of it and in
general what it was from my day to day tech reading.
The other advice I would give is to read and become involved in an Open
Source project. This improves your code quality and allows you to see
how other, presumably senior, developers work. Even if you aren't able
to contribute to the project directly, get on the mailing lists and
examine how those developers work.
How do you find and hire experts?
I think the biggest mistake managers make is leaving this up to HR. I've
always made sure I received every resume that came in for a position I
was hiring for. HR will often reject a candidate because their resume
states they have "Years of J2EE experience", but since it's a Java programming
position it goes in the trash. Perhaps it is time we start hiring "HR
Engineers" like we have "Sales Engineers."
The first place I look when hiring programmers is the Open Source community.
If they are involved in an Open Source project you can easily see how they
work with others on the mailing lists, see examples of their code, etc.
They also tend to be of higher quality because Open Source is a meritocracy.
Not to mention the simple act of being involved in a project, for no monetary
gain, shows a strong love of their craft.
I think multiple choice tests are a very poor indicator of programming
prowess. Too often they have a couple of esoteric or even trick questions
that really compare the test writers ability to confuse with the test takers'
ability to decipher. It is much more important for your new hire to know
how to find the answer than it is for him to actually have it tucked away
in a brain cell. Ability to effectively use Google to search for the answer
is much more important than many realize.
If you happen to be one of the people who are looking for an expert Perl
programmer I suggest you get in touch with my new friend Uri Guttman, The
Perl Hunter, at uri@perloncall.com. He specializes in finding execellent
Perl programmers for companies. Being an accomplished developer himself he
easily separates the wheat from the chaff and can find someone who will be
a good overall fit for your organization.
Many problems are marketing and management's
fault...
This is also very true. Bad management will bring down any team or project, no
matter how many experts they have on staff. This isn't even restricted to
technology management.
Marketing often over promises what can be delivered and demands it in an
unreasonable time frame. Unfortunately most of the time we blame the
developers, because long after the sale all that we see is the code and not
the brochure.
My advice to marketing and management is that you bring a problem to your
developers and then base your plans on when they believe they can deliver
the solution. Far too often management has already determined time lines and
set things in motion before the development team has even been told about
the project. This is backwards. You don't schedule your building contractors
before you have the proper permits or before even speaking with the architect
about the project.
Even Microsoft gets this right. They realized it was much better to delay Vista
until it is ready than to ship it too early just because they originally said
a certain date.
Obviously you can't always just wait around for something to be perfect.
There are always restrictions and requirements that are outside of your
control. No one could move January 1st, 2000 out a few more weeks just
because their Y2K cleanup wasn't done. But often I see companies attempt to
move mountains to hit some arbitrary date when one of the largest consequences
of delaying would be everyone had to update their Outlook calendars.
My language bias
I received a bunch of comments on my use of "Perl vs Java" in the
example, that simply was what we were talking about at dinner that night.
I probably should have used "agile language X vs cumbersome language Y" to
keep the flames down to a minimum.
You can write efficient, readable, and maintainable Perl. I've even had some
notable Python programmers say that about code I was in charge of and honestly
the code in question wasn't what I would consider the best of the best. I
think Python is a great language, but for me personally I haven't been shown
any compelling reason to switch.
You can write crappy unreadable code in any language. You can make most any language/framework/toolset scale and perform to your needs. For every
"large app/website/etc" that uses language X I'm sure I can find you a
comparable app/website using language Y. Any performance differences between
language X and Y can usually be solved with $100 worth of extra CPU. What
really matters is programmer efficiency. That is where you save money and
reap benefits. I simply don't see how having to write, read, troubleshoot,
and maintain 10x the number of lines of code is an efficient use of the
programmer's time.
However, I do agree that you should use the right tool for the right job.
Java/C++/C# are definitely the right tools in many situations. I just feel
that because everyone has seen a horribly written Perl CGI ( or written one
themselves ) they think this is somehow ingrained in the language and because
of this Perl simply isn't an option for anything "real."
Perl is a language where the developer must use some self-control rather than
having it imposed on him by his tool. Which is why Perl (or many of the more
agile languages such as PHP/Python/etc) written by novice programmers is so
awful. The knowledge and self-control comes with experience.
The largest problem with any language is the use of poor variable, function,
class, and method names. Using adequately long and descriptive names is
probably the single best way to improve code quality and no language out there
enforces this. Some enforce a certain style, others force certain
methodologies, but this is really only picking at less important aspects of the problem.
Company bias
By comparing Apple vs Microsoft I wasn't really singling out their
development staffs. I'm sure their management, design, and marketing
departments are as much to blame for any successes or failures these
companies have.
What I was trying to get across was the "It simply works." I would say
the second most common comment I hear from Mac users, after how pretty/well
designed they are, is that it "just works." I don't hear that very often
from Microsoft users.
. I highly recommend it for anyone who manages employees, but it makes two great points early on that are especially appropriate for technology managers:
Subscribe to feed