Forgot your password?
typodupeerror
This discussion has been archived. No new comments can be posted.

Hiring Programmers and The High Cost of Low Quality

Comments Filter:
  • Sigh. (Score:5, Insightful)

    by SatanicPuppy (611928) * <Satanicpuppy@gm[ ].com ['ail' in gap]> on Monday August 06, 2007 @05:32PM (#20134857) Journal
    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.
  • ... produces crap. Good programmers are not cheap, people that want to hire them are.
  • mythical man month (Score:3, Insightful)

    by Anonymous Coward on Monday August 06, 2007 @05:37PM (#20134917)
    that is all.
  • by Schnoogs (1087081) on Monday August 06, 2007 @05:39PM (#20134941)
    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
  • Languages (Score:2, Insightful)

    by PhilipMckrack (311145) on Monday August 06, 2007 @05:49PM (#20135055)

    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.


    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 .Net developers and I am interested in .Net but don't have any real experience in it. I understand it and have written several small programs, but nothing really complex. I have plenty of 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 can't even get an interview.

    I am studying to get .net certified and hopefully that will help. I'm trying to better my situation, but at this point I can't even get anyone to talk to me. I would hope my resume doesn't suck that bad, when I graduated college 8 years ago I had plenty of offers and seemed to not interview like a slobbering moron, but everyone's mindset is "I need x years of this language experience before I'll talk to you".
  • by s0c0 (1138981) on Monday August 06, 2007 @05:51PM (#20135081)
    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.
  • 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.
  • by Joaz Banbeck (1105839) on Monday August 06, 2007 @05:54PM (#20135107)
    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.
  • by Joe The Dragon (967727) on Monday August 06, 2007 @05:54PM (#20135113)
    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.
  • Re:Languages (Score:5, Insightful)

    by jrumney (197329) on Monday August 06, 2007 @05:57PM (#20135137) Homepage
    The hardest part of finding a new job is getting past the recruiters, who are generally not capable of anything more than keyword matching against your experience. Use your contacts if you can to get in front of the technical managers who will understand that your domain knowledge and overall experience is more valuable than which languages you have been using for the past few years.
  • Re:Sigh. (Score:3, Insightful)

    by djupedal (584558) on Monday August 06, 2007 @06:04PM (#20135191)
    "But the advantage of being a talented generalist is you have a N+1 higher chance of remaining employed then someone that can only do one thing, no matter how well."

    Tell me again? Just how is it you've managed to get this far in life having never fallen victim to office politics?
  • by Odin_Tiger (585113) on Monday August 06, 2007 @06:07PM (#20135213) Journal
    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.
  • by p4rri11iz3r (1084543) on Monday August 06, 2007 @06:11PM (#20135271)
    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.
  • Re:Sigh. (Score:2, Insightful)

    by GuyverDH (232921) on Monday August 06, 2007 @06:12PM (#20135279)
    Being a specialist can have it's benefits - mostly to the person who is the specialist.

    However, being a specialist also has drawbacks.

    Let's see....

    #1 That's not my specialty, I don't know anything about it. This is used for 99.9% of any discussion that is outside the scope of their specialty.
    #2 How could I know that my application would do that? I don't know (xyz operating system), I only know (xyz language).
    #3 What do you mean I can't use all the resources on the box, I'm the only one using it right? (as you try to explain to the specialist that they are logged into a UNIX box with 40 other programmers)
    #4 Why can't I load up xyz app server and abc web server, that's what I'm used to using? (as you try to explain corporate standards)

    The list could go on and on...

    This is where generalists, or at least broader experience bases work the best. Specialists have their places, usually in an isolated system / network where they can do no damage.
  • by tehdaemon (753808) on Monday August 06, 2007 @06:12PM (#20135281)

    This idea of lets get someone in and train them up is assinine.

    Dumb question, but if nobody trains new developers, then where the heck are those more experienced developers supposed to come from? And of course the related question, where did the few that we now have come from?

    T

  • I Thought.... (Score:2, Insightful)

    by JamesRose (1062530) on Monday August 06, 2007 @06:13PM (#20135295)
    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.
  • Re:Sigh. (Score:5, Insightful)

    by Frumious Wombat (845680) on Monday August 06, 2007 @06:13PM (#20135297)
    Every five years someone rediscovers, The Mythical Man Month [amazon.com] and thinks they've had a great insight. People should be handed a copy of this when they start their tech jobs. Managers should have it inserted forcefully into appropriate orifices. Hardback copies for senior management.

    Basically, some people are just better coders, and adding sub-standard assistance just ensures late, sub-standard software. Adding people to late projects makes them later.
  • Re:Sigh. (Score:3, Insightful)

    by tx_derf (1060278) on Monday August 06, 2007 @06:22PM (#20135403)
    I'd say you've got it entirely backwards. It's been my experience that those who make themselves irreplaceable in any one pigeon hole make themselves unpromotable. The specialists get stuck doing the same thing forever until the technology evolves and they're left behind with no usable job skills. I've been developing software for 15 years. I've been in several industries doing many different things from real time safety critical embedded software to device drivers to building GUI interfaces and databases. And yes, I got my start doing IT while I was in college. I managed to dance around the office politics and change jobs at appropriate times and have landed in a very good situation, becoming a lead architect on a software project even though that wasn't why they hired me just 6 months ago. I'm the generalist with a diverse background, including IT, that the author talks about. I'm having great success making some very significant contributions because I learned a long time ago how to learn. I got here, knew what I had to grasp about the project to come up to speed quickly and what I could figure out later. And now I'm the lead planning our next big upgrade because I can do it. I've already directed one small upgrade since I arrived. You seem happy entrenching yourself so I say more power to you. But my experience says this guy hit the nail on the head.
  • by Anonymous Coward on Monday August 06, 2007 @06:26PM (#20135465)
    That's why as a student, you want to get an internship.
    The money's not great, but the experience is invaluable.
  • Re:Sigh. (Score:5, Insightful)

    by misleb (129952) on Monday August 06, 2007 @06:27PM (#20135481)

    Tell me again? Just how is it you've managed to get this far in life having never fallen victim to office politics?


    Three possible methods... may be used in combination:

    1) Small companies/organizations
    2) Being completely oblivious to politics and not getting involved
    3) Consulting/contract work

    Note, I'm not the original person you were asking. I just thought I'd chime in.

  • by Cornelius the Great (555189) on Monday August 06, 2007 @06:28PM (#20135497)
    Don't let the job listings get you down. The jobs usually listed on Monster, Careerbuilder or (name your favorite job website) usually shoot higher than what they're asking in the descriptions. The job I'm currently at said 5+ years of experience and settled on me with my 2 years (+6 month co-op) because I had a good interview and I knew what I was talking about.

    Also, having your resume public allows recruiters and jobs to find you. My first job out of college (3 years ago) found me. Granted, you may find as a contractor for a few years before you find yourself a permanent job, but you'll get some valuable experience doing those short 6-12 month "gigs".

    Luckily for you, the CS job market seems to be better than when I graduated. I considered myself lucky to have one job offer within weeks of graduation- many of my classmates couldn't find CS jobs within the year. Anyway, good luck!
  • by mshurpik (198339) on Monday August 06, 2007 @06:29PM (#20135521)
    ...the mythical man-month?

    >why should companies favor hiring fewer more senior developers rather than many junior ones?

    *swish*
  • by EmbeddedJanitor (597831) on Monday August 06, 2007 @06:33PM (#20135569)
    While many people have an intuitive feeling as to what constitues a Good Programmer from a Bad Programmer, there are very few quantitative measures. Bad software does not look vastly different from Good Software.

    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.

  • by lawpoop (604919) on Monday August 06, 2007 @06:36PM (#20135613) Homepage Journal
    Some people are self-taught or learn on the job. Not everybody needs to learn from another person.
  • by Qzukk (229616) on Monday August 06, 2007 @06:38PM (#20135631) Journal
    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.
  • by dircha (893383) on Monday August 06, 2007 @06:44PM (#20135703)
    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.

  • Yeah, right (Score:5, Insightful)

    by Elias Israel (182882) <eli@promanage-inc.com> on Monday August 06, 2007 @06:47PM (#20135729)
    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.
  • by kbob88 (951258) on Monday August 06, 2007 @06:50PM (#20135769)

    Companies only want to hire people with experience.

    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:
    • Getting HR and top management to buy into it - their philosophy seems to be "we want above average software using slightly below average people"
    • Figuring out who the great developers are

  • by linguae (763922) on Monday August 06, 2007 @06:55PM (#20135829)

    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.

    There is a way for CS students to gain experience while in school: internships. Apple, Microsoft, Google, and many of the other big companies have summer internship programs. Students can also try to find a small company in their area. Sometimes a professor may have a research project that needs to be implemented during the summer; that counts as development experience, also.

    Yes, it is tough to obtain such internships at times. But this it what it takes to get started on the experience treadmill in industry. If you can't get an internship, try contributing to a open-source project, particularly a high-profile one. Many companies like open source projects, and they will also count this as development experience.

  • by jgarra23 (1109651) on Monday August 06, 2007 @07:02PM (#20135917)

    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.
  • Re:Sigh. (Score:5, Insightful)

    by jellomizer (103300) * on Monday August 06, 2007 @07:06PM (#20135957)
    Avoiding being a victim to office politics is doable. It is about making yourself look good as well as the rest of the department. Politics come in when you are trying to make yourself look good either by focusing completely on yourself or at the expense of others. If there are other people trying trying to make themselves look you you help make them look good, if they are trying to make you look bad you make sure you still look good without making the other guy look bad. I work in a small company but I am one of those evil contractors who do work for bigger companies and there are always people want to see me fail but normally after I help them succeed then they are normally more welcoming to me.
  • Re:Sigh. (Score:5, Insightful)

    by misleb (129952) on Monday August 06, 2007 @07:11PM (#20136011)
    Well, the question wasn't how can anyone do it, the question was how did *I* do it. The first point, avoiding large corporations, is probably the most effective way that I have avoided office politics deciding the fate of my job. You can form more personal bonds in a small company and it is much more difficult for someone else to hide their incompetence.

    Another good strategy is simply to be good at what you do and don't give anyone any reason to doubt your sincerity or integrity. Always be upfront, frank, and honest. Never be afraid to say "I don't know" if you don't know something. If/when someone approaches your boss to complain about you (presumably for no good reason), your boss will take your side by default and you can therefore remain oblivious to the politics.

    Of course, if you're in management, too bad. Politics is pretty much your jobs then. ;-)

  • by mveloso (325617) on Monday August 06, 2007 @07:12PM (#20136017)
    Your tools and techniques are probably bad, especially if you learned them in school. Do you know how to:

    * use source control?
    * analyze someone else's code (multiple people's code), figure out what it's doing, and map that to what it's supposed to be doing?
    * can you understand the bug at all (what is is supposed to be doing)?
    * can you figure out how to verify that your fix actually worked?
    * do you understand how to configure and use the product you're working on?
    * explain what you're about to do, and justify why it should be done like that?
    * be focused enough to fix one (1) bug, and not go off and rewrite a whole lot of stuff that looks like cr*p?
    * not break the build?

    In real life, doing architecture and writing stuff from scratch rarely happens...but that's all they teach you in school. In real life, you're working on some big pile of code that you're stuck with, can't change, and don't understand. You can fix #3, but usually #1 and #2 are immutable...until the magical day when they need a new feature (hey, we need to redo a whole chunk of that thing to get the new feature to work).

    Do you need experience? Write something. Nothing sells your coding skills like code. The downside is that people will be able to see how your code is. If the programmers in your target company are good, they'll be able tell the difference between someone who's new and someone who just sucks. If they aren't so great, then your code is still a plus, because they won't know how bad it is.
  • Maybe not "the right way." That's a conceit common to our profession: that our way is "right." But at least a GOOD way to code it.

    In the case of dealing with any customer "the right way" is the way that can be commented for future maintenance & works without bugs. If your code can do that, then it is most certainly "the right way"- the right way for the conditions of the job.
  • Re:Yeah, right (Score:2, Insightful)

    by Anonymous Coward on Monday August 06, 2007 @07:13PM (#20136037)
    > Perl is an horrifically bad language.

    Yes. This is how I knew the article was complete bunk. Kudos to the author for putting this signal near the top of the article (that way I didn't need to read further)...
  • by COMON$ (806135) * on Monday August 06, 2007 @07:18PM (#20136089) Journal
    welcome to the working world. The specialized knowledge you seek doesnt come from your first job. It comes from taking a thousand crap jobs and compiling information as you go. If you seek to be specialized in mainframe development then you have a long path in front of you, as there are many more experienced mainframe developers with a good 15 years of experience ahead of you.

    However if you are one of the aforementioned mainframe experts then you need to take a crap job or some side jobs as a web developer, starting off working for free for non-profits and the like, then as your skills progress you can start charging then work your way up from there. Then you can start looking for the mainframe web devs that you are aiming for. However if you are like most people you become a specialist because that is where the job field led you. You may see that there is a good paycheck in the area or it may interest you but that is exactly why those jobs pay well, because they are a rare person and unless a trade school offers a program you are SOL.

    The purpose of the article is to explain that a good dev can make up for some serious problems as a beginner programmer, or if your company is big enough you can hire the underlings to do the crap coding while the expert does all the engineering, planning and actual Development. Those entry level people pay their dues coding and recoding the same scripts over and over for the guru and after a while they move up, taking that knowledge with them. However if a company cannot afford a whole host of devs, they had better hire the good ones rather than the entry level employees.

  • by scribblej (195445) on Monday August 06, 2007 @07:20PM (#20136123)
    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.

    As someone with experience I'd just like to suggest that maybe they aren't stuck in a logical loop. Maybe you aren't the person they want, they want someone with experience.

    Here's an idea: As a computer programmer, you are in a unique position to make your own experience. I got started in "the business" by developing a totally crappy (seriously, I'm ashamed) graphing calculator for the HPC. I have an HPC, I needed a graphing calculator, and I'm cheap, so I really wrote it for myself. Then I put it up on the web and people liked it, so that became the first point on what is now a long programming resume.

    My point is, you don't have to get hired by anyone to get experience. If you don't have an idea or an itch to scratch of your own, pitch in on some open-source projects.

    When I am hiring junior programmers, the guy who is fresh out of school I'm going to overlook. The guy who's fresh out of school AND has some projects of his own he's worked on is EXACTLY the guy I want, though -- not only do I know he's knowledgable and capable, I also know he's a self-starter who's not going to wait around and whine and bitch that no one is giving him an opportunity. The opportunities are out there, you can't wait for someone to give them to you... you have to go take them.

    Seriously, go *do* something. It'll take your mind off being out of a job and if you do it right it will be the thing that gets you a job. It's win-win.

  • by Phouk (118940) on Monday August 06, 2007 @07:23PM (#20136157)
    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.

    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, ..., plus another dozen or more libraries typically used even on a small Java web project.

    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).
  • by Caerdwyn (829058) on Monday August 06, 2007 @07:29PM (#20136211) Journal
    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".
  • by phoenixwade (997892) on Monday August 06, 2007 @07:30PM (#20136217)

    I'm new to it all also. I've worked at this company a few months and have designed two separate applications, while maintaining/improving a third. All I can say is it seems that I'm a better developer than the people that came before.. The project I've had to maintain is garbage spaghetti code that was said to have been developed over a few years, and would take me 6 months tops to write from scratch. I'm not saying I'm good at what I do but I am saying whoever came before was terrible at what they do. This boggles my mind considering that it was written by 'Senior' developers, who probably make double what I do.
    I obviously haven't seen the code you're talking about and hove no opinion of it. However, I've heard this crap from new programmers for years. So let me through some ideas your way.

    1. it isn't garbage and spaghetti because you have difficulty following the technique, there are a thousand ways to do anything. It's garbage and spaghetti when it doesn't work well, and when it's under documented.
    2. Could you really write it in six months without referencing the code you are talking about? It's one thing to write code when the problems have been solved, quite another to solve the problems.
    3. the scope of a job changes over time. For a new programmer, start looking for scope creep, it's a friend and an enemy.
    4. code changes over time because languages change over time. Look for those situations in the spaghetti code where those guys that you are better than wrote functions that were not available in the language. You may get a surprise that they did something really elegant to overcome something missing in the language originally that exists now.
    5. lets say that there were five programmers on the code before you, one after another. The first four might have been gods gift to programming, it only takes one pretentious newbie in the chain to really screw up pretty code.

    certainly none of these apply to your project, but it's something to think about as you are exposed to projects in your career.

  • by iabervon (1971) on Monday August 06, 2007 @07:46PM (#20136383) Homepage Journal
    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.
  • by cryfreedomlove (929828) on Monday August 06, 2007 @08:03PM (#20136517)
    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.
  • by Mutatis Mutandis (921530) on Monday August 06, 2007 @08:08PM (#20136559)

    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.)

  • by BShive (573771) on Monday August 06, 2007 @08:50PM (#20136869) Homepage
    Yeah, being able to tell which programmers are the good/great/uber is HARD. It's much easier for companies to go on metrics as above instead of attempting to filter through for the excellent people, or even the most relevant person for the position.
    Compounding that, it's rare that a coder will admit to being subpar. Chances are even if you're dailywtf material they think they are great programmers! I've been doing code in one form or another for over a fifteen years and consider myself pretty good, great sometimes. I've worked with one uber programmer in my entire career (John Kichury of SGI), maybe 2 or 3 others that came close, but have met many that act and talk like they are. Following on their projects always has a common thread of being overly clever, loosely documented and hard to maintain.
  • Re:Sigh. (Score:5, Insightful)

    by hardburn (141468) <hardburn@wumpus- ... OWnet minus city> on Monday August 06, 2007 @08:55PM (#20136903)

    The first point, avoiding large corporations, is probably the most effective way that I have avoided office politics deciding the fate of my job. You can form more personal bonds in a small company and it is much more difficult for someone else to hide their incompetence.

    My personal experience (clearly being a statistically significant single datapoint . . . ) was in two small business (one around 20 employees, the other around 40 employees), and both were extremely cut throat. In particular, the second one had the employees forming close, almost family-like ties, but management was completely insane. That's where I discovered that being the guy that is considered absolutely invaluable doesn't actually insure job security, but rather makes you a target by people who consider you a threat to their own position.

    Now I work under a consulting company under a Fortune 500, where I'm almost completely insulated from the normal office politics. Whenever I have a bad day, I watch "Office Space" and remember why I'm so lucky.

  • by John Sokol (109591) on Monday August 06, 2007 @08:59PM (#20136935) Homepage Journal
    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.

  • by Anonymous Coward on Monday August 06, 2007 @09:07PM (#20136991)
    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?"
  • the real question (Score:3, Insightful)

    by drfireman (101623) <dan@kim b e r g .com> on Monday August 06, 2007 @09:16PM (#20137051) Homepage
    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.
  • by Skapare (16644) on Monday August 06, 2007 @09:20PM (#20137077) Homepage

    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.

  • Re:Sigh. (Score:4, Insightful)

    by turbidostato (878842) on Monday August 06, 2007 @09:33PM (#20137199)
    "But the advantage of being a talented generalist is you have a N+1 higher chance of remaining employed then someone that can only do one thing, no matter how well."

    Not so true: say you are quite expert on A, B and C. On a mature or stressed market that only will mean that you won't get work neither on A, B nor C because those job positions will go for "real niche expert on A", "real niche expert on B" and "real niche expert on C", repectively.
  • by turbidostato (878842) on Monday August 06, 2007 @09:44PM (#20137309)
    "It would be far better for most companies to pay double the going salary to attract only the best"

    1) Everybody knows that some horses run faster than anothers. The problem, my friend, is telling appart *which* one will run fastest this evening's race.

    2) Do you really think that by paying double bad programmers will be repeled and won't try to apply for your job offer?
  • by DamnStupidElf (649844) <Fingolfin@linuxmail.org> on Monday August 06, 2007 @09:56PM (#20137415)
    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.

    When you separate the planners from the builders like that, you get the Twin Cities bridge that was a load of under-engineered shit because planners built it to look good on paper, and the builders made it work, but overall it was a disaster waiting to happen.

    I mean honestly, you shouldn't have overall architects who haven't actually written code before. They will absolutely fudge the software requirements because they really don't know what they need to get the job done. Likewise you can't get an infinite number of stupid programmers to implement a perfect specification because it takes too long and is too error prone.

    Ultimately the question is where do you get your perfect software architects, and why can't you just get programmers from the same place? Without good programmers, how do you know that your software architects aren't full of shit?
  • Re:Sigh. (Score:4, Insightful)

    by SatanicPuppy (611928) * <Satanicpuppy@gm[ ].com ['ail' in gap]> on Monday August 06, 2007 @10:12PM (#20137535) Journal
    Ha! Trust me on this, COBOL programmers will take their goddamn jobs to the grave with them. Those S.O.Bs get called out of retirement and paid consultant money to fix things they arsed up decades before.

    Anything that sits on a financial system will be changed as seldom as possible, and COBOL is alive and well with people who maintain those damn ancient not-to-be-upgraded systems.
  • by Prof.Phreak (584152) on Monday August 06, 2007 @10:35PM (#20137719) Homepage
    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.

    Possibly not on day one. But definitely a few weeks afterwards (ie: domain knowledge). Experienced programmers tend to see subtle things that most people gloss over. Even stupid little things. Those things make one developer more productive than a whole department team combined (especially if those other programmers were primarily hired by HR).

    Most projects at most corps have 1 (or maybe 2) developers doing about 90% of the work, and a dozen or so folks on the payroll for the project.
  • by sfjoe (470510) on Monday August 06, 2007 @10:47PM (#20137829)

    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.
  • Re:Sigh. (Score:3, Insightful)

    by Ian_Bailey (469273) on Monday August 06, 2007 @11:45PM (#20138209) Homepage Journal
    I've found in my experiences that the "small company" vibe that some people like doesn't necessarily grow in 20 people companies, and sometimes appears in larger companies as well (although I have far more experience with the former rather than the latter).

    I've worked for a smallish company with dozens of people, and it had the culture of a big company. Lots of politics, multiple performance tracking systems, and an admin guy with too much time on his hands to create new policies that makes your life more difficult.

    I agree with the idea of the post that smaller organizations tend to focus more on people rather than politics, but it is by no means a hard and fast rule.
  • Re:Sigh. (Score:4, Insightful)

    by PitaBred (632671) <<slashdot> <at> <pitabred.dyndns.org>> on Monday August 06, 2007 @11:48PM (#20138225) Homepage
    Says you. I'm a "generalist", but damned if I don't solve tons of problems around the office that stymie specialists because they don't know the full system, or how to think of it from any other angle than what they've been trained. As in, the Java interface programmer who keeps asking me how to use LDAP, which he hasn't had experience with, or why the 64bit version isn't working. Generalism still has a lot of place in a business.
  • Re:Sigh. (Score:3, Insightful)

    by mini me (132455) on Tuesday August 07, 2007 @01:35AM (#20138755)

    A decent employer will know that.

    A decent employer will realize that communication is where most productivity is lost. Because the generalist can do it all, they don't need to waste time telling the next guy what needs to be done. Even if they are slower to get a specific task done compared to a specialist, they will easily make up that, and more, over the entire job.

    Although, I must say that in my experience, the generalists usually display more skill across the entire gamut of their abilities when compared to a specialist in their area of expertise. There is a lot of hidden overlap between fields. Even if you're not focusing on a specific field, you're always learning more about it from other fields you are working in. Though perhaps only those "wired" to be generalists are able to pick up on this fact and why specialists seem to think it doesn't happen?
  • by Edgewize (262271) on Tuesday August 07, 2007 @03:51AM (#20139293)
    I can't tell if you're being earnest or sarcastic. Your bridge metaphor is either unfortunately timed, or brilliantly placed.

    Differences in programmer skill do exist, and it has nothing to do with their grasp of domain-specific knowledge. Rather, it has to do with the ability to hold a lot of knowledge at once, such that the appropriate knowledge springs to mind without needing to look it up.

    The difference between a "decent" programmer and a "great" one is that the decent programmer will think of an approach, start coding it, come up against a wall where it collides with some other code, examine the other code, mull it over, and rework his approach accordingly. The great programmer will think about the task for a moment, the roadblock will be obvious to him, and he will get the right approach on the first try. (If he's really great, he'll even leave a comment explaining why the straightforward approach has a roadblock.)

    No matter how much training you give the first programmer, his recall capacity is not going to increase dramatically. He can understand the design well enough to know where to look, or who to ask, but his working set is just not large enough to encompass the entire design.

    If your systems are small enough that anyone can recall all aspects of them at all times, you don't need programmers. You just need monkeys who can write C/Java/Ruby/whatever. But if you work on any reasonably large project, the great programmers always stand out as "the people who get asked questions".
  • Re:Sigh. (Score:2, Insightful)

    by fusion9290991 (721295) on Tuesday August 07, 2007 @04:01AM (#20139337)
    I've got two kinds of programers:

    1. The guy who is always shitting himself over a deadline, is always going on about how busy he is, never gets anything done, and delivers consistently broken apps. He blames everyone else for either being stupid or lazy when his apps break. He consumes exceptions because he's embarrassed about them, rather than using them to determine what went wrong. He quotes best practices, but seldom uses them. He consistently reinvents the wheel. He's never wrong, and instantly knows the cause of every problem, tho he won't actually do anything constructive towards fixing it. He'll suggest lots of things, but won't be willing to try them in case he's wrong.

    2. The second guy (who is often the one accused of being lazy, coz he's "not stressing enough"), often seems to be doing things which are not related to the project, but always has his stuff done. On spec. On time. Working. And pretty much bug free. And he's solved a bunch of other problems along the way.

    Who would you rather hire?
  • by Envy Life (993972) on Tuesday August 07, 2007 @07:10AM (#20140073)
    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.
  • by FuzzyDaddy (584528) on Tuesday August 07, 2007 @09:22AM (#20140923) Journal
    I'm an engineer, not a programmer, but I'm very familiar with the generalist/specialist phenomena. My degree is in Physics, not engineering, and every job I've had has been in a very different field then the previous one. This has made my job searches somewhat slow and frustrating, but I've found that once I get to a job, I'm well appreciated because I do all sorts of useful things.

    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.

  • by kpharmer (452893) on Tuesday August 07, 2007 @11:30AM (#20142463)
    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. :-)

  • Dump Away! (Score:2, Insightful)

    by RailGunSally (946944) on Tuesday August 07, 2007 @12:20PM (#20143187)
    > These days, being a programmer generalist (even worse, one with admin experience) just increases the types of shit that get dumped on you..

        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 .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.

        I have determined quite conclusively that these fucking IS morons have never heard of a finte state machine, cannot process CSV files (buggy .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.

        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!

A Fortran compiler is the hobgoblin of little minis.

Working...