RE: The Demise of C#

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Bryan MacFarlane (MacFarlane_at_discussions.microsoft.com)
Date: 02/26/05 

Date: Sat, 26 Feb 2005 09:05:02 -0800

The most important thing is to hire someone smart. The interview should
determine that persons raw smarts - syntax, languages, and tools can be
learned quickly. The key component is whether that person can think through
a problem and be able to express that thought process/algorithm in code.

If an employer/interviewer does not have the interview experience or does
not invest time into exploring ways to get to the bottom of that question and
they rely simply on a checkboxed list of langauges/years, then they will
likely miss out on that really smart developer or hire someone who just got
by with C/C++.

If someone says - I want to hire a C programmer even if it's a web job
because that means they are smart, that means they are trying filter to the
smartest people with the very least amount of work and probing on their side.
 They have equated that one factor to their decision.

Even though I don't agree with that simple filter, we have to ask ourselves
why. Here are some possibilities:
* Their is a higher bar to entry in C, C++. You have to understand more
about the system, memory, etc... and have to be very detail oriented and
skilled to write native code that performs well and doesn't crash (both of
which aren't always achieved by C++). You are more likely to get a computer
scientist here - once again, algortighms should define that and not the
language but it's a shortcut assumption.
* Out of the box: what happens when components or the framework doesn't
give you a neatly packaged API to solve your current problem? It is more
likely that a native programmer will quickly pinvoke his way into a solution
where a RAD developer will search the web for a prewritten component (pros
and cons to that - different discussion).
* the most obvious is if they have a large C/C++ code base :)

I would characterize it on another dimension - I would differentiate RAD vs.
shrink wrapped developer. You will find two different mind sets here. If
you get a developer who is used to doing 2 year projects to develop well
designed and extensible shrink wrapped projects - putting them on a 2 week
RAD IT project will be tough - and vice versa. You will typically find
larger companies wanting experience in shipping products having gone through
full ship cycles etc ... and consulting companies looking for more RAD
developers on short cycle projects. Historically, shipping products have
used C/C++/Win32 where RAD was VB - thus the stereotypes.

Bryan
bryanmac@microsoft.com

"Kevin Spencer" wrote:

> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> seeing many posts about what language to use with ASP.Net. The consensus was
> that employers paid more for C# programmers, and it seems that C# became the
> darling of the ASP.Net crowd.
>
> In the meantime, I have observed an interesting phenomenon. Originally,
> employers hired programmers who used C# because it was based on C, and the
> prevailing opinion was (and may still be) that C# developers were better
> because they must have known and/or practiced C or C++ at some time, which
> would make them better programmers overall. C and C++ are hard-core
> programming languages compared to VB.
>
> However, now that nearly everyone has jumped on the C# bandwagon, it seems
> to me that the distinction between the languages has nearly disappeared, at
> least in terms of evaluating programmers for hire. There seem to be almost
> as many clueless C# developers out there as VB.Net developers. Many C#
> developers today are basically VB.Net developers using a different syntax. I
> wonder if the employers have become aware of this trend?
>
> --
>
> Kevin Spencer
> Microsoft MVP
> ..Net Developer
> Neither a follower nor a lender be.
>
>
>

Relevant Pages

  • Re: Arithmetic overflow checking
    ... I'm very strongly of the opinion different languages should provide ... The alternative a lot of programmers follow seems to be to pick one ... managers, from business, from customers, or from developers themselves - ... ultimately stems from this pervasive mediocrity. ...
    (comp.lang.java.programmer)
  • Re: Microsoft: Get rid of VB.NET -- now !
    ... I agree that with the next version of VB.NET, there will be many more RAD ... what annoys the piss out of me is that Microsoft is not ... oblivious to the fact that when .NET first came out, advanced VB6 developers ... the same concept for two new languages. ...
    (microsoft.public.dotnet.general)
  • Re: Arithmetic overflow checking
    ... I'm very strongly of the opinion different languages should provide ... pick the language for a job based on its requirements and those features. ... The alternative a lot of programmers follow seems to be to pick one ... managers, from business, from customers, or from developers themselves - ...
    (comp.lang.java.programmer)
  • RE: The Demise of C#
    ... employer perception of C# Vs VB programmers. ... with other traditionally OOP languages like C/C++ and may therefore give rise ... Perhaps it is down to us as the developers to educate employers in this area ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: The Demise of C#
    ... > As languages evolve, there becomes less and less that differentiates them. ... >> that employers paid more for C# programmers, and it seems that C# became ... >> as many clueless C# developers out there as VB.Net developers. ...
    (microsoft.public.dotnet.framework.aspnet)