• Ollie Williams (unregistered)

    The first rule of DAL is: you do not talk about the DAL The second rule of DAL is: you do not talk about the DAL

  • (cs)

    This sounds familiar. I've been re-writing DAL code that takes grid parameters for the past three years. I can't fathom how these people think it's a good idea.

  • (cs)

    Too bad Jeff wasn't able to effectively present his view. His code could have been an efficient and effective model for his company.

  • SR (unregistered) in reply to frits
    frits:
    Too bad Jeff wasn't able to effectively present his view. His code could have been an efficient and effective model for his company.

    It sounds more like the company didn't effectively listen to Jeff.

    Besides we all enjoy reinventing the wheel. Go on, admit it! ;o)

  • (cs)

    There's only one thing worse than a two year veteran without a clue, and that's a twenty year veteran without a clue.

    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.

  • (cs)
    Carl, a twenty year veteran with the company

    MAJOR red flag right there. What is with these people who have worked for a company for years? Every single one I have met during my career was basically an ignorant sloth who knew nothing about proper software engineering practices and, when confronted or asked about doing things the right way, used seniority to shoot it down.

    I mean, I can understand using shitty practices when you're first learning the stuff; that's expected. But you should REALIZE it's a bad way of doing things, and constantly improve yourself so the next project, you do a little better. And the next, and so on until you're doing things properly. You don't keep churning out the same shit because you're too stupid to understand it's wrong and don't want to be bothered learning better ways.

  • wtf (unregistered)

    As an aside, I don't see why everyone complains about re-inventing the wheel. Bicycle companies do it all the time, and the bicycles have better wheels on them because of it.

  • Jellineck (unregistered)

    "Ignoring the fact that is idiotic," Jeff replied, "why would we do that? The UI and the DAL are completely separate. It doesn't matter how we present the data, the DAL is just fetching it."

    Someone needs to work on his interpersonal skills. Everything after the word "idiotic" will always be ignored. He might as well have said "Ignoring the fact that is idiotic, I read the Twilight book and cried the whole time."

  • wtf (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.

    Works great if you're interviewing your twenty-year veteran employees. A good idea, perhaps, but not something that's done very often.

  • 50% Opacity (unregistered)
    He could grab the Windows team's DAL and business layer, slap a web front end, …

    It seems he should've rather slapped the DAL instead.

  • highphilosopher (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    There's only one thing worse than a two year veteran without a clue, and that's a twenty year veteran without a clue.

    Ways to avoid this kind of cluster fuck (at least for Java projects) is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then.

    You know, I think you're painting the whole world of development into one little box. There's plenty of other good design pattern books, however expecting all your developers to be architects is like trying to have an army of generals. What you need is 1-5 GOOD Architect(s) that build the framework around which the developers can work. Many companies try to save some money on their development budget by skipping the Architect (and sometimes even the Project Manager). Generally these companies end up with a codebase of useless snippets organized by prepending the name of the ASP.NET files with "Web".

  • Code Refuser (unregistered) in reply to java.lang.Chris;

    "There's only one thing worse than a two year veteran without a clue, and that's a twenty year veteran without a clue."

    Even though our young developer wanted to do things the "right way", I have to say that both parties came off as pretty clueless here. He should have expected that unless the application he was piggybacking on was designed with abstraction and re-use in mind, that whatever he was provided was going to be almost useless to him.

  • (cs) in reply to SR
    SR:
    frits:
    Too bad Jeff wasn't able to effectively present his view. His code could have been an efficient and effective model for his company.

    It sounds more like the company didn't effectively listen to Jeff.

    Besides we all enjoy reinventing the wheel. Go on, admit it! ;o)

    I think you missed something.

  • Ed (unregistered)

    Christ, at least his project HAS a DAL.

    The one I'm working on these days just have 3000 line classes that do every concievable permutation of getting tiny bits of data in and out of the database and into the relevant control on the page...

    I should start submitting some of the WTFery that I find on a daily basis I think.

  • (cs) in reply to Ed
    Ed:
    Christ, at least his project HAS a DAL.
    One of the applications I inherited has a DAL, of sorts. The really great part about the whole thing, though, is that the Classic ASP layer calls out to the COM+ layer to get the widgets it should render. The COM+ layer returns a string of XML that the page outputs in-line in the body, and never looks at directly again. Instead, when the page wants a widget, it passes the XML string back into the COM+ layer with the name of the widget it wants. The COM+ layer then returns an HTML string that represents that widget on the page.

    Honestly, when I read the submission, I had to make sure Jeff wasn't a co-worker. Because my company has a crapload of applications like that.

  • iToad (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Carl, a twenty year veteran with the company

    MAJOR red flag right there. What is with these people who have worked for a company for years? Every single one I have met during my career was basically an ignorant sloth who knew nothing about proper software engineering practices and, when confronted or asked about doing things the right way, used seniority to shoot it down.

    I mean, I can understand using shitty practices when you're first learning the stuff; that's expected. But you should REALIZE it's a bad way of doing things, and constantly improve yourself so the next project, you do a little better. And the next, and so on until you're doing things properly. You don't keep churning out the same shit because you're too stupid to understand it's wrong and don't want to be bothered learning better ways.

    Sometimes, the twenty year veteran really has twenty years of experience. Sometimes, they only have one year of experience, twenty times.

  • sd (unregistered)

    I have some advice for Jeff. Once you start off your sentence with "Aside from the fact that this is idiotic..." the other person stops listening to your argument and goes on the defensive.

    If you're really trying to convince someone to change something, insulting them for writing or suggesting it isn't the way to go about it. All you'll end up with from that is the cold comfort that you're right, and possibly the material for a TDWTF article.

  • Doug (unregistered)
    The first rule of code reuse is that the code needs to be worth re-using.

    Reading this almost made me cry. Or maybe that was the onions from my omelet.

    Either way, it's true.

  • (cs) in reply to Ed
    Ed:
    Christ, at least his project HAS a DAL.

    The one I'm working on these days just have 3000 line classes that do every concievable permutation of getting tiny bits of data in and out of the database and into the relevant control on the page...

    I should start submitting some of the WTFery that I find on a daily basis I think.

    Don't make us drool, dude... show us your dirty bits.

  • AnOldRelic (unregistered) in reply to iToad
    iToad:
    Sometimes, the twenty year veteran really has twenty years of experience. Sometimes, they only have one year of experience, twenty times.
    This. I can't tell you how many times we've had people come through the interview process here that claimed 10+ years of experience with their particular point of expertise... but showed little-to-no improvement over individuals who were considered by HR to be "under-qualified" because they only had 3-5 years' experience. Quality > Quantity. I'd sooner hire the 2-year rookie with a degree, a grasp of theory, the desire to learn and the ability to adapt and put him/her under the wing of a project lead. He/she will be infinitely more useful to the company than a 20-year veteran who is set in their erroneous ways and has not bothered to grow with the industry over time.
  • (cs) in reply to java.lang.Chris;
    java.lang.Chris;:
    There's only one thing worse than a two year veteran without a clue, and that's a twenty year veteran without a clue.

    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.

    I wish I had that luxury. I spend months waiting for a single candidate that won't fill this site with fresh WTFs. I'd hate to ignore a candidate with potential because they hadn't read my pet book.

    I just interviewed someone who was very versed in the singleton pattern. I know this because she gave me a very detailed explanation of how to create a singleton database connection for a web application. She read GoF, and she understood it, but she is still a bad designer.

  • Luis Espinal (unregistered) in reply to wtf
    wtf:
    java.lang.Chris;:
    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.

    Works great if you're interviewing your twenty-year veteran employees. A good idea, perhaps, but not something that's done very often.

    Fowler's book on EEA Patterns is not an appropriate book to use as a baseline unless you are hiring a software architect, a senior software developer, integrator or a systems engineer, and by "systems engineer" I don't mean a Sysadmin+Network Admin, but someone whose work is in the actual field of systems engineering. As a general interview question for junion/mid developers, I don't think it is appropriate.

    Everything else you said is on the mark though (specially grilling one's knowledge of design patterns, and most importantly how not to use them.) Other books I'd add to the list would be Fowler's "Refactoring" and Brown et al. "Anti Patterns". If they have actually read Bruce F. Webster "Pitfalls of Object Oriented Development", that should count for something.

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Carl, a twenty year veteran with the company

    MAJOR red flag right there. What is with these people who have worked for a company for years? Every single one I have met during my career was basically an ignorant sloth who knew nothing about proper software engineering practices and, when confronted or asked about doing things the right way, used seniority to shoot it down.

    I know at least one guy who's a 30-plus-year veteran with the company I used to work at (he's still there, running out the clock on his pension vesting with about 6 months to go). His tenure literally predates the existence of the company as he was an employee of one of two companies that merged into the current entity.

    There isn't much he doesn't know about his job area, either technically or politically, as he worked on software and hardware development through most of his career and is now marking his time administering systems he helped create. When he says "no, that's stupid" (which isn't often as he picks his battles conservatively), it's for more than sufficient reason and he has the seniority to just do things the right way rather than what our idiot managers wanted him to do.

    I'd put that guy up as a counterexample to your red flag.

    Having said all that, Jeff's desire to reuse code would work better if he created his own code and offered it rather than trying to reuse code the authors clearly were going to play silly seniority games with. But it would only work at all in a corporate culture that understands, encourages, and supports code reuse, which is clearly not the culture he was in.

  • (cs) in reply to java.lang.Chris;
    java.lang.Chris;:
    There's only one thing worse than a two year veteran without a clue, and that's a twenty year veteran without a clue.
    Can we add some SO functionality in here so I can upvote this? A clueless rookie you may be able to shape into something. A clueless veteran should just get the boot, not just because he clearly doesn't give a shit about improving himself, but also because he thinks he's doing things right and is incapable of listening to anyone else.

    I've had to work with a clueless dev "with years of experience" before. His first svn commit didn't have indentation. Who the hell writes code without indentation?! I haven't done that since I was writing BASIC when I was 11. Eventually I had to forcefully take control of the design process, because it was clear I'd end up being the one maintaining the code after this guy left. Eventually he did leave and after a while I got a feature request that would have taken about two days to deal with. I finished it in about 4 hours thanks to the proper design I had insisted on.

  • (cs) in reply to sd
    sd:
    I have some advice for Jeff. Once you start off your sentence with "Aside from the fact that this is idiotic..." the other person stops listening to your argument and goes on the defensive.
    Work isn't always about getting the immediate task done. Sometimes you need to take the long-term morale boost of publicly crushing incompetent coworkers.
  • Me (unregistered)

    Code reuse is good, yes, but it has it's limits.

    I just refactored some code that reused the same DAOs (yes! we have data access objects!) to a) fill a form with data from several related tables and b) fill a drop down list with the "name" column of one of the tables.

    In other words, the second use case used exactly the same five DB queries for each of the 80 or so items to be displayed, and discarded all but "name".

    Sometimes you have to tailor your DAL to the job.

  • Jason Y (unregistered)

    Yeah, he definitely should have:

    1. been more diplomatic, using evidence (e.g. resources like PoEAA) rather than insults.
    2. looked at the existing DAL before insisting that he use it. If the desktop software writers claim that their DAL is for the desktop software, that should have clued him in that their "DAL" was actually customized for the desktop software, rather than being written as a real DAL.
    3. communicated that the DAL he writes is UI-ignorant, and explained to the destop UI team how they can use DAL's that follow this pattern in the future, complete with sample desktop UI code, so that they would not have to duplicate efforts in the future. He could also show how desktop-specific crap in their desktop-specific "DAL" could be placed in another layer that is still desktop-specific, but delegates the DAL work to the real, UI-ignorant DAL.

    Just my 2 cents.

  • wtf (unregistered) in reply to Zylon
    Zylon:
    sd:
    I have some advice for Jeff. Once you start off your sentence with "Aside from the fact that this is idiotic..." the other person stops listening to your argument and goes on the defensive.
    Work isn't always about getting the immediate task done. Sometimes you need to take the long-term morale boost of publicly crushing incompetent coworkers.

    "Morale boost" from promoting stupid inter-office squabbling over getting the job done? Gosh, I'm glad I don't work with you.

  • Anonymously Yours (unregistered) in reply to wtf
    wtf:
    As an aside, I don't see why everyone complains about re-inventing the wheel. Bicycle companies do it all the time, and the bicycles have better wheels on them because of it.
    A lot of people hear rules, "best practices," and so forth and just commit them to memory. They don't actually think them through. They think you should reuse code whenever possible when, really, you should reuse code whenever practical. I've been subjected to cleaning up some horrible code my coworkers are rushed into producing, all because pre-existing code keeps getting hammered into whatever shape it needs to fit from site-to-site.

    All things considered, when Jeff has a few more years under his belt, he'd know the right way to ask for code. By which I mean noncommittally and (if Carl seems the type to buy it) to "learn from." That way, if Jeff finds the code is an unusable pile of shit, he doesn't have to offend anyone if he decides to imitate the functionality instead of recycling it.

  • Mads H. (unregistered) in reply to iToad

    Meh. The usual one-sided story written by the guy who lost the argument and then petulantly decided to add more crap to the codebase.

  • (cs) in reply to wtf
    wtf:
    "Morale boost" from promoting stupid inter-office squabbling over getting the job done? Gosh, I'm glad I don't work with you.
    Awww, that's just darling. Be sure to let us know if you ever land in a real-world job with incompetent toxic coworkers and a useless boss who doesn't do anything to keep them in check.
  • Skeptic (unregistered) in reply to Mads H.

    Technically, he won the argument. Or, to put it another way:

    Meh. The usual one-sided comment written by the guy with no reading comprehension, and petulantly adds more crap comments to the Internet.

    //STOP WHINING

  • Anonymouse (unregistered) in reply to Anonymously Yours
    Anonymously Yours:
    A lot of people hear rules, "best practices," and so forth and just commit them to memory. They don't actually think them through. They think you should reuse code whenever possible when, really, you should reuse code whenever practical.

    In my experience, the best cases of reusable objects are from cases where I didn't intend something to be reusable, but rather actually had the time to design the entire application properly, and re-use was a side-effect.

  • wtf (unregistered) in reply to Zylon
    Zylon:
    wtf:
    "Morale boost" from promoting stupid inter-office squabbling over getting the job done? Gosh, I'm glad I don't work with you.
    Awww, that's just darling. Be sure to let us know if you ever land in a real-world job with incompetent toxic coworkers and a useless boss who doesn't do anything to keep them in check.

    Been there. The incompetent toxic co-workers usually tried to cover up their incompetence by playing politics. (You don't go by "Lyle", do you?)

  • Dr Solar (unregistered) in reply to AnOldRelic
    AnOldRelic:
    ...individuals who were considered by HR to be "under-qualified" because they only had 3-5 years' experience. Quality > Quantity. I'd sooner hire the 2-year rookie with a degree, a grasp of theory, the desire to learn and the ability to adapt...
    THIS! I'm finding it impossible to get into anything resembling a 'real' role because they see 3 years not in the filed I'm actually good at and trhow me straight into the bin.
  • Anonymously Yours (unregistered) in reply to Anonymouse
    Anonymouse:
    Anonymously Yours:
    A lot of people hear rules, "best practices," and so forth and just commit them to memory. They don't actually think them through. They think you should reuse code whenever possible when, really, you should reuse code whenever practical.

    In my experience, the best cases of reusable objects are from cases where I didn't intend something to be reusable, but rather actually had the time to design the entire application properly, and re-use was a side-effect.

    Same here, actually. I think things come together better when you have a clear idea what to support and make your code flexible, rather than when you try to make your code flexible enough to support some great unknown.

  • Bosshog (unregistered)

    When I re-invent the wheel, I sometimes add new features. Like corners.

  • (cs) in reply to Anonymously Yours
    Anonymously Yours:
    Same here, actually. I think things come together better when you have a clear idea what to support and make your code flexible, rather than when you try to make your code flexible enough to support some great unknown.
    Never write flexible code for the sake of flexible code. At the same time, if you're doing application integration in your database, there's something horribly wrong.

    Flexible code arises from a clear understanding of your problem, not from inventing a generalized version of a problem and solving that, which is where mistakes happen. "Oh, I need to write a web presentation layer for customer accounts. My first step will be to write a generic web presentation layer and then customize it for customer accounts."

    If you really understand what your customer account system is supposed to do, and you implement to that with even a modicum of OOD, you're going to have code that's reasonably flexible, or can be refactored into something flexible.

    And when you need a more general presentation layer, you can pull up methods from your classes into newly created abstract classes that can be shared.

  • SOLID Man (unregistered)

    Writing DAL and BLL layers that are totally and completely decoupled from any UI technology (such as ASP.NET or WinForms) is actually quite difficult to do. The temptation to stick an HttpContext.Current or a Windows.Forms.Form in your BLL is always there. It requires a certain mindset towards development to write DAL/BLL layers like this, a mindset geared more towards SOLID principles and a TDD/Unit Testing approach.

    If a dev refused to allow code reuse for the DAL/BLL from a Winforms app into a Web app, I'd immediately suspect that UI specific code had somehow crept into the DAL/BLL.

  • PRMan (unregistered) in reply to wtf
    wtf:
    java.lang.Chris;:
    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.

    Works great if you're interviewing your twenty-year veteran employees. A good idea, perhaps, but not something that's done very often.

    Actually, this doesn't work at all if you are interviewing a 20-year veteran, since we invented all the best practices that you now call "Design Patterns". We don't know their new-fangled names, to us they are just called "no duh, don't be a first-year VB programmer".

  • facilisis (unregistered) in reply to Bosshog
    Bosshog:
    When I re-invent the wheel, I sometimes add new features. Like corners.

    So do I. You put a store-bought wheel on the ground, it rolls away. Not mine.

  • Barry (unregistered) in reply to SOLID Man
    SOLID Man:
    Writing DAL and BLL layers that are totally and completely decoupled from any UI technology (such as ASP.NET or WinForms) is actually quite difficult to do. The temptation to stick an HttpContext.Current or a Windows.Forms.Form in your BLL is always there. It requires a certain mindset towards development to write DAL/BLL layers like this, a mindset geared more towards SOLID principles and a TDD/Unit Testing approach.

    If a dev refused to allow code reuse for the DAL/BLL from a Winforms app into a Web app, I'd immediately suspect that UI specific code had somehow crept into the DAL/BLL.

    True it takes dicipline I sometimes find myself wantign to fall into that with data validation where you need UI prompts as the data goes in.

  • bd (unregistered) in reply to highphilosopher
    What you need is 1-5 GOOD Architect(s) that build the framework around which the developers can work.
    I wholeheartedly agree, frameworks produced by software architects are framework you have to work around a lot.
  • Jim Danby (unregistered) in reply to ObiWayneKenobi

    Bullshit.

    Just because you have worked at a company for a long time does not mean you are automatically useless. I could make the same argument that everyone that I have met with only one year or less at a company was rubbish. even if it were true (it isn't), one person's experience does not represent the entire planet.

  • Jay (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.

    If you literally mean that to be a competent programmer someone must have read those two specific books, and that no other books on the subject will suffice, well, that's just idiotic ... oops, I mean, I think that's a little narrow-minded. Do you honestly believe that those two books are the only books ever written on the subject that are worth reading?

    P.S. I've read GoF. I've neither read nor, I must admit, heard of the Fowler book. I guess this makes me completely unqualified to touch a computer.

  • Jay (unregistered) in reply to Jellineck
    Jellineck:
    "Ignoring the fact that is idiotic," Jeff replied, "why would we do that? The UI and the DAL are completely separate. It doesn't matter how we present the data, the DAL is just fetching it."

    Someone needs to work on his interpersonal skills. Everything after the word "idiotic" will always be ignored. He might as well have said "Ignoring the fact that is idiotic, I read the Twilight book and cried the whole time."

    Or at leat, "Ignoring the fact that this is idiotic, I read the GoF Design Patterns book and cried the whole time."

  • wtf (unregistered) in reply to Jay
    Jay:
    java.lang.Chris;:
    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.

    If you literally mean that to be a competent programmer someone must have read those two specific books, and that no other books on the subject will suffice, well, that's just idiotic ... oops, I mean, I think that's a little narrow-minded. Do you honestly believe that those two books are the only books ever written on the subject that are worth reading?

    No, he means that applying this test will avoid this problem. This will eliminate potentially good candidates, such as yourself, but evidently that's a trade-off that he likes. (I don't think it's very good advice, but it's obvious what he means)

  • Jay (unregistered)

    "For the umpteenth time in his tenure, he re-invented the wheel ..."

    Re-inventing the wheel is a stupid waste of time. That's why in the real world of wheeled vehicles, there is only one company in the world that makes wheels, they make exactly one kind, and it is used on all vehicles from passenger cars to children's tricycles to heavy construction equipment. Having different wheels for different kinds of vehicles would be insane. And of course the thought that someone might come up with improvements on the wheel has caused many people to waste countless hours fiddling with an invention that was already complete and perfect. The wheels used on chariots in 100 BC were good enough for Julius Caesar and they're good enough for me.

  • Me (unregistered) in reply to PRMan
    PRMan:
    wtf:
    java.lang.Chris;:
    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.

    Works great if you're interviewing your twenty-year veteran employees. A good idea, perhaps, but not something that's done very often.

    Actually, this doesn't work at all if you are interviewing a 20-year veteran, since we invented all the best practices that you now call "Design Patterns". We don't know their new-fangled names, to us they are just called "no duh, don't be a first-year VB programmer".

    I second this. The computer industry is packed with "new" ideas that have just been re-invented and re-named by somebody who didn't know they were already old news. Meanwhile, the old guys like me are looking at these "new" ideas and wondering what all the fuss is about.

    But if you're going to terminate the interview if I haven't read your favorite book, be sure to mention that in your ad. I can avoid wasting my time by coming to talk to you.

  • Vlad Patryshev (unregistered) in reply to iToad

    I agree, all those 20-year-veterans are mostly ignorant idiots. Refactoring is an insult to them. Well... even 10 years is too much. I've just left a company where a 10-year-veteran-architect threw away my unittests (in his niche, he never heard of them), because there was no "order from above" to do unittesting.

    I believe the only way to deal with them is to leave them alone. Let them code; there's enough places where people are up-to-date.

    (In case it sounds insulting to the veterans, I have to add that I started programming in 1970. Still learning, though.)

Leave a comment on “Code Refuse”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article