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.
that is all.
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?
Instead of only hiring cs people with degrees in engineering and cs, broaden your horizons. You may be pleasantly surprised at what someone who has learned programming from a different background can bring to the table.
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
Uber programers do exist, and yes they are paid very well, but it would be an HR nightmare to prove that Johnny X does the work of 10 people so he should be paid what 10 people are, thus the reason it is not done.
CS: It is all sink or swim...oh and did I mention there are sharks in that water?
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.
The problem is recognizing who the great programmers are. Sure, he may be worth an extra 100K a year, but it requires a tremendous expenditure of managerial time ( which, contrary to prevailing opinion on /., is worth something ) to monitor the situation closely enough to figure out that he is worth it.
And this presumes that you indeed have an uber-programmer. It is quite possible for management to spend a lot of time ( ie:money ) and still not find that their programmer is any better. The net result of trying is a loss of money.
This probably applies to a lot of other 'guru' type professions like lawyers and doctors. You can't understand it yourself, so you pay the going rate.
I worked for a company that got bought by a bigger company.
We had an über programmer. He left because rather than exceptional pay, he wanted good enough pay and a small company style work life.
We then got in a pickle where some kernel mode drivers for NT4 needed to be revised and SoftICD'd in. Even though he doc'd everything and gave training to our programming staff about gotchas and pitfalls as well as maintenance, it was something that only about 100 people in the world could really do. All we could get done is a widely variating series of BSODs. We hired him back at $12K/day + travel for 5 days of work. He did work his ass off, further document everything, and provide additional spot training to our two brightest. The job was done and he had a check for $60K. I suspect that the training and docs took the vast majority of his time. I asked him why so much (and why MegaCorp would pay that) and he said it was simple. They were a big company not interested in paying him either in lifestyle changes or money so he didn't stay, but for a short job he charged what it was worth.
The free market did work. (considering his solution was cheaper than a contract with MS for the same work by $40K).
-nB
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
But I think that if the über-programmer really does exist, then eventually the free market will figure that out, and compensate him accordingly.
It has, and then some. These "über-programmers" are what you and I know as "wildly successful startup founders." Part of the reason it's so hard to hire them is because they are mostly already independently wealthy and / or personally invested in a project of love that no offer of cash and benefits will draw them away from. Most likely, if the former is not true, the latter will eventually cause it to be true. The best and most common way of hiring an über-programmer is to buy the company they currently work for.
Unpleasantries.
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.
He's absolutely correct.
h tml.
There are numerous studies to support this. Taking about 20 seconds to look for one: http://www.joelonsoftware.com/articles/HighNotes.
Also take a look at "Code Complete" by Steve McConnell and "Peopleware" by DeMarco and Lister. Actually, I've seen credible estimates of a factor of 25 times productivity between best and worst programmers. Given the negative productivity I've witnessed, even this may be an under-estimate.
This should be a well-known fact but it isn't. A major part of the problem is cluelessness by the people doing the hiring. You probably can't scale salary by productivity but how about something like the square root of productivity? Of course, the hiring of Bob Nardelli, the mediocre CEO who did nothing at Home Depot, by Chrysler shows how unrelated salary and effectiveness can be.
...the mythical man-month?
>why should companies favor hiring fewer more senior developers rather than many junior ones?
*swish*
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.
It's a "perfect world" situation, because it depends on your experts really being experts, and we all know how often a loser with experience is hired into a position they aren't qualified to fill.
Not only that, in the absence of Junior programmers, you have nobody to promote to the Senior position. Which I guess is great if you want to whine to the government about how hard it is to find skilled workers that were magically endowed with their Senior-level prowess.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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:
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.
... is still looking for a senior programmer with 15 years of .NET experience.
Have gnu, will travel.
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.
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.
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.
Not really. The uber programmers rarely have the skill set needed to found a buisness. Those tend to require high people skills and financial skills, which are almost completely disjoint from the programming ones. Plus it would mean spending time doing all that bullshit, instead of programming.
The real answer is that most uber programmers work for that small premium. They get to do what they want, get a few other perks like their choice of assignments, and are generally happy as is. Money isn't really the key motivator for them- if it was, they'd be in another field that pays more.
I still have more fans than freaks. WTF is wrong with you people?
Finding decent Perl programmer is really hard thing, if ever possible... :-)
There's no one programmer who does the work of ten other programmers. One uber-programmer does just as much work as one ordinary programmer. It's just that the results solve ten times as many problems. Programming is fundamentally a design problem. A great bridge designer doesn't do the work of ten lousy bridge designers; the great one designs one great bridge in the time it takes the ten lousy ones to design ten lousy bridges.
The best approximation is that each problem has a certain complexity and a certain size. The size determines how long it will take, and it doesn't matter how good the developers are. The complexity determines how good a developer is needed to make progress at all. If you've got only easy problems, an uber-programmer doesn't help you much (unless the programmer can find a smaller, harder problem that replaces the big easy one). If you've got a hard problem, ten average programmers will work on it forever without getting any results.
And there's one last thing specific to computers: the computer can solve easy problems for you, but making it do so is a hard problem. But solving that one hard problem (plus some processor time) resolves a lot of easy problems. Another type of hard problem is writing a magic library function that makes a range of moderately hard problems easy enough for average programmers to solve.
If you've got ten people essentially doing data entry, an uber-programmer may be able to eliminate the need for them to do that at all. If you've got ten developers working on some problem, an uber-programmer may be able to double their productivity. In either of these cases, the uber-programmer directly produces something that isn't part of the actual project, but the benefit to the project is on the order of ten average programmers' work. And, if the uber-programmer reduces the complexity of the problem to put it in reach of the rest of the team, no amount of ordinary programmers' work would benefit the project as much as the uber-programmer's contribution. Of course, if you require an uber-programmer to literally do the work of average programmers, there's no benefit at all.
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.
Your wish is google's command:
http://dribibu.xs4all.nl/dilbert19950813.html
http://dribibu.xs4all.nl/dilbert19951230.html
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
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.
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!
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
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
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.
If you consider his knowledge of the NT4 kernel that no one on our team had as mediocre then sure.
If you consider that his documentation was approaching 4:1 against lines of code then sure.
If you consider that even with the 1:1 coaching that he gave our resident programmers they could barely keep up then sure.
And finally...
If you consider that we bid this to MS and they conceded that it was a touchy application that required a team of at least three programmers, then sure he was a mediocre programmer.
More likely he was light years ahead of anyone else we employed. I read his code and I fully understood the principle of the operation (with the help of the comments), but my capability of the execution would have been grossly lacking.
Seeing as you're an AC I likely wasted my time on a troll, but whatever.
-nB
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
>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.
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.
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 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.
> 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
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).