• Gumby (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.

    What if you're not an OO weenie, and you prefer functional or logic programming instead? Besides, I've worked with people who read such things, missed the whole point, and wrote superficially OO code that was just unrelated method/function calls grouped together in an arbitrary class.

    And why not include "Code Complete" in your list? I hear people recommend that also. I didn't get much out of it. I guess I have an uncanny grasp of common sense.

  • Marshall (unregistered) in reply to Gumby

    Warning - politically incorrect language follows ...

    (IMO) The ability to actually work in abstractions rises with intelligence. My guesstimate would be that the ability to use design patterns as part of a design process wouldn't kick in until at least the 80/90 percentile.

    So I agree with an earlier post that suggested you get your (few) architects who can do this and (once you trust them) make the foot soldiers follow the design even if they don't understand it.

    And as also posted, designing with patterns (or good OO design) is a skill an order of magnitude higher than answering an exam on the contents of the book.

  • Steve Parker (unregistered)

    So, the story is that a MSWindows program used MSWindows structures?

    As a Unix/Linux person, I would be very surprised if any interfaces (other than, say, direct access to the back-end database, through something structured such as SQL, XML, etc) would escape the MSWindows-specific stuff.

    What am I missing?

  • (cs) in reply to Gumby
    Gumby:
    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.

    What if you're not an OO weenie, and you prefer functional or logic programming instead? Besides, I've worked with people who read such things, missed the whole point, and wrote superficially OO code that was just unrelated method/function calls grouped together in an arbitrary class.

    And why not include "Code Complete" in your list? I hear people recommend that also. I didn't get much out of it. I guess I have an uncanny grasp of common sense.

    I agree with your basic premise, but just so you know: Design Patterns != OO.

  • not even 5 yrs experience. (unregistered) in reply to iToad

    Also, I would just point out that sometimes, they do not want to touch the already working code because it would require additional resources to verify that it still works. From a business perspective, they would only care about what costs less money. ofcourse there are very rare cases where its cheaper to refactor and fix the code. but in general from a developer's perspective its always better to fix the code now.

    If it ain't broken, don't fix it. (or use correct processes for that matter)

  • Jay (unregistered)

    A wise man once said -- not talking about IT but it probably applies to almost everything in life, It is just as foolish to embrace every new idea out of a love of novelty as it is to reject every new idea out of a fear of change.

    Yes, I've known plenty of programmers who refused to learn a new language because FORTRAN is perfectly good, why do we need this new-fangled stuff. On a less dramatic level, it is easy to fall into the trap of not being willing to learn something new because what you are able to get done what you need to get done with what you already know. The catch, of course, is that if you learned something new you might be able to do it better and faster, or you might be able to do things that you didn't know you really needed to do.

    But on the flip side, I've also known plenty of programmers who are constantly jumping on the latest bandwagon, who think they are great programmers because they know 100 languages or tools or frameworks. Except, they don't really know how to get anything useful done in any of them. They just know how to repeat what's in the marketing literature, and maybe put together a demo app that says "Hello, world."

  • Gary Wheeler (unregistered) in reply to iToad
    iToad:
    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.

    I get my '20' at my current employer this year. I find your generalities about long-term employees... disturbing.

    Most of the long-term types I know are bona fide experts at what they do. They bring a level of knowledge, experience, and pragmatic wisdom to a project that pays off in more robust solutions. Youngsters who fail to appreciate this invariably either re-invent the wheel or fail miserably.

    Even though it has become cliche, I'm reminded of this: I'll always take age and treachery over youth and zeal.

  • Hubert Humphrey (unregistered) in reply to Ed

    I believe I may have worked at that place. Briefly.

  • oksupra.com (unregistered)

    Supra shoes are so popular all over the world. Whatever you take on Supra being in the Supra Skytop Shoes market. Now Supra Strapped Shoes also very popular attention. It is nice that they actually took the time to make Supra Skate Shoes that work well. Supra shoes is a brand that has been inspired, designed and marketed by passionate individuals. We have brought to you the fullest selection of Supra footwear at cheapest price. Overload Skateshop carries a wide range of Supra Shoes to fit your 9-stair kickflips.

  • oksupra.com (unregistered)

    Supra shoes are so popular all over the world. Whatever you take on Supra being in the Supra Skytop Shoes market. Now Supra Strapped Shoes also very popular attention. It is nice that they actually took the time to make Supra Skate Shoes that work well. Supra shoes is a brand that has been inspired, designed and marketed by passionate individuals. We have brought to you the fullest selection of Supra footwear at cheapest price.

  • Programmer (unregistered) in reply to iToad

    I've heard this for the first time from a manager of a previous job a couple years ago, and... oh boy... so many times I've seen it proven it right (the sad way, unfortunately)!

  • Stewie (unregistered) in reply to iToad

    [quote user="iToad"][quote user="ObiWayneKenobi"]

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

    BEST Quote EVER ! !!

  • (cs) in reply to iToad

    Actually, I believe things were in much better shape when people did spend their careers with one company. There was significant value to be gained by the company investing in the person. These days, that is gone.

    As a concrete example, I worked for the samecompany from 1977 until 1992, and only left when the defnense industry crashed. It was fairly common for an engineer to spend 1 or even 2 weeks at company funded (all expenses) training, along with additional time for smaller seminars, conferences, etc.

Leave a comment on “Code Refuse”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article