Slashdot Mirror
Hiring Programmers and The High Cost of Low Quality
An anonymous reader writes "Why is it so hard to find good programmers? And why should companies favor hiring fewer more senior developers rather than many junior ones? Frank Wiles discusses his thoughts in his article A Guide to Hiring Programmers: The High Cost of Low Quality"
FTA: ...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. Bonus points if your developer was a systems administrator in a former life.
Some of the best developers I know were originally trained as journalists, mathmaticians, linguists, and other professions not normally associated with software development...
As a generalist programmer, originally trained in cognitive science, who has formerly worked in several disparate industries, was a systems administrator, programs in half a dozen languages (including perl), etc, etc...Apparently I'm supposed to be making twice my salary. Goddamnit!
*stomps off in search of his boss*
These days, being a programmer generalist (even worse, one with admin experience) just increases the types of shit that get dumped on you...Where they might have had to hire a person to do the front end GUI code, a person to do the database work, a person to set up the server, and a person to code all the services that need to constantly run in the back end, instead, since they've got you, you can do it all, while the specialists sit around drinking coffee and making catty comments about how much better they are at what they do than you are.
My advice is specialize in something to the point where when you do any work on it, it's immediately out of the comprehension of a generalist or a less accomplished programmer...Sure, everyone will hate you, but they'll have to deal with you, and you'll be in a position to dictate terms. What's a generalist got? They're great employees. Big deal. Being a great employee is like being a great dog; at the end of the day, they'll still euthanize your ass when you're no longer of use.
//Not bitter or anything.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
... produces crap. Good programmers are not cheap, people that want to hire them are.
This article looks like it was written by a perl programmer.
What to 'work' from home... check
flexible working hour... check
make sure perl is mentioned often... check
higher better people for more money and you save money... check
I like the last one but it has to be justified. The programmer better be worth the 90, 100, 120K a year to be paid it.
that is all.
I'm a senior software developer in my company with roughyl 15 years worth of experience and a CS degree under my belt. The newer developers are either mechnical or electrical engineers who learned to program with a book in one hand and a keyboard in the other OR they're right out of college waiting for their CS diploma to be mailed. I find that although they have a great understanding of the languages we use they have very little grasp of design patterns and architectures. Stuff like that can only come from experience and knowing what works well given the scenerio. I find that when left on their own they simply are incapable of coming up with an effective architecture...or I should say anything beyond the obvious 3-Tiered approach. I'm at a point where I design our software systems and hand them off to the less experienced developers. I would prefer we trade in several of them for one more seasoned veteran since they will be in a better position to come up with simpler and more powerful designs that require less coding. My two cents
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.
This guy should be ready to put his money where his mouth is: If there really is such a thing as the über-programmer, who is literally 10 times more efficient than his average [median] colleague, THEN BY ALL MEANS he ought to be paid 10 times as much in salary - maybe even more.
The very fact that such disparities in salary don't exist means that either the über-programmer does not exist, or else there is something so screwy about the internal politics of corporations that the suits in management won't stand for some dweeb hax0r making ten times their salaries.
But I think that if the über-programmer really does exist, then eventually the free market will figure that out, and compensate him accordingly.
Same concept goes with my job field, I spend a considerable amount of time consulting, fixing poorly configured networks and servers. You cant just grab a joe off the street and expect him to be a professional or put out professional work without having learned his/her lessons, they will make mistakes learning, do you want it to be on your buck and your network?
CS: It is all sink or swim...oh and did I mention there are sharks in that water?
How I wish this were true. I consider myself to be a good programmer, I work in a small company that provides software to credit unions. We do the complete package, teller systems, ATM interfaces, online banking, etc. Three of us work here. Our entire system works well with two programmers and one tech support guy. We support 18 credit unions. Our problem is that with only 3 people it is based on a legacy code base that has grown over the years. It is all in COBOL with a little other stuff thrown in when COBOL won't work.
I am ready for a change and work in a city with lots of bank and insurance headquarters. Everyone wants J2EE or
I am studying to get
Hope my boss doesn't read this article and get any crazy ideas. I'm one of those newb developers, we deserve a shot...right?
One aspect not discussed: Programmers are in short supply because demand for code and new features is limitless.
My company right now has huge demands for new features and new software. While development is desperately trying to fight the urge to pump out more and more features, they fail miserably each cycle. This is coupled with the fact that we have tons of work to do cleaning up bugs. No one can stop and catch their breath, the work keeps piling on.
This cycle will continue until a customer realizes they can't get something on time, or the quality is so bad the software won't sell any more. Customers think the software just materializes because they see it on the shelf. It took years to get it that way.
Salesreps do and say anything to get the contract signed, and the details get ironed out later. As long as the cash rolls in, large companies aren't going to change this.
"All great wisdom is contained in .signature files"
Was to the 400 disc CD Changer.
Seriously, we knew ALL of this a long time ago. HR just has yet to catch up- they'd rather hire 100 slightly-less-than-competent people who have the right keywords on their resume than a single lazy generalist who will figure out the right way to code it the first time regardless of how new they are to the language. And it's the second one you want. The real bottleneck isn't finding expert programmers- it's finding HR people who understand this industry.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
hiring more people is better then over working the people that you have.
Having 2 people working 40h a week each is better then one person working 80h a week.
COBOL is not really a programming language, thus the reason it is dying. I know I am being a snob, but the quality that makes COBOL great (eg anyone can write and become an expert), is also the quality that makes the devs go back to college to learn the complexities of PHP or another object orientated language. I learned C++ initially and ended up moving to Java and Perl and indeed it was a simple switch. Of course now I have discarded all and become a SysAdmin :)
CS: It is all sink or swim...oh and did I mention there are sharks in that water?
Why is it so hard to find good programmers?
Who says it is? If that is true, maybe the flood of H1B visas isn't having the positive effect that proponents insisted that it would. Gee, maybe we should stop the ongoing decimation of our domestic workforce by corrupt trade practices. That would be a start.
More to the point, why should software developers be any different than, say, car mechanics, doctors, scientists, lawyers, musicians or anyone else? Being truly competent (much less exceptional) in any complex field is a fortuitous combination of training, experience and talent. Time and money provide the first two, and can produce at best a merely competent worker. Being the very best requires actual talent, but talent is a rarity in any area of human endeavor. That's why the top people in any sophisticated profession command top dollar.
Or used to, at any rate.
The higher the technology, the sharper that two-edged sword.
It's simple. They don't pay enough. They can't. If a programmer at my age, qualification and expertise was paid a proportionately
fitting aount I would earn 5 to 10 times that of senior management. No company will ever allow an employee to earn more than the guy that 'manages' him. Therefore the only career development path for most very good programmers and computer scientists is to move into management, at which point
their brains stagnate and they lose their killer skills.
Being an excellent programmer isn't just about learning a bunch of stuff once. It's about living and breathing your art, reading new material every day and constantly bettering yourself. It's knowing software and hardware engineeing inside out, from transistor to register to pointer to array to
network packet to distributed system. After about 15 or 20 years you have surpassed everyone you will ever hope to work for. You must accept some kind of 'revolution of lower expectations' where you know you will never be paid what you are worth. Unfortunately some people take the attitude that guys who are approaching 40 and still programing as losers, because why would anybody *choose* to remain a programmer and not move up to management?
There is simply no widespread understanding of how far a person can take a career in programming and how deep the rabbit hole goes. After the first 20 languages and reading all three volumes of Knuth from cover to cover, maybe you write a few of your own compilers and maybe write another little 'hobby' language. By that time the only peers you can hope to meet are other older programmers who have taken the same path. Nobody within a company/corporation is even qualified to judge your capabilities.
Yet you can find yourself applying for 'entry level' positions in companies because you don't have specific experience of some shitty little proprietry tool that you could write yourself if you were bothered to.
There is no shortage of good programmers. It is bullshit put about by industry who can't express what they really mean. What they want to say is "there aren't enough young cheap programmers around, and all the good guys we had became managers and cant code to save their lives any more because we couldn't actually pay them what they are worth to us".
Industry is a inverted meritocracy. It's frankly how embarrasing how much more valuable a good programmer is than a good manager. Until the corporations can get over their snobbery and stop clinging to a 20th century worker/management model that encourages the best programmers to abandon their field at the moment of greatest maturity they will always be losing out on having the best and brightest actualy realise their potential.
Am I the only one who is surprised that the author didn't leave a link to his resume at the end of the article? I see the entire article as flamebait. Or maybe I'm just biased because I'm one of those "junior programmers" fresh out of college who uses "less agile" languages such as C++ and Java. Only difference is that I didn't receive my diploma in the mail...
Congratulations, you have completely missed the point.
Suppose you instead took the time to find 5 expert, or at least above average, Perl developers at $120k each per year. That seems to be the gist of the article, and it's a pretty reasonable conclusion: Experts can be very much more productive than non-experts.
However, it is also my experience that it isn't always easy to tell highly capable people from the merely capable; that is, I've worked with people who seemed very good initially, but in the fullness of time I realised they were not. And that, of course, is a benefit for having 15 developers instead of five: Any given hiring mistake costs half as much, and reduces your workforce by a fifteenth instead of a fifth.
So how are you supposed to find these expert programmers, and how can you tell a $60k developer from a $120k developer? By asking brain teasers like Microsoft and Google are reputed to do?
Just my $0.02
"Goodness me, how unlike the FBI to abuse the trust of the American public." -- The Onion
most coding/programming tasks are menial and don't require much creativity. in fact I would say the vast majority of programming work is maintenance type works/simple things that doesn't require that much skill. thats why anyone with a HS diploma can pickup a programming book and learn how to program in a couple of days. i think what makes the difference is the architect of the project--the guy who lays out the foundation of a project. maybe if the task is like writing a 3d engine from scratch you need and uber-programmer but even at game companies (where I've worked before) we just license the engine and even avg programmers can make a cool game.
If there really is such a thing as the über-programmer, who is literally 10 times more efficient than his average [median] colleague, THEN BY ALL MEANS he ought to be paid 10 times as much in salary - maybe even more.
That's not how free markets work. Most importantly, compensation isn't proportional to value. In addition, there are plenty of inefficiencies in the labor market, including incomplete information, as well as other risks and costs that limit compensation.
In the presence of perfect information, all you can really say is that a better programmer should get paid more, but it may just be a small amount. In the absence of perfect information, it's impossible even to say that: more skilled or valuable programmers may end up getting paid less than less skilled or valuable ones.
In fact, I have worked at companies where clearly compensation was inversely related to experience. How do I know? Because the economy was such that starting salaries were rising faster than senior developer salaries. Yet, senior developers stayed because the cost of switching jobs (retirement plan, stock options, etc.) was higher than the difference in compensation.
The people out in the market place can be amazing. We were recently looking for more people, but watching the people come through was kinda fun. We are a small shop, now at 4 programmers. As you can guess, we don't get the high end people applying directly to us like they might to MS or Google or whatever. We have to go find people and attract them. We do get some submissions, but they tend to be.... interesting.
We have seen... the passable, those who are rediculously overqualified (if you read their resume, but you can tell they are lying about 90% of it), the guy who (as a programmer for 5+ years) didn't know what an array was, the people who's last job shoved them into one tiny area for years and years so they have lost skills outside of that small set (which is often esoteric). We've seen those just out of school that need more experience, and those with great experience who just want too much (salaries the larger companies around would have paid a few years ago when the market was better, but they have no chance with in our company for the position they are being hired for).
It can be hard to find good people when you aren't a Google or MS.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
As a recently graduated CS student, I find this type of thinking to be incredibly infuriating at times. Companies only want to hire people with experience. Yet to gain this experience, I need a job. The circular logic goes round and round until you have a brain aneurism.
My college never stressed learning any one language well. Rather, it taught us the tools and techniques we would need to survive in the ever-changing world of software development. Yet none of this seems to count for anything. No past experience with a company? Goodbye. The fact of the matter is, I need to start somewhere. Right now I'm sitting at a job that I feel doesn't tap my abilities, yet I put up with it for the "experience." The number of opportunities for fresh graduates are few and far between, and you have to take what you can get.
"Now I'm seriously serious!" - Serious Sam
Everyone knew that programmers are unique. Each programmer has his own style and own way of solving problems- which invariably have several solutions. As a result, if you hire lots of people working on the same thing, unless they are experienced as working as a team with the particular people they are working with, there will be lots of translation problems and it'll take a long time to get that understanding. If you hire a few people and they work closely together they can work as a team, understand each other, and over time develop understanding.
Your comparison seems to be of people of the same level. Two new grads vs. one new grad, or two seniors vs. one senior. To change your original scenario, would you rather hire two recent grads at $50k, or one senior level worker at $125k? It is $25k cheaper to hire two recent grads...but when you put them together, do you get the quality of a senior level worker with say 8 years of experience? Probably not. The one senior level guy might work 50 hours a week, but he probably does more than two recent grads 3 months out of college working 40 hours.
Then again, I didn't RTFA, just other comments.
The New York Yankees have the highest payroll in baseball by far. $195,229,045 according to ESPN. $52,105,331 more than second place (Boston) and $112,176,945 higher than average. Yet their current record is 62-50, 6.5 games back from Boston. Even the lowly Arizona Diamondbacks have a better record of 63-50 with a payroll of only $52,067,546.
Baseball and programming might not be exactly alike. But look at it this way: The most "talented" individuals in baseball get the most money - yet all that talent pooled doesn't result in the super team that this guy is dreaming about. In baseball, it's fairly easy to measure past performance. Stats up the wazoo, in addition to recordings of their job performance that are easily available. But programmers aren't that way at all. Even if you try your best, filter like crazy, do interview after interview after interview, test after test, you may be getting a complete dud - shows up to work day #1 drunk and starts to watch graphic pr0n.
HR could work from now until the end of time trying to find the perfect fit. They could spend a billion dollars per employee trying to find the best. But that's still no guarantee that you'll get what you're looking for. Usually, you can't know the quality of the service until at least the start of when it's being rendered - and often times not until many years later.
The reason good programmers are so hard to come by is because colleges aren't really putting out good programmers. In the past, colleges were much more concerned with teaching the elements of one particular language, and then allowing you to transition between different languages. Nowadays, schools don't want to teach one particular language for fear of their students being labeled and losing opportunities because they went to a "Java" or a "C++" school. When I went to school (which I only graduated a few months ago), the professors refused to go in depth about any particular language so, in essence, we learned overall generalization about programming, data structures, algorithms, etc., but we never really learned any one language thoroughly. Many of my friends from other schools experienced the exact same thing.
The article would be interesting it if weren't an extended whine about how programmers should be paid more and treated like prima donnas.
When someone truly figures out how to take a group of beginning programmers and make them able to create something that a complex single programmer could create, then that will be the end of high paying jobs for computer science. At that point, programming jobs will be kinda like jobs at Taco Bell.
-- Betting on the survival of the media industry is a serious risk. I advise investing elsewhere.
...the mythical man-month?
>why should companies favor hiring fewer more senior developers rather than many junior ones?
*swish*
Hiring 1 person that works 40 hrs/week is better than hiring 5 people that work 40 hrs/week and produce the same results.
Actually Hiring two people who enjoy development and do work well is way better than having 10 non interested developers.
// i thinks
By some estimates, Good Programmers can be a factor of ten or more productive than Bad Programmers, yet they are seldom paid more than a few tens of % higher. It would be far better for most companies to pay double the going salary to attract only the best, but unfortunately business thinking does not seem to be structured that way.
Most organisations base their planning on some convenient notions like programmer-months etc, using some standardised measure for programmer capability. These measures are great because they make the spreadsheets look neat and tidy. They also make all the outsourcing logic work: "I can get programmers in country xxx for $10 per hour". Untimately they are flawed because you get what you measure. If you don't pay a premium for good programmers you won't get them. You end up spending mucch more on crappy programmers.
Engineering is the art of compromise.
Other that that, this looks like some decent advice.
Why I was still in university, I used to read stuff like from this article and be impressed! ... well, it just something that sound nice ... it just soooo misleading!
... its a job like many
that required education and experience, how odd? and all this time I thought that any one
who read "thinking in java" can truely think in java, just like that, no work experience required!
Now that I've worked for a while, I am thinking
probably help few ppl feel better about themselves but
Of course it better to hire few experienced (probably senior) workers, that few inexperienced ones! why should it be otherwise, its not like its a job of waiting tables
now I am enlightened!
and why is it hard to hire programmers! i mean is it to assume that someone like Linus Torvald or Larry Wall or Audrey Tang... or anyone who got a real work experience working for any of the many real companies that created real software that you could try urself would be at least good enough!
can't u formulate a decent C# or Java exam to filter your candidate, would 3 or 4 interviews expose the wannabes, I mean comme on! Just ask him to explain the code of a real application he wrote, how hard is that!!!
See The Market for Lemons. The existence of tons of bad programmers, and the inability of employers to tell them apart from good ones, drives the salaries of all programmers towards that of the average programmer.
Are you adequate?
Domain knowledge is the primary difference between a 1 day LOE and a 1 week LOE, not programming "skill".
There is no class of general "uber" programmer that can be brought on to an arbitrary company's internal development project and hit the ground running at a pace 10 or even 2 times that of the standard-fare developers already on the project. This is a complete myth.
However, the domain knowledge gap can in most cases be narrowed very cost effectively through knowledge transfer, training, and tools.
If you skimp on resourcing and experience anywhere in your development organization, it should be on programmers. Inexperienced and unskilled programmers can be compensated for effectively through targeted specification, management, and quality assurance processes. The key is to have processes in place to identify and rectify programmer failure early and often.
Computer programming isn't rocket science, it's bridge building. You have planners and you have builders. Builders pour cement and put rivets in place, and there are processes in place to identify, rectify, and robustly handle individual builder error. Bridges do not arbitrarily drop cars off into the river below due to individual builder error, and neither should software programs crash due to individual programmer error.
I'm going to take advice on hiring programmers from a Perl cool-aid drinker. Sure, just the very minute I get my brain replaced with a cauliflower. Perl is an horrifically bad language. It's called "write-only" for a reason. It makes great programmers produce merely adequate code, makes good programmers produce bad code, and makes bad programmers think they're great. Feh. A properly trained, incentivized and provisioned Java team can run rings around a Perl team in terms of working code produced, as well as (more importantly) cost to develop and cost to maintain.
We want to hire ability. That's not necessarily experience. There may be some relationship between the two, but it's lazy hiring to rely on experience. As we all know, there are plenty of people who have been programming for 20 years but still can't code for shit.
I'd hire you as a fairly inexperienced developer if you could demonstrate that you had great ability. You wouldn't get that huge salary at first however - sorry, you need experience and ability for that!
Unfortunately, it's very difficult to hire based on ability. How do you test for it? We've tried all sorts of stuff. In the end it comes down to good questioning, having the candidate hack out pseudo-code on the spot, and having them participate in a small design workshop. But we find that candidates don't really want to go through a long hiring process with us as we're a small company. It's still an error-prone process.
But I agree with TFA. I'd rather have 4 great programmers at $160K than 8 mediocre ones at $80K, or even less. The two major problems to hiring this way are:
Having worked in IT, as a programmer, and now as an architect I think pretty much any field is the same, not just programming. Some people are just worth a lot more because in general, the average person spends more time avoiding work than doing work. I don't think the premise of the article applies just to developers.
In a market with perfect information, by all means, yes. In a market where buyers don't have perfect information, however, irrational stuff happens.
There's also another potential flaw in your logic: failing to account for risk. If you hire one über-developer to do all your work, you're screwed if a bus hits the guy. Hiring 10 mediocre guys instead diversifies away a number of risks. A riskier asset must sell at a steeper discount of the profit that you hope to make out of it, compared to a safer one. (None of this is to imply that the IT jobs market is pricing risks correctly, however.)
Are you adequate?
1) I got bored. Too may clients were happy to give me 4-8hrs of work per week because (and this is an _EXACT_ quite) "you do more work in 2 to 3 hours than most of my team does in a week"
2) Being on-call 24x7 with no additional pay. Plus, being written up for not answering a page at 2am -- after I emailed my manager warning her that I had a tendency to sleep through everything. That email prevented me from being fired on the spot!
3) Having a manager that was so threatened by me that he tried to get me fired. 4) Hey, If I do more work in 1/2 day than others do in a week, why don't I get paid AT LEAST 2x the rate of those idiots?!?
5) Too many hours of (unpaid) overtime because others on the team aren't performing (see #1). And then getting criticized for working overtime (see #1)
6)
Enough complaining. I'm going OUTSIDE with my GIRLFRIEND to play with rocks.
The surprising thing about this is the Perl mania. Perl is OK for little stuff. But if you're writing stuff in Perl that's complex enough to require hiring multiple programmers, you're probably using the wrong language. Maintainability in Perl is a big problem. The language is hard to read, and the "there's more than one way to do it" philosophy means that code written by different programmers tends to use different subsets of the language. I have three Perl books, including Larry Wall's, each of which describes a different subset of the language, which gives a sense of how bad that problem is. On the other hand, Perl comes closer to "write once, run everywhere" than anything else around. Your Perl web app will probably work the same on almost all hosting providers.
I once wrote a sizable app in object-oriented Perl, and wouldn't do that again. Python scales better.
Python as a language is quite good, especially if you need roughly Perl's function set. The main problem with Python is that the C libraries for key functions (SSL, databases) are maintained by different groups, often by a single person, aren't part of the main Python distro, and don't sync well with Python releases. You may have to explain to your manager that the Windows distribution of the SSL library for Python is maintained by a World of Warcraft guild and they can't fix it this week because they have a big raid coming up.
As a recently graduated CS student, I find this type of thinking to be incredibly infuriating at times. Companies only want to hire people with experience. Yet to gain this experience, I need a job. The circular logic goes round and round until you have a brain aneurism.
You need to pay your dues after college. You need to work some crappy job and when someone asks for some code you produce it! You need to work for some crappy mom n' pop store and write them a better inventory system. you need to write a program to make something easier in your life and give it to other people. You need to get your name out there. There are a million things you need to do before you become successful and complacent in your chosen career field. I worked at a bank as a teller all through college and scrownged around for code jobs until I got fed up with a lot of processes we had so I wrote better ones over a couple nights & presented them to my boss... who passed them along until one day I got noticed.
If you want something you have to devote some genuine time and effort to it. Show people you want it. Don't just expect it.
Please. The word is ridiculously. With an "i".
Perhaps remembering the root - "ridicule" - will help?
How I wish I could find a link to the Dilbert strip about being an ant farm engineer.
I'm confused...no modern nation in the world has anything even close to a 'free market'. Government subsidies?!
Blar.
Yeah, that 25% tax you see there on the bottom, is to cover outsourcing insurance.
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
... is still looking for a senior programmer with 15 years of .NET experience.
Have gnu, will travel.
What is wrong with the 400 disc changer? I'd much rather have a 400 disc changer than an iPod? Or are they just not keeping the order consistent?
The masses are the crack whores of religion.
Not to a corporation!
You sir, are specifically listed in the exempt from overtime statutes in the federal code, as am I.
They can work our asses until we quit or die from stress and not pay a penny in overtime, extra salary, benefits or anything.
So far as HR goes we are just that, Human RESOURCES. THINGS, piles of coal to be burned until we are used up, with nothing but dust left to sweep out the door.
Hiring quality will never happen until IT people are paid hourly, with overtime protections.
And that will happen when the average coder is getting somewhere around minimum wage.
The big consulting companies, and companies with big IT departments pay too much to politicians to allow that to happen.
So, to turn a phrase: Suffer, code-bitch.
"Some of the best developers I know were originally trained as journalists, mathmaticians, linguists, and other professions not normally associated with software development."
Sorry, don't agree with this statement, nor the one about Perl being some great language. Every language has it's place, and you need to use the right one for the job, which a whole course was dedicated to in my BSCS.
One way to identify these develpers is to ask them what tools THEY have created to save time and effort.
Your chances of finding an expert in such an accomplished population should be very good indeed!
my intution is that there are a LOT of people out there that only have 2-year degrees and get picked up for the low-end stuff. Meanwhile, the number of people going to 4-year programs for Computer Science or getting a Masters is shrinking because, well, the stereotypes aren't too appealing and many have heard plenty of rumors about work environments like Initech. Also, managers are becoming more concerned about costs rather than quality, and hence created waves like the pandemic outsourcing trend.
First, being a generalist has meant that I have been steadily employed through several minibursts in the local tech economy. I've always found something that suited /me/ when more specialized friends have not.
Second, being a "generalist" has allowed me to keep well ahead on many learning curves than my "specialist" colleagues. Very rarely does any single technology, language, or platform remain en vogue for more than a year or two. As the next big thing comes along, I have been able to adapt faster due to my broader perspective, typically being responsible for instruction of more static peers.
The reason this is possible isn't some innate superiority-- it's simply by virtue of my generalized experience. I've programmed in various managed and unmanaged languages on various platforms and in various industries. Back when I was a consultant, frequently many of each at once. "New" is rarely new unless it's a specialized platform.
The thing is, that fellow who "does a little bit of everything" seems to be rising more consistently towards the technical lead level at my organization. "Matrixing" is the new buzzword of the moment, which really just means flexible resource allocation. Since seniority is generally preserved, such leads generally can't be specialists...One week, you may be leading a team of web developers, the next designing the schema for a database.
My suggestion is that you analyze your work environment and see if, perhaps, there is some other limiting factor on your career. Are you a "dump" for any problem that "doesn't quite fit the box" on your team rather than a valued asset? Are you in a top heavy organization? Do your immediate superiors appreciate your ability to make their lives easier?
The best programmers realize everything they do sucks, is *fundamentally* flawed and never anywhere near approaching good enough. They don't reflect on their careers or tout their own achivements as this just conjures memories of how much they suck at what they do.
The best programmers must also strive to be as lazy as possible in the context of their contributions entire product lifecycle.
And for crying out loud..the best programmers *DO NOT* waste their time reading/posting on Slashdot!!
You don't need to hire an expert in language X, you can and should look for expert programmers that are willing to learn language X. An expert can easily cross over from being a novice in any language in a matter of a few weeks.
..., plus another dozen or more libraries typically used even on a small Java web project.
I read this a lot, but it's misleading, and raises wrong expectations. While learning a new syntax and grammar can be done in hours, it doesn't buy you much. To get to that 10x productivity level on a real-world project, you have to master the whole ecosystem surrounding a language - standard libraries, open-source libraries, tools, idiomatic use, patterns, conventions, best practices, common architectures etc.
As an example, coming from Java, if I switch to Ruby, how long before my code truly follows "the ruby way"? How long before I know the ins and outs of Ruby on Rails and the standard libraries including their gotchas? How long before I can architect a serious ruby application that makes good use of its meta programming facilities, instead of one that looks as if it was ported from Java?
Or, as another example, if you switch from Ruby to Java, let's say on a web project: How long before you can make a informed choice which web framework to pick? How long before you know the architecture implications of picking Hibernate, and when iBatis would be a better match? To know what Spring can do for you, and what you are giving up by not using it? Until you know even a standard set of tools like Eclipse plus which plugins to use, FindBugs, Ant, Cruise Control, Emma,
Of course, you can be productive even when you don't yet know all these things, and are still learning - but you won't be productive on the expert / 10x level we are talking about. By all means, become an expert in as many languages as you can - but don't plan on getting there in 24 hours, days or even weeks.
(Disclaimer: Switching between fairly similar environments, e.g. Java C#, is of course much easier).
Stupidity is mis-underestimated.
Yes, Virginia, we do exist.
I am an uberprogrammer.
I am (at least) 10 times as productive as the average programmer, write good, highly performing, well documented code and designs the very first time (and yes, I was once a sys admin too). And I'm compensated $200K/year for my efforts. I can work in any domain or language and come up to speed faster than any "average" employee of any experience level.
(New and inexperienced programmers can be very valuable under the oversight of excellent technical leadership and mentors. Good tech managers are, however, as rare as us uberprogrammers. You're better off with a few of us.)
It still doesn't make much difference.
The mediocrity of Fortune 500 management, misguided technical leadership, utter failure to understand the underlying principles of component based development, SOA and the Mythical Man Month prevent me from carrying otherwise large and complex projects by myself. (I would just make them simple and then lots of people would be out of work.) Unfortunately divisions of incompetent designers, architects and managers can so badly mess up the simplest projects, that often the best I can do is to save my projects from utter failure instead of making them the shining successes they could easily be.
Really, though, that's my job.
There have been a few times I've met other uberprogrammers and we have created beautiful code together, in a very short time. Those projects are so successful they're hardly noticed and quickly forgotten. Then, after some other project begins to fail horribly, I'm back to work fixing broken projects enough so that management can get their bonuses. Afterwards, management immediately goes back to their old ways of technical incompetence and poor development processes that caused the failures in the first place.
And I'll be there, waiting, reading slashdot, until the next time I'm called.
Uberprogrammer
I'm a little dismissive of the mystique around the required "super hackers" that never need to look for work but there is a ton of great advice on just hiring people.
I'm an engineer. Been there and done a lot of that. I'm not going to say I'm one of the greatest but not too shabby, I've built some stuff and made some good money, you, know left a few marks.. As a more senior guy I've been taking on more and more leadership and to be completely honest, I like to think there are things I know to look for and catch, but I suck at hiring and team building. At the end of the day it's about building products, selling them and making money and the balance between people you think are a good personality match vs. the people that are technically good enough vs. people that are actually motivated and want to work and be successful is hard. We've hired folks we though were good personality matches for the team and turned out to be terrible technically and completely unmotivated, as much as you might want to like them, you simply won't when they are trying to play big business "CYA" games and not actually contributing to the team.
I'm kind of dealing with a situation now, we're a small team, 4 or 5 developers and 2 testers. We hired the 5th developer based largely upon a recommendation from one of the testers. He's a marginal tester to be honest, good guy, just not super motivated, why we hired his recommendation is looking more and more stupid by the day, we value recommendations. After reading Joel's book I've found like 6 or 7 indicators that probably would have flagged this guy that we simply didn't think about. We were in a hurry, we thought the req would go away, etc.. Honestly, I'd rather have one fewer people and better morale that this guy, seriously in 6-8 months of having him, I cannot point to a single substantial contribution. Now we get to go through the process of firing him which sucks for every one involved also.
Basically, you always want smart people, you want motivated people, people that do a good job, people that have some passion, good communicators, strong team people that know what it is to be on a team, you want all of that stuff, all of the time and it's hard to find. We pretend that parts don't matter or don't matter as much. Having shitty people on your team just flat out sucks, doesn't matter how good everything else is.
Another reason to prefer many junior developers is that junior developers scale much more cost effectively. On many large internal projects, there is a large amount of work that is both not technically very challenging and yet not automatable. Coding data collection screens, implementing batch processing routines, specifying reports. All of these tasks are time consuming, but none of them are substantially skill-dependent; they are busy work.
This has the effect that "uber" (highly skilled) programmers do not complete the tasks in substantially less time than standard-fare programmers. However, if you follow the author's suggestions, you will still be paying your uber programmers uber salaries to perform this work. But even though they are completing the work only 5-10% faster than standard-fare programmers, you are still paying them 20-50% more.
Had you instead built your organization around a large, dynamic, pluggable pool of junior or standard-fare programmers, you would be able to complete the work at a significant cost savings.
There are other issues besides technical skills. The higher you rise in the food chain, the more the "soft skills" matter. Organizational skills, people skills, communication skills. All the elegant code in the world doesn't make up for a prima donna who won't show up for a critical meeting or who openly disrespects "lesser" members of the team. The last thing in the world most people want is to hire the developer equivalent of Terrel Owens... because, just like Owens, they will leave damaged teams in their wake. Morale counts. The reason that leads get paid more than individual contributors is not just because of technical skills. It's because they can herd cats. It's because they can recognize that business reality sometimes has to trump "ideal" elegance or philosophy-of-the-week. It's because they can convince Dev to talk to QA to talk to Product Management to talk to Sales. It's because they can somehow get a clear functional spec from the marketing guy. It's because they can get by with existing equipment instead of demanding an Intel Core 31337 for their desktop. It's because they don't have to have an HR apologist in tow smoothing ruffled feathers everywhere they go. "Senior" implies so much more than "technical guru".
Everybody gets what the majority deserves.
Companies won't pay that kind of money. They will tell you, you cost to much and will ship your job overseas to India! "You cost us $52/HR, they only cost us $27/HR." If the company needs to cut costs the jobs that aren't out right cut will be outsourced overseas. Programmers are the biggest target as they can pay Indians less. This is FACT! But companies ALWAYS fail to realize that many times the quality is in the toilet of what you get. You get what you pay for!
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.
Simply put, experts write readable code. They comment and document it appropriately based on the complexity and criticality of that particular piece of code.
All of this pays huge dividends when the next developer has to pick up where they left off. Especially if the next person isn't an expert.
From these statements I consider myslef an "expert" then. I like to think I fit into everyone of these items.
I have worked with way to many developers that fit this bill:
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.
I can't count how many times I have had to re-write stuff that was such bad code it should have never been written in the FIRST place! I wish I got paid $120K (I make quite a lot less that) for being an expert - instead I'm being outsourced to India eventually (as soon as they take over all our projects) - because I and my fellow developers "cost too much".
Show me a company that -wants- a developre with 21+ years experience and has done it all in IT and -wants- an expert and will pay $100K - $120K for that expertise and not just outsource it. Good luck, I doubt you will find one.
The Truth is a Virus!!!
That is exactly correct. This article is exactly right.
The number of poor developers out there is staggering. I left a previous team not because the work wasn't particularly appealing, but because the people on the team were poor and I didn't want to deal with crappy code anymore.
This is also why software goes to die at companies like CA or other large software companies. Developers who have developed for 20+ years are set in their ways and are unwilling to learn new techniques. We have developers that completely disregard the notion of unit testing (and are unwilling to recognize the value). Sheeit, we have devs who we couldn't convince to use smart pointers on a regular basis in our C++ code. Yet, these are principal-level software engineers getting paid in excess of 100K a year, just because they have the "industry experience".
The actual contribution of these software engineers' skills has decreased over time (and much more so in comparison with the state of the art), yet their salaries keep increasing over time.
One company I know hired devs with a certain keyword on their resume, passing over another candidate with a lot less experience. I guarantee 5000 that the person they passed over would've learned all the material related to that keyword and would've put out higher quality software in less time.
You guys pay $80k even for mediocre programmers?
Wow, am I underpaid...
... while the others have 1 year of experience 20 times. (source? - I forget).
Seriously, I used to teach a workshop on software quality assurance. An earlier poster said that some programmers are 10 times more productive than others, and it turns out it's true. From the data I found researching for the class (this predates the web, so sorry, no URL!), a study of programmers within the big corporate/government real found that within one standard deviation programmer productivity varied by more than an order of magnitude - IIRC it was about 20 times. I don't recall the measure, but it was reasonable at the time.
Having seen how much worse/slower some are than I, and how much more some other people manage to accomplish than I, I'd say it's at least 5x each way, so 25x is a reasonable number to my mind.
I had one consultant that worked for us for six months, then we fired him. A year later not a single line of his code still existed in the system. I figured this was a testimony to the quality of his work.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
No, we don't, but plenty of people do out here in the Bay Area. Even more actually. But then again, a 3BR/2BA house in a good neighborhood with good schools will set you back $1.5 million!
Finding decent Perl programmer is really hard thing, if ever possible... :-)
Very seldom has quality been under my control. I'm told what language to use, how to design it, etc.
All the choices that directly control the worth of the final product are already chosen for me.
-- Programming with boost is like building a house with lego. It's a cool but I wouldn't want to live in it
I'm amazed how every five years someone realizes what people knew 40 years ago, only to promptly forget it for the next wave of people to figure out five years from now.
On the flip side, why is there such an excess of not-so-great programmers out there? The answer is simple: The higher education system is turning out not-so-great graduates. In an ideal world they would not, but we live in a world where there are "CS Graduates" who have never seen anything more than pseudo-code and java. There are some great programs and great graduates to be found for sure, but I think the writing on the wall is apparent -- the average graduate is a below-average programmer. There needs to be more hands-on exposure to real, complex code, or better yet, production code.
In the interim, unfortunately, we realistically need to take in some of the graduates that we have and finish the education they apparantly never received in full. If we don't -- if we let a bubble form between now and when the educational system corrects itself, then we will effectively lose much of the "tribal knowledge" that is passed down through the generations of the workforce.
You cannot sustain a class of experts in any endeavor simply by surrounding them with other experts. At some point they must mentor or pass down their knowledge to the next generation -- but the best way to ensure the next generation is to make sure that they're at least on-par as a developer.
I say all this as a relatively young developer who graduated in Computer Science in 2002.
But having 80 people work for 1 hour a week is not any better. You need the right number of people for the tasks you are working on. There aren't very many types of programming tasks can be split easily among a large group.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
I disagree with the premise of this article. This article assumes that it's easy to determine who is and who isn't a good programmer and then goes on to discuss the benefits of choosing a good programmer over an average programmer... I find this discussion meritless because its first assumption is, in my view, plain wrong. It's difficult to hire good to great programmers because generally, it is virtually impossible to determine how good a programmer really is based on an interview, a resume, the person's current salary at his/her existing job, or references. It is this fact that it's so hard to tell who is good and who is not that makes hiring difficult. Hence, you get the statistical mix of good and bad programmers after you've hired enough people. If it was easy to determine the quality of each programmer, don't you think everyone would prefer to hire the better programmer? Hence, I think the rest of this article is rather moot. Maybe a more interesting article would be an exploration of how we can reduce the costs of trying to figure out who is good and who is average to assist those who are in the market to hire programmers.
If a business treats you with the same concern as they do a laptop computer, don't work there in the first place, or leave.
I don't mind working overtime if something needs to get done occasionally, or if I'm really in the zone. However, I'm not going to work myself to death every single week; people who do are either masochists, or they don't know any better.
Yes, I am a smart ass; it's better than the alternative.
Yep, but it costs more. That is why companies refuse to hire more people.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
I've been a software engineering manager for a long time. I don't blame the higher education system. Nearly all CS programs cover enough of the basics to form a foundation for lifetime learning in CS. The rest is up to the student and their own innate passion. If they have a passion for the technology and chose CS as a labor of love, then they'll do fine. There have been many graduates of CS programs who declared CS majors when counseled to 'get into computers' by a high school guidance counselor. I always look for the passion players when I hire people. I avoid the people who chose CS as a 'sensible career in computers'. I've seen some passionate lovers of CS that come from tiny state universities run circles around graduates of Stanford, MIT, and Berkely.
I think the biggest stumbling block for above-average developers is the attitude of managers who indeed think of programmers as 'cogs in the machine'. And a sausage-machine at that. I have seen too many projects without a serious design phase at all. Typically they start with a team of managers and tutti quanti dreaming up a specification (usually to vague to be useful, but still specific enough to be unworkable) and then expecting that the software will simply be written.
When you try to explain to them that actually, there is nobody in the IT department who is actually capable of designing and building such a system of the required complexity, you meet blank stares and incredulity. How is that possible, when that place is filled with programmers? Trying to explain the difference between routine GUI programming, systems administration, database administration, and designing a company-wide system of interlinked applications is no use. Managers would apparently trust any competent car mechanic to design a Formula-1 car. Well, they must, because they are not willing to pay for the skilled engineers that it takes to do the real job, or to invest in serious training for the people that they have.
Of course, if they don't have the people, managers are willing to contract them. So they pay to bring in programmers from consultancy firms, and expect them to hit the ground running, seamlessly integrating in teams with people they have never met before, and writing business logic for a business they don't understand. You would need to be really lucky to find all the right people right away, more often you need to get rid of about half the consultants you hired at first, because they are no good or because they experience is too far removed from the needs of the projects.
So far, I've met just one or two really highly skilled and creative developers. Flexible thinkers who quickly grasp problems, readily adopt to whatever technology they need, plan realistically, and deliver quality work. They are a delight to work with, and you can achieve as much with them in one hour as you would else do in whole month of meetings and deliberations. But they are usually self-employed or running their own little firms, and they can afford to pick and choose the projects they are interested in. If they don't want to do it, or don't have the time, they won't. Management regards often them as 'difficult' and expensive, considering that other programmers are a dime a dozen... So the pleasure is rare.
The normal condition is to have a mix of more or less skilled people who will learn on the job and might be quite competent at the end of the project, and inevitably a few idiots you have to entrust parts of the project to with appropriate feelings of resignation and foreboding. (When in IT waters, I live on my wits. I have no authority there.)
I work for a small game developer. We recently announced we are developing a pretty big title, and some fanboys of the game said that we'd make a lousy product because our Programmer Job description on our job page reads like this :
If programming games is your dream, we're the place for you. Please send in examples of your work, no matter how trivial. Websites are acceptable as well. You can't always work in one language long enough to know the syntax by heart. But the concepts are reusable, that is what we look for. C/C++ knowledge is an advantage but not necessary.
The comment went along the lines of, how can a company make any good games if they hire just anyone off the street? Well, we do. But everyone has to pass a test. We basically hand them a copy of the engine and give them the instruction of. "Complete it" It's their job to read the code, figure out what it does, and add their own code to extend functionality. The test basically tests their ability to grok it. To get it to compile. Then to extend the code while following proper standards and naming conventions( As long as you follow the style of the rest of the code, we're happy ). Finally, their creativity. We don't tell them how to complete it. So some people do the bare minimum which shows competence, and some go all out. But usually you can tell what they like. Some are AI heavy, some do a lot with player mechanics, and some start extending the engine when they want to do more (Warning : Not Invented Here Syndrome Probably Present).
So we've got some older guys from the VIC-20 days, some young college grads and some non-traditionally trained programmers. I'm a tools and build process guy myself. Engine is another set of people that hate muddling with gameplay because you can only spec so much, the rest is up to...testing and feel, and they hate repetitive work like that. The gameplay guys that love to noodle and pull magic numbers out of the air and test until it feels "just right".
We also do products in staggerred teams. Several experienced developers, several inexperienced. Let the experienced funnel the knowledge down. Rotating R&D cycles, so everyones fingers is in the engine at least a little bit. Really experienced outside developers have their issues sometimes as well. They are very set in their ways, and it's hard to mold them to your system. Which is why Microsoft prefers hiring physics and math majors. They haven't learned any bad habits yet. Sure when it comes to crunch time, we do neglect the juniors, but that is when the smart one's start to shine.
Then you said: you can do anything with a modern COBOL compiler that you can do with any number of other languages. couldn't help but notice the discrepencies....unless you are either admitting that A: You don't know that much about COBOL and are just regurgitating what some old COBOL programmer told you or B: You understand that certain things can be done much better in certain languages.
CS: It is all sink or swim...oh and did I mention there are sharks in that water?
Then your three guys go out for lunch in the same car one day, and they get hit by a bus.
You're missing the point. GP proposed a reductio of the claim that an überdeveloper is really 10 times as productive as a mediocre developer, based on the logic that if this were really so, they would command 10 times as much pay. However, there are sound reasons why the productivity might be 10x, but the pay less than that--higher risks inherent in hiring fewer people, and imperfect information about how good developers actually are.
No matter how you do the math, as you add more developers with no unique or rare skills, you tend to reduce the risks associated with the loss of any one of them. The real questions here what is the business' capacity and taste for risk, and which staffing decisions meet the desired risk profile. Saying "get 3 good guys instead of 10 mediocre ones" doesn't even begin to address the issue.
Are you adequate?
You're selling the wrong thing. Your languages aren't really what you need to be selling but what you told us already. i.e "experience writing software for the financial industry that work, writing software that is delivered on time and on budget and recieving praise for the quality of software I write." I hope you also hanged onto your performance reviews were some of this is documented?
"but everyone's mindset is "I need x years of this language experience before I'll talk to you"."
That's really no different than any other job in other professions. What you have to convince them of isn't that you have "x years". But that you're reasonably proficient (leave the "for dummies" books at home) in what they're asking for and that you have the demonstrated ability to learn.
You may not get the job, but then if there already was someone with "x" this and "y" that. Then there wouldn't even be an ad.*
*And yes I know what the slashcynics are going to say. Don't worry about it. It doesn't hurt to try and if you get an interview and fail? Turn it into a learning experience so you'll do better next time. BTW don't forget the cover letters. Too many forget those. And follow up!! That will make you stick out over most.
Ok we need to get real it's not 50k and 125k. We live in a global market it's really 125K and 10.9K so you can hire 11 senior programmers in china (and they work 90hours a week) an one system programmer in US. Think I am full of BS?? I only wish I was my wife's father owns a software outsourcing company. You can't put trade tariffs on lines of code baby. Sucks to be a programmer including myself we are just task driven people (i.e. Light bulbs). Ya that's what the idiot with an MBA thinks of you. You're just programming slave that has to be given tasks. Programmers are just worthless scum bags that get paid more than some production guy. An you both do the same thing build a product. People that work with tools are ruled and people that think rule. So everyone reading this little small thought go start your own company the money will come just give it some time. Cheers, WAT
"So, why isn't there room in the software industry for a low cost provider, someone who uses the cheapest programmers available? (Remind me to ask Quark how that whole fire-everybody-and-hire-low-cost-replacements plan is working.)
Here's why: duplication of software is free. That means that the cost of programmers is spread out over all the copies of the software you sell. With software, you can improve quality without adding to the incremental cost of each unit sold.
Essentially, design adds value faster than it adds cost.
Or, roughly speaking, if you try to skimp on programmers, you'll make crappy software, and you won't even save that much money."
"The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce.
Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years.
Five Jim Davis's -- creator of that unfunny cartoon cat, where 20% of the jokes are about how Monday sucks and the rest are about how much the cat likes lasagna (and those are the punchlines!) ... five Jim Davis's could spend the rest of their lives writing comedy and never, ever produce the Soup Nazi episode of Seinfeld."
Yeah, the closest thing we have so far is Electronic Arts.
[same applies to the GP post]
As for your 20something workhorses you as a manager need to learn that there is a difference between a workhorse putting in hours and a workhorse that can get a weeks worth of 20 something work done in a day. I know a couple programmers who can for a fraction of the price punch out what the 20 somethings in half the time and a product that you will not recode when you learn the crap mistakes the 20 somethings are learning on your buck.
Case and point, think of when you first started coding, go back and look at the code, how much better are you now than then?
CS: It is all sink or swim...oh and did I mention there are sharks in that water?
You blast Perl, and then go on to suggest Java, of all things?
The reason there is bad code in Perl is, it doesn't actually "force" you to do anything. There are so many ways to do it that it's very easy to write crap -- but it's also very easy to write good stuff.
That works even better if you apply it to Java.
Java has things like static type checking -- to the point where you must explicitly declare what exceptions you might run into. Before templates, I was actually forced to typecast to and from Object...
This is flatly retarded, by the way -- if Java can give me a compile-time error that my method didn't declare a particular exception, why can't I simply omit all such declarations and let the compiler add them back in?
But then, managers like to see Java as a good thing precisely because it's so limiting. It forces everything to some level of mediocrity and sameness, meaning horrible programmers are just slightly bad because Java keeps them from shooting themselves in the foot. It also means you can hire a team of horrible programmers, and replace any one of them with another at any time, and the project will continue moving forward. And it's great for programmers, because they can look busy all day writing interfaces, typing ridiculously long method declarations, and dealing with the complexities and limitations of things like single inheritance, without having to get much actual work done (or do much thinking).
But what people are finding out is, flexibility like Perl's is really useful. Look at Ruby. The syntax looks OK on the surface, but get into even marginally complex programs and it can look as ugly as Perl. But it's also amazingly flexible, quick to code in, and makes a bright programmer into a brilliant programmer -- whereas Java will take your bright programmers and beat them down into codemonkeys.
You can point to all the Java in the world, but when Ruby runs probably 10 or 100 times as slow as Java, and people STILL use it to run websites, and simply buy more hardware? I'd say that proves we have some damned good languages. Obviously better than Java -- pick any site that's written in Perl or Ruby (even Python), and not Java, and ask yourself why.
Now, PHP is an horrifically bad language...
Don't thank God, thank a doctor!
Your experience was not unique. If you wanted to learn to specialize in one language, you didn't need to get a 4-yr CS degree to do it. Most decent 2-yr colleges with a program in programming (or, for that matter, your local bookstore) can teach you the syntax for the Language-of-the-month.
Instead, you probably chose a Computer Science degree. The name alone should tell you something, namely that your degree is going to be in science. Of course it is going to be theory-intensive! You were being given the tools you need to learn quickly just about any computer language, and solve a wide range of problems with them. If you concentrated in a single language, it is doubtful you would have been able to learn as much as to how computer languages work. Nothing gets you thinking about data structures, algorithms, methods, etc. like having to translate complex problems into a different language each semester.
That is what separates a quality degreed programmer from a self-taught programmer similar intelligence without the same training. That is not to say that all degree holders are good programmers, or that all non-degreed programmers are bad ones...
In fact, it is highly likely none of your professors even knew Ruby, or the LAMP stack. The job of a college professor is to perform original research work to advance the state-of-the-art, and to pass on the accumulated knowledge of the ages to students. If the students are any good whatsoever, they will be able to figure out for themselves how to apply it to practical work, if that is their chosen career path.
However, if all you did in college is take and pass your classes, you will indeed have a tough time "hitting the ground running" in most jobs. This would be the case even if your school did specialize in a single language, because there is a heck of a lot more to programming proficiency than the language itself. For myself, I had several school-year and summer jobs doing "front-lines" IT work, programming, and even a low-end retail mgmt. job. I learned things there that could not have been taught in any class, and conversely my classes taught me things that would have been difficult or impossible to pick up as part of on-the-job training.
Immediate employability is not the job or goal of college curriculums, nor should it be. It has always been my impression that it is a student's responsibility, via self-learning, personal programming projects and relevant part-time and summer work, to pick up where their theoretical classes left off.
SirWired
For 100's of years you have the senior crafts man and his apprentices.
You can't get good quality with just Senior crafts man, or just junior apprentice types.
The Junior ones just don't know how to make the trade offs or the how and why things are done a certain way and end up painting then selves into a corner or making a mess for the next guy to deal with. But they are young and full of energy.
The Senior ones, just don't have the patients or excitement about over all of the stupid little details. They just can't get excited about doing the same thing over and over. But they think ahead for the next guy, they know how to avoid problems and usually know how to fix problem when they arise.
Also they have usually have a long list of other senior developers they can call on for help and advice.
Often on a really difficult problem the phone and E-mail are your best tools.
As my former partner the infamous Jesus Monroy used to say, on a boat you need rower and captains. Too many of either doesn't work.
As a senior developer, I find I am best at working the really difficult problems, but lack the patients for the more mundane bulk coding.
Also like doing architecture work.
But thing work best when there a Junior programmer that will get stuck on a problem and usually hide in the cube for weeks trying to solve it. Where when I am around I usually can take one look and tell then exactly how to fix it. As a result they tend to get 10x or more work done when I am around.
Also junior programmer usually just start writing code when giving a project with little consideration on design. The end result tends to be large, slow and almost impossible to debug.
As someone experienced, I find that laying out the design, the foundation, if you will that everything else is to be built of from is critical.
Once designed correctly, the code is much smaller, simpler, is easy to work on and debug. It also less code means it runs faster, loads faster and uses less resources.
Also less code, means it faster to implement. So I'll spend more then 1/2 of the development time on research and testing, and design, before I ever type the first line of code in. But in the end, I get done faster and almost never have any logical bugs, memory leaks and have never needed a debugger, just type-o's as mostly, of only I could spell...
I hate nothing worse the Bloated code.
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
Making you actually handle the exceptions your code is declared to produce is "retarded"? You haven't really thought about that, now have you?
Why do I get the impression you can't handle Java? Why do I get the impression I'd never hire you because you'd never get past the question, "So, what practices, procedures, and habits have you developed in your years of coding that are intended to prevent the introduction of bugs?"
Programmers these days, are on about the same level as typists.
Given Problem A, Apply generic Java Cookbook Solution A
Given Problem X, Apply generic Java Cookbook Solution X
and so on and so on
Don't worry about code quality, JavaDoc, PerlDoc will do it FOR you.
Don't worry about memory management / leaks, let java do it FOR you.
Don't worry about which algorithm to use, let Java do it FOR you.
You are not getting a person that can solve problems and analyze data, you are getting someone who can cut,copy,paste and 'resue' code by altering the hell out of some java example problem.
Experience doesn't mean anything in this field anymore. You pay your money, you take your chances with some 'learn Java in 24 hours' person.
Software Engineers on the otherhand, that is 'Real' Software Engineers (a generic B.Eng in Canada anyway), are taught a mix of CS/Math and a Electrical/Mech/Civil/Chemical background. They can solve problems, and apply an engineering discipline to solving a problem. Not just sit down and produce steaming mounds of code.
As an added bonus, if hired as an Engineer, they can be licensed by the PEO, to produce mission or safety critical software. They FSCK up, and their licence can be revoked, and they can be sued. What happens when code money #44 FSCK's up and the voting machine fails...pretty much nothing, he gets fired, and moves to another code monkey pounding out steaming mounds of code job.
a Distinction has to be made re, the 'run of the mill programmer' suitable for working say at Microsoft, etc, and a qualified Engineer, who can work just about anywhere.
so you can hire 11 senior programmers in china
Not if you have a secure project, you can't.
Reason #1 to get a security clearance: you can't be outsourced.
Who's hiring these recruiters? I may have all the qualities of an expert developer, but I'll never in a million years get even a sniff if I don't have all the checkboxes in order. Recruiters don't care if your resume screams out that you can be idiomatic in a new language or system within a few weeks. They'd far prefer you have a ten year history of making the same pinhead mistakes over and over. The attitudes of recruiters reflect the desires of the company, whether they're implicit or explicit. Companies that have trouble finding expert programmers are just lazy.
The problem with Java is there is no built-in filter to keep out the bad programmers. I agree that Java is better than Perl. But I've seen probably more bad programmers doing a Java than bad programmers doing Perl. This doesn't mean one should stop using Java by any means. It just means you better select your programmers very very carefully. And their experience in other languages should count.
now we need to go OSS in diesel cars
College is not programmer training. It's building a foundation upon which one learns new things for the rest of their life ... or at least for the rest of their career. There will be good programmers and bad programmers coming out of CS programs at every GPA level. You have to figure out which is which because that was not what colleges are there to do. One of the best programmers I ever had working for me had no college at all and had only done some code hacking at home. In other cases it's real world experience that counts more than compuetr experience.
now we need to go OSS in diesel cars
I definitely agree with this -- contacts can be very useful. My biggest let-down was that I spent several extra years working towards a Masters' degree while most of my friends went out to get jobs with the companies that actively recruited finishing undergraduates. I got it in the end, but also decided I'd had enough of academia and just wanted a job.
Getting past the recruitment agents was awful, because there was absolutely zero understanding beyond keyword searches of buzzwords that were related to Java and DotNet, especially when my only formal commercial experience had been a couple of years of ASP web development. (yuck) Years of experience programming and scripting in a zillion languages in NetBSD, Solaris and Linux systems in academia didn't really count for much.
In the end, I emailed someone who I'd worked with in a temp job at Christmas a few years before, to ask if there was anything going. I was very fortunate that there was, and that he already had a lot of respect for my abilities, and now I've landed a nice job which is right now is primarily working with DotNet, but which also gives me a lot of opportunities to play in other things. I'm also hoping that the commercial experience I get here might actually count for something in the future.
I think that part of it can be finding the right recruitment agent. For the ones who don't properly understand the industry, it's a risk presenting someone to an employer when they don't necessarily have the specifics that were asked for, especially if the agent doesn't really understand the industry. I did manage to find a couple of agents who actually seemed to understand a lot more and were really enthusiastic, but I was only discovering them at about the time I already found a new job. Those are the agents I recommend to friends, and next time I'm searching they'll be the first I go back to.
you have probably heard of Ross Perot
as a kid, he was a salesman for IBM on comission, no cap
he made more then the VP levels above him
as a result, IBM changed the whole comission structure so that a sales person could not make more then a VP
moral: companies will cut off their noses to spite themselves
beyond this, we are hiringin, and how do you tell if someone is really 5x or whatever better ?
it is worse then useless to say that there exists a special class of super programmers if you cant identify them during the hiring process.
developing code that can do something simple like print 0..1999 excluding numbers not divisible by 5 or 2 and excluding any number divisible by 3.
a novice might screw up some of the semantics and wind up including 15 in the printout,
the high end and the regular should be able to code it in under a cup of cofee.
on a harder task.. calculate all primes under 32 bits and populate a vector with the results.
A novice is going to have code that is slow as sin. O(n^2) (2^64 ops)
a regular shmoe coder will manage to find a few tricks that will make the process a bit faster. O(n * sqrt n) (around 2^48 ops)
A high end coder can pull off an O(n) result (less than 2^32 ops)
They might all pull it off in the same time but high end coding makes all the difference in performance.
Some programmers are paid correctly, but quite a few are overpaid for their lack of skill, and some are underpaid for a brutal level of skill. And some uber-hackers just produce at regular hacker levels because they can get away with it.
Storm
In real world people get paid by using the right tools to get the job done.
In some cases, Perl is the right tool.
Obama likes poor people so much, he wants to make more of them.
Oh mate, if I only had some mod-points you'd be up there. I nearly choked on my coffee when I read the GP...
No, making you actually declare every single exception that might possibly happen, even if you don't intend to catch all of them, is retarded.
Let's say I've extended "Hello, World" to ask you for your name, so it can then say "Hello, <name>!"
class Hello {
public static void main(String [] args) throws IOException...
Obviously, "Hello, World" is a simple enough program that IOException doesn't need to be caught. I'd much rather just leave that off, and let the program crash with an exception error. And I can do that, but I still have to declare it, for no good reason.
For that matter, there are plenty of cases where you might want to handle the exception, but at a lower level. Why should the intermediate levels all have to know about IOException?
For example, I might be five calls in before I hit the exception. Could be five separate methods that now need to have "throws IOException", even though all I really intend to do is catch it somewhere out in the main program loop and throw up an error dialog, then either quit or try to restart the program. (Re-initializing all data structures might be faster than starting the program from scratch -- remember, this is Java, and Java can take a LONG time to start.) But that means there's maybe one method doing IO, and one method which catches the exception, and three methods in between that have to know about the exception for no good reason.
Sure, there are runtime exceptions. But I have no control over what libraries use them or don't, and I distinctly remember that there were disadvantages, though I can't remember what they are. (I haven't used Java for years, on purpose.)
From a technical point of view, I can sort of see why it might make sense for the generated code to contain information about what exceptions to expect. It might even be a best practice to provide some comment stating what exceptions might be thrown, maybe even to have some system which watches for this kind of comment, the way Eclipse can automatically generate your documentation for you, and warn you if you don't have properly formatted comments for every method.
But it shouldn't be required any more than documentation is required. You can always write a third-party tool to audit your code, you don't have to throw up a compiler error if not everyone wants to conform to your precise coding style.
Unit testing. Tight development cycle. Avoid global variables, and use namespaces where possible. Comment more than you think you'll need to. Turn on warnings in the language during development. Use stubs and prototypes so you can get something that sort-of works, so that you can keep it sort-of working as you fill in the details (see Unit testing and Tight development cycle).
Also, modularity is good. A chunk of code shouldn't have to know about more than what it absolutely needs to. And my Hello World program has no need to even know that an exception exists.
Don't thank God, thank a doctor!
At the end of the day, what matters the most is whether your team fits well together or not. I've recently found myself in a situation where my extensive coding skills are going to waste, just because the shop I work for, like to do things differently (read: fast and cheap, to stay competitive). Now there's nothing inherently wrong with that, because that's how the customers like it. I find myself struggling with what should be trivial work, simply because I haven't written such spaghetti code in oh, 20 years! It doesn't matter that I could probably code an operating system in Javascript (a very shitty operating system, indeed!), my daily challenge is to set aside my pattern-rich design style, and settle for the quickest solution that fits the requirements.
I guess my point is, no matter how specialized you are, 90% of the work out there is simple generic crap. Just because we're brilliant designers doesn't mean there's a client to appreciate our artful code. What the user sees is "I type stuff in, and click a button", whether you coded 4 levels of abstraction, or you're some half-brained VB 2.0 "developer"... it's all the same to their eyes, and the only thing that matters beyond that is the bottom line. This means we'll be seeing more and more junior (low wage) developers churning out garbage code that usually does what the client wants, that's simply the product of a competitive market.
-Billco, Fnarg.com
Yeah "retarded" maybe wasn't the best wording, otherwise it's a pretty good post.
.NET programming.
Java feels like a very restrictive language; for example, as parent pointed out it forces you to spend a lot of time coding exception handling clauses, until a fair percentage of your code base consists of boilerplate exception handling. Now it's great that it forces attention to be paid to error handling, but that's not the only way to do it, and maybe not even the best way.
Also, Sun (and IBM, etc) has defined such a wide range of standard classes that it seems like the art of being a Java programmer is find and superficially learning all the APIs you need for a given project as quickly as possible, instead of developing infrastructure code of your own (incidentally the latter is where programmers develop mastery of their art, not gluing together stuff into an application). Similar remarks can be made about
Perl is a very loose language by comparison, not at all suitable for mission-critical code but terrific for many small tasks that need to be tweaked as requirements change, as for web applications and system administration.
I LOVE CS and IS, but I cannot locate a position - I worked in industry for 12 years, I build hardware and am studying verilog, I write assy, C, C++ w/STL, Java, perl and sh, among other things designed and built software to dump function vectors from RAM to hardware EEPROM for a computing platform, that is, I have bit-level knowledge. I have professional sys admin and security experience for NT, Solaris, Linux, and returned to finish a M.Sc. in Information Systems specializing in Software Engineering, we spent a lot of time on testing - professor is the author of one of the IEEE recommended textbooks. I still cannot get any call back for even an entry level job in my area. Any advice for an unsuccessful job seeker?
Thank you in advance
I think the real problem is that people don't know how to interview to find talented programmers. The best predictor of future performance is past behavior. 90% of an interview should be about past projects or academic work. Instead many people seem to have this weird notion that asking how many socks you need to pull from a drawer to get a matching pair gives insight into an engineer's talent.
It's simple: I demand prosecution for torture.
But having 80 people work for 1 hour a week is not any better.
...
Heh. It reminds me of a clever version that I've heard a few times:
If one woman can make one baby in nine months, how many babies can twelve women make in three months?
Unfortunately, many managers wouldn't understand why you would ask such a silly question
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Good programmers are not cheap. Most programmers are not good.
I can tell you that when i graduated in the great job vacuum that was spring/summer/fall of 2003 I was desperate for a job, the previous spring/summer i had sent out hundreds of resume's and used every friend of a friend contact i could, it was all for not, when i did actually talk to HR people they would say "we're firing 5 people this month, i doubt we'll have any interns this summer" so of course this led to no intern experience for me... I wish at the time open source projects where as available as they are now, but I didn't know anything about it... so there i was with a degree and no job, no insurance no experience and no way to gain it, i was working 12-14 hours a day as a handy man for my future in-laws(two sets) and filling out job applications for maybe another 2-3 hours a day, there was no time to join open source projects or program my ti-89 to do cool stuff, i went to sleep, so i could get up the next day and work for 10 dollars an hour to pay off the student loans, car insurance, food, internet, rent etc... It must be so nice to say get experience... when you already have it.
Checked exceptions (the ones you are forced to catch) totally suck and I completely agree with you. Fortunately this is a common opinion in the Java community and a lot of the open source third party libraries (Spring for example) agree and strictly use unchecked exceptions (those that derive from RuntimeException). There aren't really any disadvantages to unchecked exceptions. There are major disadvantages to checked exceptions. You can at least wrap checked exceptions in unchecked exceptions, for example, Spring wraps SQLExceptions in its own unchecked exception class.
After using Java for quite a while, I'm comfortable with it, it works well despite its few problems (some of which can be worked around), but I'm starting to feel the limits of it, and want to move on to something less restrictive. Java 1.5 was a nice improvement and makes Java a good enough language, but lately the ways I've been using it have almost been stretching it to do things dynamic languages are better designed for. Seems the open source Java community is pushing it in similar directions.
I'm going to try to improve my Python and/or Ruby skills and see how it compares. At least there are dynamic languages that run in the JVM (Jython, JRuby, Groovy, etc) so I can interface with existing Java projects if I have to.
I hate to say it - but odds are you aren't getting call backs because you are applying to entry level jobs. Start applying for mid and upper level jobs and odds are you will start getting call backs.
bad (i.e. incapable of doing any real production development) but talented programmers can easily disguise as good ones. That's what I do all the time.
Its not circular logic. I was in your shoes a lot of years ago. And I thought the same thing. Then I learned.
You need to go to a big company. Period. Several companies will hire new graduates, train them, give a decent wage and benefits. Companies like Cisco, IBM, et cetera. All of them hire new graduates. But smaller companies don't have the capability, training, and infrastructure to support the care and feeding of new graduate.
After two or three years at a company, you will be able to get a job a most places, and off you go. But you need to earn your stripes, man. Right out of school, you just aren't going to get into the places that the good programmers go to.
So go to the big boys, apply, earn your stripes, pay those dues... and we'll see you in the workforce in a few years.
As parent stated, when the problem to be solved is too easy, having uber programmer is useless since the works quality of average programmer and uber programmer is similar. At easy problems, you can throw many average programmers (with some consideration to mythical month effect) to speed up the work. At difficult problems, you must use uber programmers since 10 average programmers might not be able to progress at all
Therefore an efficient company should consider the problem on hand and employ a mix between uber programmer and average programmer. Morale will goes up. Nobody do extremely boring or difficult stuff for too long. Total of salary paid will be lower although it will commensurate to performance. Everybody's happy.
If you delay pleasure infinitely, the pleasure will be infinite. (YM)
Ok, so if everyone is only hiring senior developers, what happens when the last of them dies? This is the shepherds vs sheep equation. A lot of academies (including military) for example like to say that they produce leaders. Well, if they don't produce proportionate numbers of rank-and-file also, then who are these leaders leading?
The fact is, big projects encompassing a variety of specialties and disciplines do need a critical mass of programmers to fill those roles. And rarely do you ever get to pick and choose the perfect set of candidates. Some you win, some you lose. This is reality. It has nothing to do with software and everything to do with the law of averages.
And the fact is, if the newbies don't cut their teeth on real projects then they'll never become experienced veterans. That's part of the whole "experience" thing. Today's senior developers were juniors once. And that's how it always will be. Convincing people not to hire new blood is like saying no one should ever be treated by a new doctor. Which in principle has some validity, because everyone prefers the more experienced person, but this is precisely why hospitals regulate handing off patients and cases to new doctors -- they have to be sure that a doctor with 10 years experience actually has 10 years of experience and not 10 years of watching other people do stuff.
So sure, if you are a small, elite company go ahead and siphon off the best talent you can at any price, in exchange for not having to do any training. The larger and more willing companies who are willing to invest time in their employees are the lifeblood of the industry, and without them you wouldn't have any senior developers to hire.
...we won't work for them anymore.
Listen to my music.
Um, 'cos Joel's got 'em all?
Sorry, couldn't resist...
"Good news, everyone!"
Thanks for mood improving article. :D
>There's no one programmer who does the work of ten other programmers
Oh there is, I am one. I've had several occasions where I solved problems in a few days (or 4 hours once) that others were struggling at for months; some of these others were plain incompetent, others were pretty good.
I find that I'm pretty unique in fitting the right tool to the problem at hand, as well as in general overview. I've never met anyone as productive as myself.
I'm posting this anonymously, because I have to work with others, and one of the things you cannot do is alienate everyone around you; one sure way of doing that is being more skilled than them in all job related aspects.
It's not just computer science, the schools aren't training people to -think-.
I just spoke to a friend of mine, a trucker, about this. A majority of office workers and people in support jobs have exactly one reaction to minor obstacles: stop dead and wait for teacher to come around and lead them through how to solve the problem.
Office workers he deals with think he's some kind of super-genius because he can walk into their office and work an unfamiliar fax machine. One gal asked, "How did you DO that?" He answered, "There's a LCD screen on the front that tells you exactly what to do; you READ it."
He's helped his grandson move from being a D average math student to an A+ average in one year by teaching him how to solve math problems in general, rather than how to solve THIS specific type of problem.
"Not if you have a secure project, you can't. Reason #1 to get a security clearance: you can't be outsourced." Depends on what's classified and how you partition the design off. It's like the movie CUBE give every programmer a little task and nobody understands whole system. So you have the US guys do all the classified stuff usually a couple .h files and give everything else to overseas programmers. Ya all those GUI wrappers and functional blocks that do some task. System integration is painful but it can be done.
I think this guys got part of the argument, but the real argument is that code has to perfectly describe the job it has to do without being overly complex or to slugish. Juniors are great, but you should always have their code reviewed at least twice by senior programmers and you should always have a senior programmers code reviewed once, you could even go the whole hog and use XP as a development process and get continuous review by lots of different people.
You need to do all of this because if the code isn't "perfect" then your going to have bugs and bugs mean bad data coming through, unreliable software and never ending maintenance of the software.
A lot of software also need to be future proofed to some extent so that new features can be added for the next release and that required practices and disciplines that junior developers won't have.
But in the end a good programmers a good programmer, you'll get a lot more out of a junior whose a good programmer than you would out of someone with years of experience in many different fields who couldn't program a good solid application to save their life. And probably the only way of finding out if someones a good programmer is talking to them in an interview and putting them on a few months probationary period. (of course a good mix of jobs that have been held for a reasonable length of time mixed with a reasonable amount of open source development should give you a pointer in the right direction) and if they've done open source work then at least there's some code you can look at!
thank God the internet isn't a human right.
Is it surprising that finding good people is the hard part? Is it any different than the effort it takes lure a world-class CEO to run your company in hopes of making many times his salary/bonus/stock options in return?
Most companies are lazy, and don't try to measure the value of any employee in a company, just hire people to fit a job description and cross their fingers. To make matters worse, after hiring the wrong person they don't know how to get rid of them. Is all this really a revelation? People are lazy, and as implied all over the article and the comments to it, not enough companies seem to try hard enough. Is it not like buying a lotto ticket and hoping your numbers are drawn to be rich? Finding the right people vastly improve the odds of the company's success. That's what it's all about. End of story.
Good, but not as good as "The Rise and Fall of the American Programmer".
Probably. People also have synchronization problems at school (althoug I used to solve mine with a bit more of engeneering and didn't touch version control untill last year). It is not that hard either, that shouldn't be at a interview questionary.
That is normaly mandatory. And several times. How do you think people learn to write operational systems or device drivers? By looking into Linux and BSD code. How do you think people learns how to write compilers? By looking at other compilers' code...
You mean testing (a fomral discipline), (reverse)engeneering (both formal disciplines) or simply understanding the code (like above)?
Now you mean testing. That is a formal discipline, people normaly learn those at scholl.
You mean knowing theory, not just practice? It is people that didn't go to scholl that have problems here.
Those you don't learn at scholl. To be honest, the last one doesn't seem to be aquired with practice either (at least work practice). But people with experience on a lot of dfferent systems (that you normaly get from school) have a easier path toward the first.
Rethinking email
I've hit the downside too. Our company's in a financially tight period, so we've reduced are headcount. As a result, I'm back in the production area building and testing product. (Somewhat high end, we're talking $30K a piece). I'm back there, despite being the number two technical guy who actually designed the stuff, because I'm the only one who can do it at this point. Yes, if our volume was a bit higher we could higher technicians to do it, whom I could train, but we're not there now.
However, despite being a fairly unpleasant time to be working here, the last few months have been very educational. I had the epiphany that employees assume management knows a lot more about what's going on then is actually the case. I'm not talking about internal politics. Do you think you know where your company's revenue is going to come from in the next three months? In most tech businesses, nobody has a clue. We all groan about PHBs, but most of us assume someone is watching the store. It ain't necessarily so.
So I'm doing things I think are unpleasant because they need to get done, and I'm doing them well enough. I'm keeping it up because there's a possible payout, and they continue to pay me on time. I don't think I can stand it past the end of the year, but as I grit my teeth through it, and watch other people grit their teeth, I'm getting a terrific lesson in what an organization needs to do to survive, and how to make sure those things get done.
It's not wasting time, I'm educating myself.
I may be abnormal, but I always ask for code when I get job applicants.
I'd would rather read a chunk of 5,000 lines of code (obviously, spread out in multiple files or projects as applicable) before I read the details of your college degree.
With a reasonably large chunk of code, you can get a good feel for how they code, what style, what level of sophistication (php html+code mix vs mvc setup type stuff) are they at, do they comment, do they test, did they give me the code in the form of a URI to their personal SVN repository, etc etc. Once you've read enough code, you can tell a lot from it.
Assuming you wrote it and it's not outright fraud, that says more to me than most of the rest of your resume.
Code you wrote at another job, generally I'm not going to be allowed to see it.
So it needs to be YOUR code!
Wrote a web-based tracker for your share-house expenses? Show me that?
If you write Perl, do you have any CPAN modules? HUGE indicator you "get" mature Perl development.
In short, I don't particularly CARE if your experience if commercial or not. I just want to see some evidence you know what you are doing.
Focus on the 12 years you worked in the industry. Make a list of everyone you worked with. Don't be cautious with the list. Include even the most junior people because some of them are now hiring managers and they will remember you. Track everyone of them down and make contact. Let them know you are looking. They may not hire you directly but they will know someone who is looking.
That's actually wrong.
A lot of the estimates of 100 fold productivity estimates in Peopleware etc come from coding competitions in which different programmers were given fairly straightforward projects and measured on how quickly they did them, the quality of the product, etc. So even on apparently simple problems, there is a huge difference.
Furthermore your advice suggests that you should have a lot of people in the organization. In large organizations, that may be unavoidable. However research on team size says that for medium sized businesss projects (10K-100K lines) the calendar time to complete a project hits a minimum with 5-7 developers, then doesn't recover to the same level until you have 15-20 developers. (Note that the 15-20 developers spent a lot longer developing, and are bound to have more frustrations.) I know of no published comparison available on quality or functionality, but I have to think that 20 people developing a 50K line project won't have the same internal consistency in the result as the output of 5 people. So I bet the small teams actually accomplished more in their projects, and I suspect they encountered less frustration while doing it.
That strongly suggests that for most business projects you should aim for small teams of at most 5-7 people. When you put highly productive people in those teams and use languages intended for rapid development, the result can be quite astonishing to people who aren't expecting it.
I have seen this many times: Companies often have a toxic culture and no one in their sane mind would ever want to work for them unless they were desparate for a salary. Unfortunately these companies prefer to hire desparate below-average developers rather than fix their culture and seek to create an environment that attracts top talent.
What companies ought to is to design a healthy corporate environment first and make sure it gets a good reputation. The right people can then be found and attracted easily.
So, if you are a manager and you can see that your corporate environment sucks, do not be tempted to hire desparate people just to fill some empty seats. Try to fix your culture as much as you can before seeking to hire, and focus on finding quality people.
The term "Spaghetti Code" doesn't refer to whether the code works or not, it's code who's path of execution looks like a plate of spaghetti. i.e. lots of gotos.
You can also get spaghetti code with stuff like shell script A calls B, which might call A, B, or C.
I've see some real spaghetti code in my life, but thankfully unless it's written in BASIC or assembler, I don't see a lot of it anymore. (Garbage code, on the other hand, is everywhere, and in any language)
All ideas^H^H^H^H^Hprocesses in this post are Patent Pending. (as well as the process of patenting all postings)
Programming is 10% knowing the programming languages at hand and 90% being able to design algorithms, knowing the problem domain and knowing some form of development procedure. It is no wonder that inexperienced people are not preferred by companies.
I was once part of an interviewing team, so I saw the other side of the coin. Surprisingly, 95% of the people that came for an interview were very sort of knowing anything truly significant about development. I then came to the conclusion that what we are taught in college is almost irrelevant (with the exception of hard CS stuff, like how to make compilers). I learned the principles of Pascal when I was in college, but that has nothing to do with development of applications. I did not learn the thought process of development, how to recognize the problems, how to co-operate with others, how to handle errors, how to see through what the customer says, how to break down problems, etc.
I think any good programmer can easily tell which programmers are good/great/uber. In your case just try to see which ones ask the right questions, rather than focusing on what they assert.
It is for the average manager without any meaningful programming experience that is hard to tell. Probably hard for mediocre programmers too.
We are Turing O-Machines. The Oracle is out there.
The more people you put on a project, the more overhead there exist in communication, coordination, etc. The per person produtivity inevitably goes down. This overhead could easily be half the effort when you get to a 10 person team. So the uber programmer could be only 5x more effective and still match a 10 person team.
for the right job. These languages are optimized for different kinds of problems. It's futile to compare them.
Furthermore, this reinforces the point of the article that the most important aspect of software production is NOT implementation languages. Architecture, process, testing, interface, etc. matter much more. You're looking in the wrong place for productivity.
This is understandable, considering that the person who wrote the article is/was a programmer him/herself. This is my non-technical, management-level summary of his points:
1. "Expert" programmers want managers to recognize them as good, and all other programmers that do not generate as much code as them as bad programmers.
2. "Expert" programmers want managers to recognize that they deserve more money than all the programmers that do not generate as much code as they do.
3. "Expert" programmers do not like to communicate. They view communication as a waste of time and think of less communication as a pro.
4. "Expert" programmers do not want to acknowledge the existence of anyone who is better than they are. Because if there was someone better than them, then they wouldn't be "Experts" anymore.
5. Despite viewing communication as inefficiency, actively wanting isolation from each other, "Expert" programmers promise that "things will just flow."
6. People should be judged on the quality of their work.
Am I wrong in thinking that maybe the article is...a bit obvious? He ends with the following aphorism:
"As with many things in life, sometimes you get what you pay for."
I don't mean to be rude, but can I please put a "duh" tag on this?
In the agile world, the best teams are supposed to be made up of "generalizing specialists." These are folks who have one or more specializations, but who also have a working knowledge of many systems / technologies / business domains.
p ecialists.htm
For instance, not everyone on the team might design a database as well as Joe, the database savvy guy, but everyone on the team has a working knowledge of databases and could design one. Not everyone on the team might be able to easily write our deployment/automation scripts, but everyone on the team is familiar with how these work and could modify them. Not everyone knows exactly how our server clusters are configured, but everyone knows enough to safely work with the servers.
Scott Ambler has a good article about "generalizing specialists" here: http://www.agilemodeling.com/essays/generalizingS
To begin with, it might sound like it doesn't leave you with much job security if everyone knows a good bit about everything, so you could lose any member of the team and the project would survive. That's potentially good for the project as "Joe could get hit by a bus," but it's also not true, when it comes to job security. Those who learn the business model and the ins-and-outs of our system become huge assets to the team, and to the company. We would be far more likely to lay off someone who isn't willing to learn new things. What's the point of someone like that?
I think the single best way to find good programmers is to find enthusiasts.
:-)
The reason is that it's easier to determine how enthusiastic someone is than how good a product they develop:
- enthusiasts usually have side projects
- enthusiasts often create libraries of code that can be reused
- enthusiasts will have a variety of favorite tools - and can explain why they like them
- enthusiasts will likewise have a variety of favorite methods - and can explain why they like them
- enthusiasts read widely in their field
- enthusiasts know the names of those who have made impacts on their field
- enthusiasts often find themselves putting in too many hours - because they *enjoy* the work
- enthusiasts gravitate together - put them in a room together and you'll have a lively conversation
And there are technologies, methods and tools that attract enthusiasts. For example, I've found that even if python and ruby aren't the most marketable languages out there - they are great ways to find the enthusiasts.
Of course, this won't help a manager that lacks enthusiasts on his team. But a technical manager who is himself an enthusiast, and builds such a team should be able to easy find more. At least in my humble opinion.
Someone with tons of Java experience may not know all of that either. The thing is, a great programmer will be albe to learn them, appreciate their value and understand their shortcomings, while a mediocre programmer won't. A good programmer with no Java experience will be able to learn the basics of Java in two weeks, and will then be able to learn the basics of various libraries and frameworks. In a couple of months he may understand the intricacies of various J2EE implementations, when to use hibernate, the advantages and disadvantages of various web frameworks, etc. Experience with a few existing frameworks won't help you if you're unable to understand why a new one might be better.
When hiring a temp or a consultant, you're better off hiring someone with the experience you're looking for, but when you're hiring a new employee, I really hope you're planning to keep him for longer than a few weeks. Ability pays off in the long run.
"Are you an ASP.net programmer?" I am asked often.
I will follow your advice; Thank You all.
I have almost 15 years of .NET experience. Back then we called it Win32. :)
To the GG[*]P:
Kids these days. Bah.
Pay your dues: spend years debugging shitty code, written by stoned company founders, in obsolete languages, on hardware that can only be repaired by buying parts on eBay, on obsolete architectures, for companies that nobody's heard of, in financial trouble, in cities you'd be hard-pressed to find on a map. Don't forget to spend your weekends and holidays learning the system top to bottom. From microcode to reporting. Everything. Learn the business model too. And do it for cut-rate rates just to get the break.
And be happy for it, goddammit.
(My break? Sales tracking, "Mr. R", CADOL, Tiger-8's, minicomputers, Contel, bankrupt 1993, Burton MI, for $17,500/year in 1989. Not much, even then.)
Before that? Data entry clerk at a different company. I punched freight bills all day long. 8 hours/day in a room full of middle aged gossipy women, keying bills of lading. Evenings spent reading the system manuals, learning it inside out, doing whatever I could to optimize my job. When not doing that? Hacking code on whatever computers I could lay hands on. Writing plug-ins for BBS's. Modules for the newly installed local library computers. Laying cable. Assembling desk-side computers.
If you're any good, I'd give you the break.
Don't expect good money and you will get the shittiest jobs I can find. Only become a programmer if it's what you really want to do. Do it for free. If you're in it for the money and a desk job keep moving, boy.
Impress me, and we'll talk.
Get off my lawn.
> These days, being a programmer generalist (even worse, one with admin experience) just increases the types of shit that get dumped on you..
.NET solution that runs right only on IE. Unix admins work on the command line. Internal Systems developers know exactly fuck all about Unix. Nobody uses the "solution" and we get blamed by association for its egregious nastiness.
.dll in their BillyWare), do not know what a linked list is... They are, in brief, incompetent morons. I have theorized about the cause and effect of this putrid situation at incredible length. It just seems to be the case that some folks are compelled by nature to work from first principles, and some are content to accumulate seemingly random senseless facts about systems that will be for them forever completely opaque. The first principle people become your theoretical physicists and top gun *nix admins and the like. The fact accumulators, who are just flat out intellectually inferior, are best suited to the help desk or project management or some such. The fact accululators invariably arrive at "development" by making office apps out of Excel macros and Access crap. Management, in all its abject stupidity, cannot differentiate this from real software. Voila! The lowly fact accumulator is thus Peter principled into "development" and is now officially the hell in my way.
I would love nothing more than to have management give me the whole works and get the hell out of my way while I complete the project. I am a Unix System Admin at a fortune 150. I specialize in system programming. Every so often we get a wish list from the generalist admins and danged if it doesn't have some real good ideas on it. This is a source of project ideas, but most of our programs start as band-aids.
Here's the deal. Trench admins are outstanding triage people and they can write a mean quick & dirty shell script which will fix the immediate problem. If the problem was interesting enough, they'll email the details of the cause and solution to the group along with the {box}:/path/to/script that they just wrote to fix it. We in coder land monitor the use of these scripts and if one of them is used a lot and/or manages to get itself into an automonitor program that starts generating a lot of false negatives (or, in theory, positives) we will review it and add all of the invariably missing return checks, usage functions, man pages, additional functionality, &etc. Some of these puppies grow to behemoth proportions and require a far more sophisticated user interface than we can easily manage in the shell. At this point there is a terrible danger that one of our managers will discover the thing and "help" us out by trying to raise money for a formal Internal Systems development project. God forbid he actually gets funded. Now we can't just pick the tool for the job and knock it out. We have to wade with these sorry people through months of requirements gathering, use case analysis, prototyping, alpha- and beta-testing, and all of the other horseshit that happens to occur to whatever utterly superfluous project manager is assigned to the thing. In the end the "developers" in IS will puke forth a
I have determined quite conclusively that these fucking IS morons have never heard of a finte state machine, cannot process CSV files (buggy
The sorry fact is that all of the decent software coming out of my little group is manufactured by stealth. We develop very solid software in spite of our "helpers." Unfortunately, the only way to change this mess is to go into management and spend enough years playing petty political games and garnering good relations with stupid people to start to make a difference. First principle people simply can't do it. We'd vomit explosively at the first opportunity to compromise technical elegance for expediency. We can just write a book exposing the whole process, but The Mythical Man Month is already there. Management can't learn from it. They are not incented to learn from it. They are incented to find more shit to manage. And more shitheads. And the cycle of poo continues.
Hope this helps!
I want to be the guy who gets to type the ; at the end of all the code lines!
Now that is specialization!
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
3. The third guy who keeps busy but is not stressed out about it, once he is done with his work he actively goes find more work to do. Does his job gets things done on time, on spec...
Guy Number 1 is not efficient and has emotional connection to his work on a level that he feels threatened when he makes a mistake, any success is greatly exaggerated their login passwords normally have the word god in it. Because it is all about Ego and not about getting stuff done.
Guy Number 2 is a good programmer but he is lazy in the fact that because he is a good programmer he could be more efficient. If that guy is working on a project 25% of the time and doing nothing the rest vs. say #3 who may be half the programmer he is but works all the time and if he finishes he finds himself more work... So for the sum of work done #3 will get twice as much done over #2 just because he is willing to go that extra step and try to give himself more productive work.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
"For example, if the shop language is FOO, a good programmer who has X years experience doing all kinds of different development in a few languages, and is willing to program in FOO, can do better than the average programmer who has X years experience in FOO."
And you base this conclusion on what? Gut feeling?
After failing to fix the heating system at a factory, management called an old-timer out of retirement to repair it. The old-timer went into the boiler room and returned an hour later. The problem was fixed and the system worked beautifully. A week later, he sent in his bill: $16,000.00.
Management balked and demanded an itemized invoice. A week later they got it:
quiquid id est, timeo puellas et oscula dantes.
I also have the similar experience -- in a place where I match a job description perfectly, the HR person will not quite understand what s/he's hiring for, and disqualify me, and possibly other candidates. I've also seen many many many many recruiters who are 'playing the numbers' with candidates -- they will blast out an email to 500 people that show-up in a Monster search, and not really put all that much effort into filling their req. Lots of this and other kinds of treatment from the recruiting and HR sides, forced me to put together a web-based list of recruiters, Recruiter-Rater.
Zhrodague.net - I do projects and stuff too.
I'm a programmer (of sorts) because I want to build tools to get my job done.
I'm an EE by training, but I got my s/w feet wet about 20 years ago when I joined a project to build automated test systems. A couple of mechanical engineers got tired of writing test specs, sending them to a coding group who coded test routines, reviewing the results (since s/w people have no clue as to what was actually being accomplished), marking them up with a big red pen and sending them back. So we sat down and wrote some natural language processing tools. System requirements documents in ---> ATE instructions out. Simple. We saved the company about $20 million a year by cutting huge test coding groups out of the middle of the process. We also made the IT department's 'most wanted' list.
Eventually, IT took the project over. After all, it was software. This first thing they did was insist that everything get ported to Windows. The second thing they did was to throw out all the natural language processing tools, since 1) they were written by MEs and EEs, 2) they dont't run on Windows, 3) they couldn't have a bunch of *NIX machines sitting around and risk not getting invited to Bill Gates' CIO dinner, and 3) they didn't understand how to they worked. That they actually worked wasn't an issue.
Fortunately, when one saves the company a few hundred million dollars over the years, one is quite well rewarded. I retired and do some consulting work in the EE field. I still get the opportunity to do a little coding, but when the contract specifies implementing {insert buzzword here} technology instead of actually getting work done, I can afford to walk away.
Writing code for the sake of writing code is like becoming a mechanic so you can play with the tools but you don't want to learn how diesel engines work.
Have gnu, will travel.
I'm going to take advice on hiring writers from an English cool-aid drinker. Sure, just the very minute I get my brain replaced with a cauliflower. English is an horrifically bad language. It's full of pronunciation and grammar exceptions and idioms. It enables great writers to write nuanced texts, but can make good writers produce unintelligible documentation, and makes bad writers think they r the 1337. Feh. A properly trained, incentivized and provisioned Esperanto team can run rings around an English team in terms of clean text produced, as well as (more importantly) cost to develop and cost to maintain, since it's so uniform in its phonetics and syntax.
Expressiveness in a language can be used for good (see Perl::Critic) or evil (obfuscation).
For having all the documentation and tools available to you to actually fix the problem, he didn't ask for too much.
We've had an issue with one of our really old dated systems (94') which is proprietary. The company wanted to charge us $10k a day to have a lesser tech come and work on it--as much as 3x more for a qualified technician. The cost could be justified as the problem was causing potentially thousands of dollars lost per a month due to lost productivity with the tool, however, there was no guarantee on their part that after a day of work, the problem would be fixed. So me and another engineer decided to see if we could determine how to fix the problem and after just under a week of searching (in addition to some of our other activities) we found it. So the company problem lost about $3k for us to spend time working on the problem but didn't have to pay up the vendor for support and saves on improved productivity with the tool.
So in my book, your uber programmer charged a low rate for a lot of work.
Sadly, a typical situation being presented with the wrong job, as a result of corporate miscommunication, bad product selection, accretion of code from various sources, recent FEMA appointees, etc. Considering the frequency of this, I've frequently found Perl to be the right tool or a good tool for the kinds of work that falls out from these situations. It's at least good as a prototyping tool to extract data from various sources for closer examination.
Really, the big difference between a great programmer and an average one is that the great ones know how to think through a problem, figure out how to express it succinctly, then start coding. It's not really possible to code something unless you understand what you're trying to accomplish.
The worst are posted job listings with impossible requirements such as:
"Must have 10+ years of Vista experience"
or
"Must have at least 7 years experience with C#"
You know some retards in the HR department wrote those. If a company is really that dumb, you have to ask yourself if it's a place you want to work at in the first place.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
Had you read the article you would have seen the author link to the mythical Man Month. Instead you lamented that the author "discovered" it on their own - by not reading the article. There is some irony in there somewhere.
/. articles of course.
Besides, individual discovery of the same principles is a *good thing*. It serves as a validation in the same way that scientists who individually discover the same mechanism validate the discovery. This is in distinct contrast to duplicate
My Suburban burns less gasoline than your Prius.
There's no one programmer who does the work of ten other programmers.
The thing is, that depends on your metric. If you're measuring useful work done, in terms of actual problems solved and perhaps with some sort of cost and/or speed factors built in, then it is entirely possible for one great programmer to do the work of many mediocre ones. This is for three reasons, and I think most people only really think of the first one.
Firstly, contrary to what you wrote about the size of a problem, I think it's clear that a good programmer will generally solve a problem of average difficulty faster than a mediocre one. The point here is that the two will not most likely come up with the same solution. Each may solve the problem, but the good programmer's solution will typically have a clearer design, be more concise in the implementation, have fewer special cases to deal with, be more flexible when it comes to future expansion, and come with useful tools as needed. So that's your first win: the good programmer comes up with better solutions, which tend to be faster to develop than mediocre ones.
The second win is usually bigger than the first IME, but it's the one most people overlook. A programmer typically doesn't just write new code. In fact, writing code is usually a relatively small part of how he spends his working hours. Usually, he also has overheads such as investigating bug reports and documenting what he's doing for future reference. Because good programmers tend to have cleaner designs and higher quality implementations, they can spend far less of their time fixing bugs, and they usually don't need to write as much to document their code to the same standard. Because they incur lower overheads, they have extra time to spend writing code that solves the next problem, and the one after that.
Finally, there are the indirect benefits. If you have a good programmer in a development team, then typically any smart designs, time-saving tools, useful implementation techniques and the like that they create will filter through to improve the productivity of other team members as well. This applies to some extent whatever the skill level of those other team members. Non-experts will learn from the expert, and be able to do things they otherwise couldn't (or at least couldn't do as fast) thanks to the expert's tools and techniques. Multiple experts will gain from bouncing ideas of each other and getting informed second opinions before committing to something, resulting in less work changing things down the line.
It's true, as you said, that some problems are simply too hard for programmers below a certain level to solve at all, and for those you need someone above that level. It's also true that some problems are so easy that almost anyone would produce the same trivial solution just as quickly. But in real life, most problems fall somewhere between these extremes. For the three reasons above, I think it's wrong to pretend that great programmers won't be more productive in dealing with those. When you combine the direct speed benefits of a better design and implementation, the lower overheads, and the support given to others, an order of magnitude or more is easily believable.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
As a programmer and student of mathematics, my personal philosophy on the issue is:
Nothing you have to reason that is obvious is ever obvious. As soon as you think that something is obvious, you will make and find mistakes in precisely this 'obvious' issues. In other words, I, you, and almost all people make mistakes in what we think is obvious.
Thinking that nothing is obvious makes you methodic and disciplined, and that's a good thing.
We are Turing O-Machines. The Oracle is out there.
Look at google or berkshire hathaway
As long as you retain control you are ok.
* = The gap appears to separate compiled languages from interpreted languages. I've personally written a toy dynamic functional language interpreter with a JIT compiler that fell inside the gap, ahead of Erlang and Lua but behind Fortran. The primary goal of that project was to test the feasibility of compiling a rapid-prototyping language. If I had more time (only spent a couple months on the project), I could have added inlines for the type inferences, SSA, and other optimization tricks, so I think I could have cranked it across the gap, and I definitely agree that it should be possible to make a dynamic language as fast as Java.
In fact, I just had a recruiter call+email me yesterday offering a position that seems to involve:
- AJAX, Dojo Toolkit
- JavaScript
- Simple HTML/CCS stuff
- Travel to various N. American major cities
Now I've communicated with the recruiter, and she hasn't really been able to explain the position beyond that. I'm sure that there must be some database work involved, and likely some scripting... but they couldn't tell me anything more about the position. It's really hard to get or provide more info if you don't know whether you'll be using MySQL, Oracle, PHP, or ASP. Actually I've worked with all of those, but some more than others (haven't used ASP for a long time).
So today the recruiter sends me a form (from the employer) that has a bunch of Java-related questions and some database related stuff (it doesn't say which database though). It's a "matrix chart" done in excel, which doesn't even add up the scores in the columns. You fill in a score (which I'm assuming is your comfort-level/experience on a given topic) and add comments. Add to that it's by email, so if I wanted I could have googled for appropriate BS to fill the thing in and really known nothing. I emailed back saying that I don't know Java, and that JavaScript and Java are two quite different things. The response is that the only requirements are: HTML, JavaScript, AJAX, and Dojo, but the client supplied this general form and fill it out anyways please.
So I fill it out, filling in some of the stuff in the Java sections, and add comments giving myself 10/10 on stuff like typecasting or overloading, but add comment on the java-specific stuff as "Java Related, not JS/AJAX related." I'm rather sure that the position itself does involve Java work and the recruiter just doesn't understand the different between JavaScript and Java, but saw that I've used Dojo and it was a required buzzword.
Seems like we've just wasted a whole lot of my time, and the employer's. It could be that the employer didn't state the position requirements well enough either, but for a "technical-position based recruiting company" the recruiter really seemed to not understand a whole lot.
I'm hoping I get to talk to the employer so I can discuss this, and politely decline the position but ask them to hold onto my resume. I'm more in the SysAdmin game these days, and even if the job was just basic web stuff I think I'd be a little overqualified, even at the offered $62k/year. All in all the company itself is supposed to be in the top 100 employers, and would probably be a nice place to work for, so I'm just going to be honest and polite about things, and maybe it'll net me a good job contact for some other position that I'm more suited to...
It's sad though, because at first I was rather happy to be contacted. Despite having my resume+covers updated, checked, and generally looking pretty darn good, I've had much luck getting past the recruiters or tier-1 HR people. I wonder how many people nowadays BS their way into a position like these, and/or if I'm being too honest in general, but I really hope that recruiters/HR-people that are looking me up for other position are a little more knowledgeable of the what to look for in candidates.
Indeed, it has been much the same for me, which always seems to confirm the old adage "it's not what you know, it's who you know."
This is understandable, as having somebody with a solid reputation who can vouch for you is generally the best form of reference, and a more reliable one than a resume that might be 10% fiction and 50% exaggeration.
However, there are many situations where one ends up without references. In my case I'm in BC, Canada, and I'm nosing around positions in the Toronto, Ontario region (about 4000km away). The only people I know there are a few family members and my girlfriend, both of whom have tried to offer help but unfortunately aren't really connected with my industry. So it's just my resume against a few thousand others.
I've gone so far as hooking up with the LUG in Toronto, but thus far I've found little in the way of permanent position (just some contract work filtering through). I was even there on holidays for awhile, and while I met a bunch of people who were also interested in contract or general-tech type work, there's nothing for a SysAdmin/Developer type person that I've run across. The question becomes, where does one search, or what is the magic gem (short of lying) to put on one's resume?
That always depends on what you're doing with it. I still wouldn't write a game engine in a "slower" language, because it really would be slower, and my competitors (using C++) would kick my ass in benchmarks. But, I might write the AI and game logic in a language like Python -- and this is often done.
What seems to be the common attitude now is to write high-level stuff in high-level languages, and low-level stuff in C, then tie the two together somehow -- for example, either embed Python, or write a Python module in C. Another common attitude is to rapidly prototype something in a "slower" language, then re-write it in a faster one, now that you have a good idea what kind of program architecture is going to work.
I think that all of these are good strategies, when high-level languages are slow. I just think that if high-level languages were fast, we wouldn't need things like C.
Well, what is sometimes whispered in projects like Psyco is "faster than C".
Here's my reasoning: The killer features of a language like Ruby are its dynamic nature. You can go in and tweak any part of your program on the fly, or, indeed, chunks of the language itself. In fact, large parts of Ruby are written in Ruby.
The killer features of a language like Java are its speed and its static nature -- it makes it possible to do many more anal-retentive checks at compile-time.
Now, Ruby, Perl, etc could easily be made to emulate the static nature of languages like Java. In many cases, best practices can be enforced at the IDE/editor level, or with grep. And I think it's far better to be able to have these things (use strict in perl, for example) and be able to turn them off, than to have them forced on you by the language, so you spend a lot of time working around them.
So, the big difference is speed. And I think "slower" languages are slower primarily because they are so dynamic -- it means that things which Java can throw away at compile time must be kept around by Ruby even through runtime.
For example, suppose you want to add two integer variables and store them in a third. Compiled languages can optimize this down to practically assembly-level instructions at compile time -- 2 + 2 really becomes simply adding 2 and 2, and storing the result in some location in memory.
Compare that with what Ruby has to do. First it has to convert those to objects, so we now have two Fixnums, each with a value of 2. It then has to call the '+' method of Fixnum -- so if we're adding a and b, it has to do a.+(b) -- and it has to do this kind of stuff on the fly. That is, it has to look up each variable by name, then look up its class (again by name), then the method being called (surprise! by name), and finally it ends up with some code to run that's roughly the equivalent of 2+2 in C.
I think that even the majority of Ruby code doesn't need that kind of flexibility. It's nice from time to time -- if Ruby can't find foo.bar, it'll call something like foo.method_not_found('bar'), which can allow fancy things like automatic RPC or loading of libraries.
But it also forces Ruby to be as slow as JavaScript.
I do actually have a solution, but I think this post is long enough as it is. But I will say that I think it's a problem. Right now, I can write any kind of app I want in Ruby, it'll just run slower. And I can do the same thing in Java, and it will run faster, but take longer to develop. Which means there's a certain class of applications which can't be developed in Ruby (they need to be fast), and a certain class that can't be done as well in Java or C (they need to be dynamic), and probably a class of apps that can't be done at all (they need to be both).
Don't thank God, thank a doctor!