Red flags. Red flags everywhere.



  • What is with all the shitty job listings? Why are so many companies going to all the trouble and expense of getting recruiters involved only to then dash out a half-baked job listing? A lot of this garbage I keep seeing makes me do this: http://i.imgur.com/kiLB1.gif

    A lot of them are fucking up really really simple stuff like spelling the names of the technologies they use correctly. If I read a job listing that mentions "My SQL", "MYSQL" or "MySql" as something with which it's desirable for candidates to have experience, this instantly calls into question the potential employer's level of commitment to quality. If you're willing to pay a recruiter some large N% of starting salary, how are you not insisting on one that can at least spell the name of the technologies you use correctly?

    And what kind of half-assed hiring strategy consists of telling somebody a list of six acronyms and a job title? You say you're looking for a web developer who has experience with HTML, CSS, and AJAX? Should my own list of requirements be similarly vague? Perhaps I should change my resume to say that I am a developer with a vacancy for an employer with experience in offices, desks, chairs and providing internet connections for employees.

    The successful IT Employer / Company will have:

    • CEO, CTO/HR
    • ARPU
    • PBT/PAT
    • Leadership experience

    The overall impression I get from this landscape of phoned-in job listings is a marketplace full of employers who think that the reasons why I should want to work for them are self-evident and they merely need to provide the most tantalising glimpse into their working environment for me to come beating down their door. How about you tell me something substantial about what exactly makes your workplace better than the next? You know, like you expect me to do in my application? And no, stipulating that you "use source control" does not count. If anything, proudly boasting about your usage of the most utterly fundamental tool in software makes me imagine that you've only begun doing so recently and are still in awe of yourself.

    Other red flags:

    • Listing both HTML and XHTML as "required technical skills" as if listing both in any way helps candidates self-select better or gauge their own interest in the role
    • Claiming that the company is going to "change the face of the world as we know it"
    • Claiming that the company is going to "change the face of the world as we know it" using Drupal
    • Mentioning AJAX skills as if most of the other companies hiring are still churning out purely static HTML pages like it's 2003
    • Saying that your application(s) are "complex" as if most of the other companies out there looking to drop several tens of thousands on developer salary to build a couple of quick forms now and again
    • Saying how many developers you need (e.g. 3x web developers) as if we are some sort of cattle that only interview in large herds

    If the only interesting detail in your job listing is that I will need to "hit the ground running", then all you have told me is that your client will stop at nothing to meet deadlines and has just had a developer quit.



  • @GNU Pepper said:

    Claiming that the company is going to "change the face of the world as we know it"

    That would actually be a pretty good slogan for a mining company.



  • @Salamander said:

    @GNU Pepper said:

    Claiming that the company is going to "change the face of the world as we know it"

    That would actually be a pretty good slogan for a mining company.

    I actually thought this was such a clever idea that it must definitely already exist out there. So I googled it, and surprisingly your post in this thread was already top result. And thanks to the magic of timezone conversion, you said it 16 hours before you actually said it!






  • @GNU Pepper said:

    Mentioning AJAX skills as if most of the other companies hiring are still churning out purely static HTML pages like it's 2003

    You'l be surprise how much candidates resume for web position i saw that don't have ajax skills!

     Also, acronyms are used in such documentnts so that they trigger more search engine results for the potential candidates. I totally agree on about everything you said by the way, so much position without even the slightest description of which company is hiring :)

     


  • Discourse touched me in a no-no place

    @tchize said:

    I totally agree on about everything you said by the way, so much position without even the slightest description of which company is hiring :)
    If the adverts themselves are placed by recruiters 'on behalf of the hiring companies' they don't necessarily want you going direct to the company. At least that's my assumption. The last advert I replied to was placed direct by the hiring company and they had their details on the advert.



  • @GNU Pepper said:

    stipulating that you "use source control" does not count. If anything, proudly boasting about your usage of the most utterly fundamental tool in software makes me imagine that you've only begun doing so recently and are still in awe of yourself.
     

    In some ways, pointing out that you use source control means (a) any new employee is expected to follow suit, and (b) you will learn how to checkin/out using the tool of their choice. It doesn't necessarily imply they're doing things correctly, but a non-WTF employer may use that criteria as a filter to block potential loose cannons that don't practice proper change control - or even aware that it exists.

    @GNU Pepper said:

    If the only interesting detail in your job listing is that I will need to "hit the ground running", then all you have told me is that your client will stop at nothing to meet deadlines and has just had a developer quit.

    Erm.. yeah. Vacancies that expect me to get up to speed "quickly" ring alarm bells for me. Doesn't mean I expect to sit around for the first six months doing bugger all, but it does sound like approaching deadlines, crunch and pressure are beckoning wiht open arms.

    I'll avoid that embrace, thanks.

     



  • I've found much the same thing happening for people who want to sell houses or cars through websites. People who want me to pay -say- 100.000 for an apartment. They don't bother to include more than two pictures of the apartment, both from the outside. They don't list the features of the apartment. They "mistype" the area, so on the website it reads "44 sq meters" and when you call it's 54 sq meters. They are offended and all huffy when I call them on the phone they wrote in their ad (I should have magically known to call another number, or contact via email only). They don't reply. They are surprised when I ask them if I can see the apartment outside working hours.

    I wonder sometimes if they actually want my money at all.



  • There are a few reasons for these crappy job listings. My wife works as a recruiter (not IT) but other branches of her company do.

    " trouble and expense of getting recruiters" This is not true. Recruiters bend every which way for clients. They only get paid when a person is hired.

    "only to then dash out a half-baked job listing" A lot of times, the people writing the job posting are the recruiters. By the time they get the requirements, the hiring manager has written something basic, then HR has played with it, then it finally gets to the recruiter who has to write up the final. By the time it gets on the site, they are so wonky because HR has messed with the wording That's where crap like having an internet connection, and comfortable chairs come from. The recruiter then adds tons of acronyms to cast a wide net for potential applicants.

    A lot of the crappier postings are what are known in the industry as "Magnet Postings". Designed solely for the purpose of increasing their pool of candidates.



  • @GNU Pepper said:

    What is with all the shitty job listings? Why are so many companies going to all the trouble and expense of getting recruiters involved only to then dash out a half-baked job listing? A lot of this garbage I keep seeing makes me do this: http://i.imgur.com/kiLB1.gif

    [[snip]]

    And no, stipulating that you "use source control" does not count. If anything, proudly boasting about your usage of the most utterly fundamental tool in software makes me imagine that you've only begun doing so recently and are still in awe of yourself.

    Reading TDWTF has given me two more questions to ask when I am interviewing for a job: "What do you use for source control?" and "What do you use to back up?"

    Any place that answers "Nothing" to either of these will be a WTF factory and I am unlikely to accept a job there.



  • @D-Coder said:

    @GNU Pepper said:

    What is with all the shitty job listings? Why are so many companies going to all the trouble and expense of getting recruiters involved only to then dash out a half-baked job listing? A lot of this garbage I keep seeing makes me do this: http://i.imgur.com/kiLB1.gif

    [[snip]]

    And no, stipulating that you "use source control" does not count. If anything, proudly boasting about your usage of the most utterly fundamental tool in software makes me imagine that you've only begun doing so recently and are still in awe of yourself.

     

    Reading TDWTF has given me two more questions to ask when I am interviewing for a job: "What do you use for source control?" and "What do you use to back up?"

     

    Any place that answers "Nothing" to either of these will be a WTF factory and I am unlikely to accept a job there.
    One of my top must-ask questions is the ever-important "two-ply, or three"?


  •  I try and use the employee restroom; to see if it has gas-station quality paper, or comfortable softpaper.

    It's a major flag if they are BYOTP.



  • @C-Octothorpe said:

    One of my top must-ask questions is the ever-important "two-ply, or three"?
    ...or do I need to bring my own?!?



  • @GNU Pepper said:

    You say you're looking for a web developer who has experience with HTML, CSS, and AJAX?
     

    Some places actually want proof...



  • This reminds me of the WTFery associated with my company's hiring practices, especially how initially our listings amounted to "Looking for developer. Required skills: HTML, Javascript, PHP". Because telling what we actually do or mentioning that we're a WordPress shop would somehow enable our competitors to guess our secret sauce and price us out of the market. Likewise with any other technology that we use.

    It took me two hiring cycles (ie. failed attempts to attract any attention) to convince the boss that mentioning WordPress would not magically make us uncompetitive and might, in fact, help when looking for a WordPress admin/coder.

    Then again, "PHP/HTML/Javascript" is restrictive enough when the boss stubbornly refuses to hire anyone who isn't currently a student at the local university. Which has absolutely zero courses involving PHP. He has no idea why we get so few applicants.


  • Discourse touched me in a no-no place

    @D-Coder said:

    @GNU Pepper said:

    What is with all the shitty job listings? Why are so many companies going to all the trouble and expense of getting recruiters involved only to then dash out a half-baked job listing? A lot of this garbage I keep seeing makes me do this: http://i.imgur.com/kiLB1.gif

    [[snip]]

    And no, stipulating that you "use source control" does not count. If anything, proudly boasting about your usage of the most utterly fundamental tool in software makes me imagine that you've only begun doing so recently and are still in awe of yourself.

    Reading TDWTF has given me two more questions to ask when I am interviewing for a job: "What do you use for source control?" and "What do you use to back up?"

    Any place that answers "Nothing" to either of these will be a WTF factory and I am unlikely to accept a job there.

    Or just use the the Joel Test.



  • In my experience, don't trust blanket questions like "So what do you use for source control" or the Joel Test.  Ask questions, sure, but also drill them on best practices using them.  My former employer could proudly claim they used Subversion, but they didn't understand branching or tagging and created separate repositories for every release of the project; they would score a point on the Joel Test since they technically DID use version control.

    I make it a point when interviewing for a developer role to question the environment.and the tools not to gauge what's being used, but if it's being used correctly.  For example, I'll ask what is used for version control.  I mentally grade answers as follows:

    Nothing or Visual Source Safe: Red flag, run away
    TFS/Subversion: Acceptable; question how they use it (e.g. "So how do you branch/tag?") and if they seem to be clueless, run away
    Git/Mercurial: Probably know what they're talking about.

    Or I'll ask about what kind of ORM they use for data access:

    None: Red flag, run away
    NHibernate or a Micro-ORM: Probably know what they're talking about
    Linq/EF/Subsonic/Other: Acceptable

    Or, if they're doing .NET web development, what platform.  MVC is great, MVC with older WebForms w/MVP is okay, pure WebForms without any kind of presentation layer is a big red flag and shows they're clueless idiots living in the stone age.

    In short, don't accept an answer without delving into the details.  Otherwise you might end up in a company wrting .NET 1.1 code on the 4.5 platform because when you asked what version they were on they said 4.5 despite not actualy using any 4.5 features.

     I find there are a lot more companies that will just mislead their environment because they know the truth would scare people away.  You have no way of knowing these things in an interview without actually asking detailed questions, not just "Do you test code" becasue the answer might be yes, but they don't mean unit tests or automated testing they mean manually prodding an app in IE.


  • Trolleybus Mechanic

    @FrostCat said:

    Or just use the the Joel Test.
     


    Always fun to revisit that one. Let's see how the current employer's doing:

    1. Do you use source control?

    We use Visual Studio 6.0... so, no.

    2. Can you make a build in one step?

    What's a build?

    3. Do you make daily builds?

    Seriously, stop talking with those fancy terms. You're too academic. Copy and paste to a shared drive worked well in 2001, it works just fine today. Now go spend 4 hours copy and pasting your "package"

    4. Do you have a bug database?

    Does my inbox full of Word documents from the QA guy count?

    5. Do you fix bugs before writing new code?

    While writing new code. While.

    6. Do you have an up-to-date schedule?

    Every day, I get asked by the boss "What's on your plate?" The answer's forgotten until the day before he'd promised a feature to a client. Aside from that, what deadlines? I'm going to simplify this: no.

    7. Do you have a spec?

    I have tons of specs. All hand drawn scribbles by either the boss or the client, sometimes scanned into One Note. They're incomplete, contradictary, and dozens of man hours have to go into revising them by phone and email. I do have one really good spec doc for a large project, because I aboslutely insisted the client hash out all the details that were fiddling about in her slippery mind.  So yes for "you" as in me, no for "you" as in the company. I'll give it a half a point, rounded down.

    8. Do programmers have quiet working conditions?

    This one's not too bad. Except for when anyone's on the phone. Or discussing. Or being yelled at. Or typing. However, I do have ear phones, there's no sales floor, and the AC runs quiet. I'll give it half a point, rounded up.


    9. Do you use the best tools money can buy?

    I'm going to grudgingly give this a yes, because the boss will buy the tools, but if they're inexpensive, or he's convinced they're really good. I have a quad core computer with a dual monitor, and a fully licensed copy of Beyond Compare. No source control, though.


    10. Do you have testers?

     A tester, but that's on par for 3 programmers. He's good, but overworked, and is pulled onto many non-testing tasks like documentation and support. On my insistance, we're finally making clients do indepth UAT before shipping code. Half a point, rounded up.


    11. Do new candidates write code during their interview?

    Yes. At least I had to write some SQL queries.

    12. Do you do hallway usability testing?

     Does asking the QA guy "have you looked at my code" when he goes to get a tea count?  Quarter of a point, rounded down.

    So total score: 4. Really, 3.5. Sigh.


  • Trolleybus Mechanic

    @ObiWayneKenobi said:

    pure WebForms without any kind of presentation layer is a big red flag and shows they're clueless idiots living in the stone age.

    @ObiWayneKenobi said:

    Or I'll ask about what kind of ORM they use for data access:

    None: Red flag, run away

    @ObiWayneKenobi said:

    Nothing or Visual Source Safe: Red flag, run away
     

    @ObiWayneKenobi said:

    "Do you test code" becasue the answer might be yes, but they don't mean unit tests or automated testing they mean manually prodding an app in IE.

    {weep}

     

     



  • @ObiWayneKenobi said:

    In my experience, don't trust blanket questions like "So what do you use for source control" or the Joel Test.

    Only a pedantic dickweed would assume Joel meant to go down the list and accept only yes/no answers with no discussion.

    @ObiWayneKenobi said:

    Git/Mercurial: Probably know what they're talking about.

    Hm.

    @ObiWayneKenobi said:

    Or I'll ask about what kind of ORM they use for data access:

    None: Red flag, run away
    NHibernate or a Micro-ORM: Probably know what they're talking about
    Linq/EF/Subsonic/Other: Acceptable

    Do you count "stored procedures" as an ORM? Or phrased another way, why exactly is "none" a red flag?

    @ObiWayneKenobi said:

    pure WebForms without any kind of presentation layer is a big red flag and shows they're clueless idiots living in the stone age.

    What if it's an internal site and not public-facing? /contrarian



  • Here's mine, for the project I was not hired to do, but brought into because it's run by assholes who have no clue what they're doing at all:

    1) Source control? Git, but I keep having to prod people to actually upload the fucking code to the fucking server. Mock Subversion and TFS if you want, but at least they FORCE you to upload the code before you can call a check-in "finished".

    2) Build in one step? Not really. It's a bunch of fucking Ruby bullshit, so "build" consists of copying the files around and manually tweaking the DB schema if needed.

    3) Daily Builds? Eh, about 2-3 times a week, I'd say close enough

    4) Bug database? Just started one this week; but having trouble getting the assholes to put in features. "Can you work on feature X?" "No because you've never described to me what feature X is, how it should work, and it's not in the bug tracker."

    5) Fix bugs before writing new code? By necessity usually, but still a yes

    6) Up-to-date schedule? Made one 3 weeks ago when the competent people took over from the incompetent people, but yes.

    7) Do you have a spec? Nope, see 4. Just an extremely vague SOW, and whatever's in the asshole programmer's skull.

    8) Quiet working conditions? Not in my office, fuck, I can never get shit done.

    9) Best tools money can buy? I'd say that Ruby and Git are about the WORST tools. You can't buy a working debugger for Ruby for a billion dollars at the moment; it simply does not exist. The Portland engineers all have super-fancy expensive Apple computers, as if that would miraculously make their Ruby code less fucking awful.

    10) Testers? Hahahahaha no. Engineers who have downtime click-around in a browser a bit and call it "testing" though.

    11) Candidates write code during interview? I didn't, but I'll ensure any future candidates do.

    12) Hallway usability testing? Yes, surprisingly.

    That adds up to a final score of about 5.5 or so.

    BTW, we should write a Joel Test for programming environments, since I didn't imagine in a million years how awful the Ruby ecosystem actually is. It should be something like this:

    1) Does your language have automatic memory management?
    2) Can it be used to write portable applications?
    3) Do quality tools exist to make a GUI using native widgets and behavior, with in a WYSIWYG editor?
    4) Does a quality IDE exist for the environment?
    5) Does a quality "auto-format" utility or feature exist for the environment?
    6) Does a quality debugger exist for the environment?
    7) Does a mechanism for automatically downloading/updating dependencies exist for the environment?

    .net hits all 7, now that it has Nuget. Ruby hits maybe 3 or 3.5.



  • Do you count "stored procedures" as an ORM? Or phrased another way, why exactly is "none" a red flag?

    No, and in fact being a stored proc shop is 99% of the time a red flag as well, or if not a true red flag at leat it sends up caution because relying on sprocs went out of favor around 2004, so anyone still relying on it for **new** development is behind the times.  Why?  Because modern software develompent, and craftsmanship, is about using the best tools for the job and relying on hand-written SQL and raw connections (and worse DataSets/DataReaders) when there are better alternatives means the company doesn't evolve.  None is a red flag because there's little to no reason in a modern development shop to not use a tool for database mapping, whether it's a homebrew solution (still not a good option, but better than nothing), a Micro-ORM like Dapper, or a full blown ORM like NHibernate or the Entity Framework.

     So i guess the answer is maybe.  Stored Procedures with DataSets and DataReaders is bad.  Stored Procedures with some kind of factory pattern to map the data to objects is acceptable, but not great.  IMO the best option is to not even bother with sprocs and use a real tool.

    What if it's an internal site and not public-facing? /contrarian

    IMO it's still a red flag.  It's possibly acceptable if it's some legacy app that is barely used and infrequently updated, but for **new** development there's no reason to still be using raw WebForms like it was 2002 beyond being lazy, ignorant, or both.  Even WebForms with Supervising Controller is circa 2006, over half a decade ago, and most serious .NET developers moved to MVC when version 1.0 came out, almost 3 years ago.  There's very little reason to still be using WebForms for anything new, and even if it is the better choice (heavy form-driven app for instance) there's never a reason to do it without applying some design patterns.



  • @blakeyrat said:

    2) Can it be used to write portable applications?

    ...

    .net hits all 7

    Depends what you count as portable.  If you mean different OSes but in the same set sure, but otherwise you are relying on mono which means "maybe if you're lucky".



  • @ObiWayneKenobi said:

    No, and in fact being a stored proc shop is 99% of the time a red flag as well, or if not a true red flag at leat it sends up caution because relying on sprocs went out of favor around 2004, so anyone still relying on it for new development is behind the times.

    Sprocs do things ORMs don't. For example, sprocs have their own permission system enforced by the database engine itself. You can give your web server different permissions (read-only) from your back-end data importer service. That's a good thing.

    @ObiWayneKenobi said:

    Why? Because modern software develompent, and craftsmanship, is about using the best tools for the job and relying on hand-written SQL and raw connections (and worse DataSets/DataReaders) when there are better alternatives means the company doesn't evolve.

    How are ORMs better? You forgot to actually give a reason. I gave one reason they're worse.

    @ObiWayneKenobi said:

    None is a red flag because there's little to no reason in a modern development shop to not use a tool for database mapping, whether it's a homebrew solution (still not a good option, but better than nothing), a Micro-ORM like Dapper, or a full blown ORM like NHibernate or the Entity Framework.

    What about working with Twitter or Facebook data which is 1) constantly changing, 2) delivered in a multi-level format (JSON)? How does your ORM deal with that? The schema is "whatever Twitter happens to send you." (Which is not to say sprocs are better at it... frankly both solutions suck.)

    @ObiWayneKenobi said:

    So i guess the answer is maybe.  Stored Procedures with DataSets and DataReaders is bad.

    Not convinced.

    @ObiWayneKenobi said:

    Stored Procedures with some kind of factory pattern to map the data to objects is acceptable, but not great.

    Why?

    @ObiWayneKenobi said:

    IMO the best option is to not even bother with sprocs and use a real tool.

    You do your thing and I'll do mine. You haven't convinced me yet. In fact, you've given almost very reasons for preferring ORMs.

    Your main argument seems to be "if it's popular, it's the best way!" That especially comes through with your WebForms paragraph.



  • @blakeyrat said:

    @ObiWayneKenobi said:
    No, and in fact being a stored proc shop is 99% of the time a red flag as well, or if not a true red flag at leat it sends up caution because relying on sprocs went out of favor around 2004, so anyone still relying on it for new development is behind the times.

    Sprocs do things ORMs don't. For example, sprocs have their own permission system enforced by the database engine itself. You can give your web server different permissions (read-only) from your back-end data importer service. That's a good thing.

    @ObiWayneKenobi said:

    Why? Because modern software develompent, and craftsmanship, is about using the best tools for the job and relying on hand-written SQL and raw connections (and worse DataSets/DataReaders) when there are better alternatives means the company doesn't evolve.

    How are ORMs better? You forgot to actually give a reason. I gave one reason they're worse.

    @ObiWayneKenobi said:

    None is a red flag because there's little to no reason in a modern development shop to not use a tool for database mapping, whether it's a homebrew solution (still not a good option, but better than nothing), a Micro-ORM like Dapper, or a full blown ORM like NHibernate or the Entity Framework.

    What about working with Twitter or Facebook data which is 1) constantly changing, 2) delivered in a multi-level format (JSON)? How does your ORM deal with that? The schema is "whatever Twitter happens to send you." (Which is not to say sprocs are better at it... frankly both solutions suck.)

    @ObiWayneKenobi said:

    So i guess the answer is maybe.  Stored Procedures with DataSets and DataReaders is bad.

    Not convinced.

    @ObiWayneKenobi said:

    Stored Procedures with some kind of factory pattern to map the data to objects is acceptable, but not great.

    Why?

    @ObiWayneKenobi said:

    IMO the best option is to not even bother with sprocs and use a real tool.

    You do your thing and I'll do mine. You haven't convinced me yet. In fact, you've given almost very reasons for preferring ORMs.

    Your main argument seems to be "if it's popular, it's the best way!" That especially comes through with your WebForms paragraph.

    You should probably clarify what you mean by a sproc, since I think Mr. Kenobi's sproc experience is limited to:

    EXEC sp_executesql @query

  • Considered Harmful

    @pkmnfrk said:

    EXEC sp_executesql @query

    It's a good thing you're using parameters to protect yourself from injection.



  • @ObiWayneKenobi said:

    Because modern software develompent, and craftsmanship, is about using the best tools for the job and relying on hand-written SQL and raw connections (and worse DataSets/DataReaders) when there are better alternatives means the company doesn't evolve. 

    At my last gig I had to deal with several 12000+ line sprocs written by an ex-mainframe programmer who thought "C# is stupid; SQL rocks". These beasts were used to fill large DataSets which were subsequently passed all the way up to .aspx code-behinds and manipulated directly. I left that place a year ago and I can still work myself into a foaming rage thinking about it.



  • @pkmnfrk said:

    You should probably clarify what you mean by a sproc, since I think Mr. Kenobi's sproc experience is limited to:

    EXEC sp_executesql @query

    haha no doubt.

    I think his worship of ORMs is just the same old, "I'm a programmer I'm so SCARED of learning SQL! SQL frightens me!" we see so much here as a source of WTFs.


  • ♿ (Parody)

    @blakeyrat said:

    I think his worship of ORMs is just the same old, "I'm a programmer I'm so SCARED of learning SQL! SQL frightens me!" we see so much here as a source of WTFs.

    Possibly. IME, ORMs are in general an improvement over having to hand write SQL. Of course, for lots of things, their performance isn't sufficient, so you still have to know SQL. But for lots of things, it's a lot simpler and helps the developer write correct code more quickly, like many other modern software development tools.



  • You should probably clarify what you mean by a sproc, since I think Mr. Kenobi's sproc experience is limited to:
    EXEC sp_executesql @query

    No, I've worked with real sprocs.  I still prefer ORMs because it lets me apply domain-driven design, design patterns and have sophistocated mapping from SQL to my business objects.  Not trying to be the guy preaching "sprocs are evil" since they aren't, and have their place, just I dislike them for standard CRUD type code for displaying data screens. 

    I know how to write SQL, so I'm not "afraid" of it, just for CRUD scenarios I don't see the point when I can use a tool to make it easier with little performance hit AND not have to waste time building my own business objects with a factory method (although again that's better than returning a DataSet to the clonsuming code).  FWIW I'm a big fan of views, especially for aggregate user screens.

    I tend to follow the "best of the best" .NET developers (e.g. Rob Conery, Ayende Rahien, Jeremy Miller, etc. the guys who write books and give talks about best practices) and the common concensus is that sprocs are outdated; at least in many years I haven't seen anyone suggest sprocs, it's usually NHibernate or the like, or even a document database like Ayende's RavenDB.  At the very least you should be using an abstraction of some kind so you return domain objects or DTOs, not raw DataSets.  So it boils down to somebody with many years more experience says MVC is the way to go, and they give talks and write books and everything, I'm inclined to believe they know better than some random developer working at random e-commerce company for 5 years.

    There's pretty much no redeeming qualities for WebForms though.  Maybe version 4.0 where you can have consistent naming but the prior versions are garbage, meant to hide away how the web really works to attract VB6 drag and drop guys to the web.  Not to mention you can't have automated tests for WebForms without using M-V-P or similar patterns.


  • Discourse touched me in a no-no place

    @Lorne Kates said:

    8. Do programmers have quiet working conditions?

    This one's not too bad. Except for when anyone's on the phone. Or discussing. Or being yelled at. Or typing. However, I do have ear phones,...

    Or they eating, scraping the last remenents off the crockery for 5 minutes. Or burping afterwards.

    Or on their own ear phones listening to their music and are pretending they're in the band they're listening to and using their desk as a percussive instrument. Loudly.

    Or, knowing the (I'm assuming false) floor reverberates, and they tromp around like a lost heffalump every time they move from their seat. To talk to someone. To go to the toilet to wipe/wash their hands after they've sneezed snot into them because they don't have tissues near by (more than 5 times a week.) To go feeding (see above) and come back etc.

    Oh, and annoying ringtones on their mobiles. And they get called more than once a day. And leave their mobile on their desk when they decide to 'wander off' for 1/2 hour.

    And that's just the bloke who's next to me in the office. There are 6 of us in that little bit of 'open office.' Thankfully the other 4 aren't quite as annoying, though whether that's function of distance or they simply aren't as bad, I'm not sure.


  • @ObiWayneKenobi said:

    So it boils down to somebody with many years more experience says MVC is the way to go, and they give talks and write books and everything, I'm inclined to believe they know better than some random developer working at random e-commerce company for 5 years.

    Maybe, but a lot of people with many years experience can't write software worth shit. See: Ray Ozzie for one example.

    I prefer to think for myself and come up with my own opinions. You should try it. It's freeing.



  • @ObiWayneKenobi said:

    data screens.

    BTW I love that you don't like sprocs because you think they're "outdated", and then you use crazy 1970s terminology like "data screens". What's up with that?



  •  Most of the web developers I've met have at best a basic understanding of what css is. Most know of ajax as this fancy technology they have heard of.  While I agree these are basic skills at this point that should be expected its actually still rare.  Most of the ajax proficient developers I know are working for software focused companies.

     

    We recently were looking for datawarehouse developers at my company.  It took us months to find a candidate who could join two tables.  Even then they were surprised when I asked what a common table expression (CTE) was.  This has been a basic structure of the t-sql language since SQL Server 2005.



  • @ObiWayneKenobi said:

    You should probably clarify what you mean by a sproc, since I think Mr. Kenobi's sproc experience is limited to:
    EXEC sp_executesql @query

    No, I've worked with real sprocs.  I still prefer ORMs because it lets me apply domain-driven design, design patterns and have sophistocated mapping from SQL to my business objects.  Not trying to be the guy preaching "sprocs are evil" since they aren't, and have their place, just I dislike them for standard CRUD type code for displaying data screens. 

    I know how to write SQL, so I'm not "afraid" of it, just for CRUD scenarios I don't see the point when I can use a tool to make it easier with little performance hit AND not have to waste time building my own business objects with a factory method (although again that's better than returning a DataSet to the clonsuming code).  FWIW I'm a big fan of views, especially for aggregate user screens.

    I tend to follow the "best of the best" .NET developers (e.g. Rob Conery, Ayende Rahien, Jeremy Miller, etc. the guys who write books and give talks about best practices) and the common concensus is that sprocs are outdated; at least in many years I haven't seen anyone suggest sprocs, it's usually NHibernate or the like, or even a document database like Ayende's RavenDB.  At the very least you should be using an abstraction of some kind so you return domain objects or DTOs, not raw DataSets.  So it boils down to somebody with many years more experience says MVC is the way to go, and they give talks and write books and everything, I'm inclined to believe they know better than some random developer working at random e-commerce company for 5 years.

    There's pretty much no redeeming qualities for WebForms though.  Maybe version 4.0 where you can have consistent naming but the prior versions are garbage, meant to hide away how the web really works to attract VB6 drag and drop guys to the web.  Not to mention you can't have automated tests for WebForms without using M-V-P or similar patterns.

     

     

    Adam Machanic put it best when he said "TSQL is not code, It's not a set of instructions which the database will follow.  Its a request.  We tell the database engine what we want and the engine figures out a plan to get it".

     Stored Procedures are not outdated.  They can be performance boon or hinderance depending on how they are used and are susceptible to the same issues as ad hoc sql.  If you have more than one application accessing your databases, encapsulating the data logic can make it easier to maintain.

     I'm not against ORMs. I just want to make sure that whoever is creating that layer knows that tool inside out.  I've seen ORMs used in such a way that it brings a server to its knees and I've seen ORMs used with large databases that worked flawlessly.  It all depends on the skill of the developer with that ORM.

    I like MVC.  I've used it to convert old classic asp applications to .net and to build new applications from the ground up.  And I find I can build an application faster with MVC than with webforms.

     



  • The Joel Test was obviously not written with the Real World™ in mind.

    1. Do you use source control?
    Yes. No branching or tagging, though, because no one in the company knows how they work and reading up on them would cost valuable development time.

    2. Can you make a build in one step?
    Builds and packages are unneccessary. We just directly stage to the production server via FTP through our mid-tier consumer DSL line and then connect to phpMyAdmin and modify the database if neccessary.

    3. Do you make daily builds?
    No, and it wouldn't work anyway because our average time between source control checkins is somewhere around three weeks.

    4. Do you have a bug database?
    No. The developers don't have time to set up something like that until the system we're working on is done and bug-free. It would take away valuable coding time, you see, and we can just use text files anyway.

    5. Do you fix bugs before writing new code?
    Only if that code isn't top-priority. We have no priorities other than "top", of course. It's a good week when I can finish one bit of functionality before I have to drop it to start work on something else that needs to be done "right now".

    6. Do you have an up-to-date schedule?
    Yes. That schedule is "I expected your one-man team to write this ERP system with specs known only to me in three months. Why aren't you done yet?".

    7. Do you have a spec?
    The boss knows what he needs. He won't tell me but I'm a developer. I'm supposed to know based on the screenshots of a legacy system he once sent me.

    8. Do programmers have quiet working conditions?
    No but at least I have headphones. Of course I can't set them too loud or I can't be interrupted. Which would be bad since in our company "developer" and "tech support" are synonymous.

    9. Do you use the best tools money can buy?
    We have a spending freeze until our system is completly done. The boss has promised everyone a Mac after that, although it's dubious whether actual productivity tools other than Adobe Creative Suite would be greenlit. So... Does the trial version of Sublime Text count?

    10. Do you have testers?
    Why would you need testers? Just insist that the devs get it right the first time. Duh.

    11. Do new candidates write code during their interview?
    Yes, but mainly because in our company developers conduct the hiring interviews and I've heard of the term "FizzBuzz".

    12. Do you do hallway usability testing?
    Hallway what?

    That's two out of ten, which is what my boss would argue is "how every company operates". So obviously the test must be faulty.



  • @j6cubic said:

    That schedule is "I expected your one-man team to write this ERP system with specs known only to me in three months. And we're having this conversation on the 29th day of month 3. Why aren't you done yet?".

    FTFY



  • @j6cubic said:

    That schedule is "I expected your one-man team to write this ERP system with specs known only to me in three months. Why aren't you done yet?".
     

    "The specs are known only to you. The reasons for the delay are known only to us."

    @j6cubic said:

    The boss knows what he needs. He won't tell me but I'm a developer. I'm supposed to know based on the screenshots of a legacy system he once sent me.

    I'd create a prototype (or even an image) that shows a fascade exactly matching the screenshots. Requirements fulfilled, job done.



  • Wow.

    We score 8 on the Joel test.

    We are awesome.



  • @ObiWayneKenobi said:

    You should probably clarify what you mean by a sproc, since I think Mr. Kenobi's sproc experience is limited to:

    EXEC sp_executesql @query

    No, I've worked with real sprocs.  I still prefer ORMs because it lets me apply domain-driven design, design patterns and have sophistocated mapping from SQL to my business objects.  Not trying to be the guy preaching "sprocs are evil" since they aren't, and have their place, just I dislike them for standard CRUD type code for displaying data screens. 

    I know how to write SQL, so I'm not "afraid" of it, just for CRUD scenarios I don't see the point when I can use a tool to make it easier with little performance hit AND not have to waste time building my own business objects with a factory method (although again that's better than returning a DataSet to the clonsuming code).  FWIW I'm a big fan of views, especially for aggregate user screens.

    I tend to follow the "best of the best" .NET developers (e.g. Rob Conery, Ayende Rahien, Jeremy Miller, etc. the guys who write books and give talks about best practices) and the common concensus is that sprocs are outdated; at least in many years I haven't seen anyone suggest sprocs, it's usually NHibernate or the like, or even a document database like Ayende's RavenDB.  At the very least you should be using an abstraction of some kind so you return domain objects or DTOs, not raw DataSets.  So it boils down to somebody with many years more experience says MVC is the way to go, and they give talks and write books and everything, I'm inclined to believe they know better than some random developer working at random e-commerce company for 5 years.

    There's pretty much no redeeming qualities for WebForms though.  Maybe version 4.0 where you can have consistent naming but the prior versions are garbage, meant to hide away how the web really works to attract VB6 drag and drop guys to the web.  Not to mention you can't have automated tests for WebForms without using M-V-P or similar patterns.

    I agree that MVC is vastly superior to webforms; however, to say that webforms has no benefits, and then to go as far as to call it a red flag is asinine. Making a complex form, especially with ajax updates, takes half the time in webforms.

    Also, to say that not using a ORM is a redflag is very shortsighted. Yes, I do like a ORM better for simple CRUD. However, sometimes, Linq 2 Entities will just crap out and not work for a very complex data-model. Not to mention, the performance can be abysmal. Also, you seem to be making the assumption that if you don't use an ORM that you are using a DataReader directly in the UI; it is possible to transfer the data from a datareader to a model inside a repository you know...

    Also, you seem to be speaking like sprocs and ORMs are mutually exclusive... in L2E you can form entities off of a sproc; it's very convienent for when you have a complex join that is heavily used!



  • @FrostCat said:

    Or just use the the Joel Test.


    Did you know Joel invented an in house language called Wasabi? He really jumped the shark!



  • Can someone explain to me what advanced stored procs do?  That way I know whether I've used them or not.



  • @dhromed said:

    Wow.

    We score 8 on the Joel test.

    We are awesome.

    Then I guess we are even more awesome: just looking at it straight and honest, without shifty half-thruths, we still score a full 12/12 on 'the Joel test'. Ridiculous, I know. Goes to show that the test by itself can't paint the whole picture.

    Admittedly; it might also be spot on. We really do have a very low level of WTFery going on. Most of what we deal with is documented crap from legacy code that was written over a decade ago and we're regularly authorized to go in and clean part of it up. It's kind of eery that from junior developer up to management everyone seems to just be generally competent at what they do. Even the interns turn out OK. (This would kind of make us the antithesis to Snoofle's employer, wouldn't it?)

    @this_code_sucks said:

    Making a complex form, especially with ajax updates, takes half the time in webforms.

    Making it takes half the time. Maintaining it takes quadruple the time or more.

    Writing actually maintainable Webforms applications is really only possible by forcing yourself into an MVVM/MVP pattern where you bind input and pre-process your model data into view models 'outside' of the Page (at the top level in the Init or Load part of the lifecycle) and just databind all the way down the Page and its Control instances. Congratulations: you've reinvented ASP.NET MVC's binder -> model -> controller -> view workflow in WebForms.



  • @Ragnax said:

    @this_code_sucks said:
    Making a complex form, especially with ajax updates, takes half the time in webforms.

    Making it takes half the time. Maintaining it takes quadruple the time or more.

    Writing actually maintainable Webforms applications is really only possible by forcing yourself into an MVVM/MVP pattern where you bind input and pre-process your model data into view models 'outside' of the Page (at the top level in the Init or Load part of the lifecycle) and just databind all the way down the Page and its Control instances. Congratulations: you've reinvented ASP.NET MVC's binder -> model -> controller -> view workflow in WebForms.

    Can't really argue. Again, I did say MVC was vastly superior. I by that, I mostly meant in an architechture kind of way. It's funny, when I am applying lessons I've learned in the past to the architechture of a webforms app, I always end up recreating a crappy MVC haha. But, like I said, webforms has it's place. A really simple app but with complex forms is great for webforms, especially if your UI-structure is a direct match to your data-structure. Webforms also allows you to enlist the help of some what less skilled developers, or good devs with no web experience. 



  • @Ragnax said:

    @this_code_sucks said:
    Making a complex form, especially with ajax updates, takes half the time in webforms.

    Making it takes half the time. Maintaining it takes quadruple the time or more.

    I'm curious, what about it makes maintaining it take so much longer? Do the bits shuffle around, requiring you to recode the form twice a month? Does the compiling process obfuscate the form, meaning that anyone who wants to read it needs to be able to read base 64?



  • @pkmnfrk said:

    @Ragnax said:
    @this_code_sucks said:
    Making a complex form, especially with ajax updates, takes half the time in webforms.

    Making it takes half the time. Maintaining it takes quadruple the time or more.

    I'm curious, what about it makes maintaining it take so much longer? Do the bits shuffle around, requiring you to recode the form twice a month? Does the compiling process obfuscate the form, meaning that anyone who wants to read it needs to be able to read base 64?

    I think that applies to almost any technology. "Just add one more field to this 100-field form" will always take more than 1/100th of the time to create the original form, unless you already have it open in your editor.



  • As much a fan of MVC that I am, I do believe that WebForms are arguably a better choice for "thick" apps which 10 years ago would be desktop apps i.e. the typical line-of-business CRM or order fulfillment systems with lots of fairly simple data entry screens.  Obviously I'm not talking about crap 1.1 era WebForms with all the logic stuffed into the code-behind, but modern MVVM and pretty URL N-tier applications, with a nice front end using controls such as Telerik's offerings, can still work.  MVC is great, but IMHO it really is more suited for customer-facing type of sites that involve occasional user interaction (e.g. an e-commerce site; people use it frequently but don't spend most of their day using it) rather than an application which business users are meant to spend 8 hours a day working inside.

    Unfortunately, very few companies seem to actually know that A) it is possible to use modern techniques with WebForms and B) Have competent staff that can control the urge to just rely on WebForms' hacky nature (i.e. "Oh I don't need another class for this, I'll just put it in the code behind").

     



  • @blakeyrat said:

    BTW, we should write a Joel Test for programming environments, since I didn't imagine in a million years how awful the Ruby ecosystem actually is. It should be something like this:

    1) Does your language have automatic memory management?
    2) Can it be used to write portable applications?
    3) Do quality tools exist to make a GUI using native widgets and behavior, with in a WYSIWYG editor?
    4) Does a quality IDE exist for the environment?
    5) Does a quality "auto-format" utility or feature exist for the environment?
    6) Does a quality debugger exist for the environment?
    7) Does a mechanism for automatically downloading/updating dependencies exist for the environment?

    .net hits all 7, now that it has Nuget. Ruby hits maybe 3 or 3.5.

    Excellent list.

    The biggest most gigantic WTF of all is that there are heavily used programming environments that don't hit at leat 6 out of those 7.

     



  • @ObiWayneKenobi said:

    As much a fan of MVC that I am, I do believe that WebForms are arguably a better choice for "thick" apps which 10 years ago would be desktop apps i.e. the typical line-of-business CRM or order fulfillment systems with lots of fairly simple data entry screens.

    Simple data entry screens is what MVC's Html.DisplayFor() and Html.EditorFor() excel at. Need a specific widget for a specific data field? Code up your own template and mark up the relevent property on your model with a [UIHint()] (or name the template directly after the simple name of the property's type and don't even bother).

    @ObiWayneKenobi said:

    Obviously I'm not talking about crap 1.1 era WebForms with all the logic stuffed into the code-behind, but modern MVVM and pretty URL N-tier applications, with a nice front end using controls such as Telerik's offerings, can still work.

    Telerik's offerings are nice because they have lots of fancy JavaScript handling around it client-side (all based on jQuery nowadays; the scripting in the older versions of their UI kit used to suuuu---ck). There's nothing preventing you from having MVC helpers to do pretty much the same. (And call those from aforementioned Editor and Display templates to make sure you have consistent rich data entry everywhere.) The exception is probably the richness of the designers / editors that you'd get with WebForms, but will have to miss out on with MVC. (Nothing a well designed helper API can't cope with though.)

    However, the real power for these modern applications comes from client-side JavaScript or DOM technology that is made simple and accessible through libraries like Angular, Ember, Backbone, Knockout, etc. The 'Model View Whatever', or MV*, stack in the browser itself. A modern rich application will mostly be JavaScript, with a few JSON service calls to a backend. That's where MVC WebAPI shines, ofcourse....



  • @El_Heffe said:

    @blakeyrat said:

    BTW, we should write a Joel Test for programming environments, since I didn't imagine in a million years how awful the Ruby ecosystem actually is. It should be something like this:

    Excellent list.

    It IS, actually. Blakey - you should consider whacking that up on your blog (or submitting it to some programming site) to invite feedback and further discussion about what features exist and how they're used in IDEs.

    @El_Heffe said:

    The biggest most gigantic WTF of all is that there are heavily used programming environments that don't hit at leat 6 out of those 7.
     

    Are these environments for older languages?

    There's still a school of thought that the skill is not in the tools but in those that wield them. I'm wondering if this has created a culture in which using better tools for improved development is perceived as a sign of weakness, ergo nobody wants to build better IDEs for those languages because there doesn't appear to be a demand for them.

    It is sad that developers with their rich skills in those languages don't think about turning their skills into improving the environment in which they - and others - work, but simply suck it up and get on with it. Cobbler's kids syndrome, I guess.

     


Log in to reply