The Demise of C#

[Guest]

Anyone who thinks c# programmers are 'better' than VB programmers is an
idiot. Has it ever occured to people like you that the core competence of a
VB developer might be in the business rules they are trying to fulfill, and
that the vision of such a language might be to remove all the uneccessary
complexity from programming so as to allow such an individual to do just
that? By your reasoning, the habbits of an assembler programmer would be
welcome as a sign of intelligence towards OOPs related tasks! I am really
sorry guy but the time for knowing that the bios looks in the first boot
sector at address 0800 to start running the operating system is OVER. VB has
evolved into a powerfull programming language for fulfilling business rules.
C and C++ are low level languages that, becuase of their features, can be
used for system development and the like. Saying a C developer is 'smarter'
or 'better' at what they do is like saying a builder is smarter than an
engineer, or an engineer smarter than an architect!

 

[Kevin Spencer]

Anyone who thinks c# programmers are 'better' than VB programmers is an

idiot.

I wouldn't put it that way, but in essence I agree with you there.

Has it ever occured to people like you that the core competence of a
VB developer might be in the business rules they are trying to fulfill,
and
that the vision of such a language might be to remove all the uneccessary
complexity from programming so as to allow such an individual to do just
that?

Are you responding to my post? I will assume that "people like you" is a
reference to people like myself. Please point out where I made the statement
that C# programmers are better than VB programmers. A careful reading of my
message will prove the opposite. There is a big difference between the
reality of things, and the way things are perceived by many people. I was
talking about perceptions, not reality.

By your reasoning, the habbits of an assembler programmer would be
welcome as a sign of intelligence towards OOPs related tasks!

I'm afraid not. By my reasoning, there is a perception out there that has
nearly nothing to do with reality. It is your perception of my reasoning
that is in error.

I am really
sorry guy but the time for knowing that the bios looks in the first boot
sector at address 0800 to start running the operating system is OVER.

Maybe for you, but not for everyone. In any case, I didn't imply any such
thing.

VB has
evolved into a powerfull programming language for fulfilling business
rules.
C and C++ are low level languages that, becuase of their features, can be
used for system development and the like.

I don't develop systems. I develop applications. Some of those applications
require low-level programming. So, while you seem familiar with VB, you
don't seem to understand much of anything about the use of C and its
derivatives.

This is an odd post. It seems to be in reply to "move to c#" but all of its
arguments seem to be against my own. If this is the case, the writer didn't
read my post carefully, and misunderstood it almost entirely. Pretty sloppy
work for a programmer.

BTW, will someone remove the "Kick Me" sign from my back?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Guest]

IMHO, the incompetence you are seeing more of is people jumping to Web
development from desktop/thick client application development. Take any
"hard core" C++ developer awash in all his/her OOP glory: If this person has
never developed for the Web and has instead spent a career doing low-level
programming (device drivers, etc), and throw them into a Web Application,
they'll probably be asking a lot of dumb questions - of the same sort you
are currently attributing to the VB6 crowd. IMHO, it's the application type
(Web vs desktop), not the prior language.

An interesting point. I myself started in web and have moved over to
winapps. Maybe because Perl and PHP are C-esque languages I had an easier
transition.

 

[cmay]

Let me preface this with: If you do a quick scan up this thread, you
can see that I like vb.net, so this isn't coming from a vb hater.

However, regarding the "C# developers are better" thing, I'm sorry to
say that, even though I prefer vb.net, I would tend to agree with that
statement as a generality.

Now... having said that. I know lots of people who ONLY program in C#,
and my skills are FAR more than theirs in C#, VB, systems and on and
on. I'm not tooting my horn here, just stating the obvious "just cause
you use C# doesn't mean you are better than someone who users VB".

But, I have to say. If I were interviewing someone who was very good
at vb.net, but had no idea when it comes to C# I would think a lot less
of them than someone who programs in C# who knows nothing about VB.

Why is this?

It is obvious to me that new programmers (less experienced) would pick
VB over C#. So a larger portion of VB.Net developers are "newer" to
programming. What about the argument "A new programmer would look at
both languages and see that people value C# more and pick it as their
starting language" ? I would suggest that people who take that
approach are of a different mindset than the people who are thinking
"how can I get response.write to work with these crazy code behind page
things?". In other words, people who research the languages and make
an informed decision about picking one language over the other, not
matter which one they pick, are probably destined to be very good at
their job.

Also, as Kevin Spencer points out, C# isn't new (C -> C++ -> C#). C#
has many links with ECMA script which in is related to many other
languages. So in other words, imagine you took 2 people who had never
programmed a day in their life. One of them got 6 months to learn and
work with VB.Net, and the other got 6 months to learn and work with C#.
Then after 6 months you asked them to write a java app, or a client
side javascript program. The C# guy would have such an advantage b/c
the syntax is so similar.

So, basically what I am saying is, that if someone suggest that a
person is less able or competent because they work in vb.net I would
strongly disagree. However, if you want to say that the avg C#
programmer is a "better" programmer than the avg VB.Net programmer,
then I would have to agree.

I wouldn't just apply this to C# and VB though. I think the same could
be said of PHP, VFP, VBscript (vs Javascript) etc.

If someone thinks that there aren't PHP developers out there that are
fricking smart as hell, then they are wrong cause some of those guys
(dedicated PHP programmers) are brilliant! But, I would bet that if
show me a great PHP programmer (or any of the other languages listed
above) I will show you a person who can understand and read (and
probably write) most other languages, and has a very strong knowledge
over all the non-language related skills involved in programming.

 

[Guest]

There are plenty of clueless C++, VB, et al, developer.

There's a reason for this:

"You don't have to be good, just good enough."
-me, ca. late 80s

You can also consider things such as "bad coders can write bad code faster
than good coders can write good code" (or good coders can fix bad code).
People like to code and like to get paid for something they like to do. This
is without regard to the quality of the work they produce. Generally, the
only measurement of the quality is "does it work?".

Code reviews are a rarity. Documents are a thing of even farther in the
past. Besides, most technical people can't write their way out of a paper bag
so why should they write docs which are worthless? Granted, there are people
who write them professionally, but do smaller shops which only have one, two,
or three technical people on staff have to have a technical writer who only
writes docs? Ever look at the code someone has written for a group they
belong to? Service group? Church? Charity? There are plenty of good people
who write for such groups but there are plenty who have members who willingly
hop into the pool (and pee in the water) and deliver, at best, something
someone who took a first year VB course could improve upon.

Priority #1 is get to the keyboard and bang away at code. Forget specs.
Forget everything. Keyboard is #1.

In one of the blogs where everyone is whining about VB6, "Dougie" is
throwing a fit because the 200'000 lines of code he's written over the
previous twenty years are going to have to be rewritten because VB6 is going
away. His credentials are he not only knows VB but, "and for your
information, I can code in C, pascal, delphi as well as vb". I'm guessing
most of his code is a clusterf%ck and most of it hasn't been partitioned into
various DLLs, out-of-process EXEs, classes, etc. Things which not only would
be easier to manage but migrate as well. I think he'd fit real well with a
co-worker at a contracting firm I worked for who claimed, "There's nothing
you can do with OOP which you can't do with modules." And said his MBA gave
him the divine wisdom to know such things. The funny thing is we were billed
out at $125 for VB work and he wrote & debugged code by trial-and-error (I'm
not joking about any of this). The boss|owner loved him because he raked in
the dough but anyone who had to follow in his footsteps and either fix or add
to his code either kept a wastebasket handy (to barf) or rewrote the apps on
their own time, lest they have to work with it again. It was about as tasty
as one of the Star Trek animated series when an ESP-capable member of a
feline race begins to get nauseated because one of the Enterprise crew
focuses so heavily upon eating vegetation. That's what it felt like to work
with Brent's code.

I know others are upset but I think Dougie represents a vocal group who
couldn't buy a clue if you handed them the money; and he's pretty
representative of the industry as a whole.

You can find Dougie here to look for yourself:

http://tinyurl.com/6szrc

http://blogs.msdn.com/brad_mccabe/archive/2005/03/10/393704.aspx

***************************
Think Outside the Box!
***************************

(This is trite and a poor interpretation of deMarco's "Lateral Thinking" - I
suggest you get one of his books...)

"Kevin Spencer" wrote:

And before ASP.Net, it was ASP. Employers paid a lot more (and still do)
for ASP. The problem is a sizeable percentage of the ASP crowd were rats
jumping off of a sinking ship - all of the static HTMLers realizing their
pond was shrinking and they'd better jump...fast. Think about non-programmers
writing ASP + client-side JScript. Fortunately, a measure of competency
became a requirement and started to turn the tide.

At the risk of sounding rude, how is this the demise of c#?

 

[Kevin Spencer]

"You don't have to be good, just good enough."

-me, ca. late 80s

You can also consider things such as "bad coders can write bad code faster
than good coders can write good code" (or good coders can fix bad code).
People like to code and like to get paid for something they like to do.
This
is without regard to the quality of the work they produce. Generally, the
only measurement of the quality is "does it work?".

I hope you don't really feel this way. I have certainly seen enough of this
type of mindset (lacking forethought or any appreciation of future
consequences for present decisions) in my life. However, there are
individuals, businesses, and companies that do not subscribe to such a
Dilbert-esque business philosophy. Such individuals, businesses and
companies generally seem to survive and prosper over the long haul, as that
is what they plan for.

The truth of the matter is, it takes less money and effort over the long
haul to spend the money and do it right the first time. A LOT less money.
Bad code must be constantly rewritten and hacked to adapt to changing
conditions. Unless it is completely rewritten, the legacy of bad code costs
money for a very long time.

I wouldn't work for another company like that for any salary.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Guest]

It seems to me after reading some of these posts that this is just an
argument over personal preferences. I think its great that .NET offers both
VB.NET and C# and I feel that everyone has their own personal reasons for
picking their language. I have done programming in C++, Java, ASP, VbSCript,
JavaScript, Python, TCL, and others... however when I moved to use .NET i
chose C# simply because it was closer to C++ and Java. I found the syntax of
VB.NET to be too much of a blur of different languages, and I would start to
confuse syntax when working in different environments, as I still support old
VB6 and asp apps.

The idea of writing a line of code that looks like
Dim var as Object = new Object

My syntax may be off there, as you know I use C#.... but you get my point.
To me it just made me thing I would start to confuse my syntax for different
languages, so I chose C#.

However I just got a new job, where they only want me to use VB.NET because
the talent pool at the company are all peopole from vb6 with no c++/java
experience.

So I think for every company that requests a c# person, there is a company
that wants a vb.net person.... for whatever reason it may be. There are a
lot of companies with talent consisting only of vb.

Funny... I don't really see a need for C#

There are a few things that C# can do that VB.NET can't, and there are
things that VB.Net does that C# can't do without added in a bunch of VB.NET
references. But the reason for the very few things that VB.NET can't do
isn't any limitation of the language. What I mean by that is, MS could, if
they wanted to, add all the extra stuff C# does to vb.net if they cared to do
so. There isn't anything really holding them back from doing that. In fact!
C# is starting to get a lot of the nice features of VB.NET, such as "With"
blocks.

Now, I'll be clear that I use both VB.NET and C#, but I clearly prefer
VB.NET, save a few things that bug me.

My 2 major annoyances with VB.net, as compared to C# are:
1) XML Comments -- I have the XML comments add-in, but it doesn't tie into
the intellisense. It would be nice if my comments showed up in my own
intellisense function calls in vb.net just like they do in C#.
2) The "Dumbifying" of terms. "MustInherit", "Shared" etc. A standard
question for all interviewers who program in vb.net should be "what is an
abstract class?" If you have to explain that "abstract" means "MustInherit"
then you know what kind of programmer you are dealing with.

Now, I think you would be hard pressed to prove that you can develop as fast
in C# as you can in VB.Net. The intellisense and error catching is so much
better in VB.NET (Im referring to the VS ide).

Either way, I agree the 2 will be moving closer to one another, but you have
to wonder: with the technical reasons for using C# all but gone, why would
new programmers choose C# (new, meaning they aren't coming from years of C++
of java development)?

Better question: Is there any (quality) vb.net programmer out there who
can't read/write C#? Maybe not as fast, but everything is so similar...

I believe they did. (can of worms here)

I really don't see a reason for VB.NET given the fact that it certainly
isn't VB with .NET classes. Eventually, VB.NET will have to morph into
something else. Programmers who need to learn VB.NET coming from VB classic
are better off learning C#.

--
Regards
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
--------------------------------------------------

The main reasons they went with C# is because they were experienced with
C++ (becuase C++ was more powerful than VB6) so it was more of a natural
progression for them, and the other reason was because C# was the "new"
language and they wanted to eat their own dog food to ensure C# would
become capable of all that they'd envisioned and all they needed.

It wasn't because they saw C# as superior to VB.NET in any way.




When I saw that when deciding whether to continue on with VB.NET
(I was an old VB 6 and a C# coder), I went with C#.

I figured if the Microsoft guys saw fit to use C#, maybe I should too.
There must be a reason they picked it.

--
2005 Microsoft MVP C#
Robbe Morris
http://www.robbemorris.com
http://www.mastervb.net/home/ng/forumvbcode/post10017013.aspx
http://www.eggheadcafe.com/articles/adonet_source_code_generator.asp



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.

 

[Guest]

I have to agree with Steve here, though he probably wouldn't go as far as
me... I have hired many web developers, and have experienced much more
difficulty with 20 year C/C++ programmers who have been doing Internet
development for a few years, than relatively new programmers that just have a
few years experience with ASP/VBscript/VB/COM (and now with .net).

Why? I think it has to do with instinct. Some of the C/C++ developers we
have brought on board had a heck of a time becoming instinctively aware of
"where" their code was executing. ASP.NET has done a great deal to rectify
this by handling client events in the code-behind, but when you have a
programmer that has always developed applications with a single event layer,
and they suddenly have to debug a process like: request goes to the server,
server to biz layer, biz to database, biz to server, server generates
client-side html and script, server generates client-side script written to
generate more client-side script when it executes, buffer is flushed, html
rendered, dom events fire, client script executes, user triggers events,
script submits a hidden form to the server, (insert first 11 items here
again), etc.. I have had to spend an inordinate amount of time breaking down
the layers and explaining "where" different pieces of the code is generated
and where it ends up executing.

On the other hand, programmers who "grew up" on the web with ASP/VBScript
(or even Perl/PHP/etc) as their native language/platform, seem to have a much
better instinct for weaving through the web - for instance, if you have to
debug someone else's code that does something crazy like:

<% = "Hello world" %>
<script>
window.attachEvent('onload',function() {
msgbox('<% = jsEscape(sMessage) %>', msg_onclose);
}

function msgbox(message, closeEvent) {
document.msgWin = window.open('blank.htm','width=400,height=300);
setTimeout(1000, 'msgboxReady("' + message + '", ' + closeEvent + ')');
}
function msgReady(message, closeEvent) {
if (document.msgWin) {
if (document.msgWin.readyState) {
document.msgWin.document.opener = document;
document.msgWin.document.open();
document.msgWin.document.title = '<% = sTitle %>';
document.msgWin.document.write('<p class=message>' +
unescape(message) + '</p><button onclick="window.close()">Close</button>');
document.msgWin.document.attachEvent('onclose', eval('opener.' +
closeEvent));
} else {
setTimeout(1000, 'msgboxReady("' + unescape(message) + '", ' +
closeEvent + ')');
}
} else {
alert('Error! Please contact <% = Application.Settings("AdminEmail") %>
if this problem continues');
}
}
</script>

Unfortunately, there are times you have to fix someone else's code that
looks like this (don't try and run that, I just typed it as an example of
code I have had to debug.) A web programmer has to have a good instinct to
know where each piece of that code is executing in order to decipher and
debug. Of course there are many exceptions (like, umm.. the C/C++ programmers
that built the technology probably have it down pretty good) but within MY
little corner of the web, the unfortunate reality is that we are simple
hiring more 5 year web-grown, ASP programmers than 25 year C/C++ veterans -
even if they say they have 5 years of web programming. This isn't a rule of
course - we give them all an equal chance at an interview - it just seems
like we don't hire them as much in the end.

 

[Kevin Spencer]

I dunno, maybe I was just lucky. I studied C first, and then the Internet
came along, and I wanted to ride the curl. So I abandoned C and C++ for a
number of years working with ASP mostly. And then .Net came out and I could
use C#. So I suppose I made the transition easier than some others.

Still, the fact that one hasn't been working on a particular platform, or
written distributed applications before, is likely to indicate a certain
learning curve when adapting to ASP.Net. I think that principle could be
applied to almost any programmer, regardless of the language(s) they are
proficient in.

On the other hand, my point regarding C was that C is low-level enough so
that you really have to understand what your code is doing in order to use
it at all. You don't have all those nice little black boxes that VB comes
with, little black boxes that seem to do things magically, without you
having to worry your pretty little head about why. And I believe that
contributes to the ability oif the coder to write better structured code.

Anyone can write code that makes things happen. It is writing code that is
optimized, elegant, extensible and maintainable that is the Art of
Programming. Anything else is just hackery.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Guest]

About productivity, I did heard from some people writing in VB.NET that
writing in VB.NET is faster, on the other hand, I've heard from people
writing in C# (and I think so myself), that writing C# code is more
error-prone and "developable", of course, if written right (well, only VB.NET
code which is written right, is written fast).

Another thing, I've heard about some plug-in for VS.IDE which negates the
difference in speed of development for C# coders for like 95% and allows for
almost all of that nifty features of VB.NET IDE. Though, I've not used it
myself, so I can't tell anything.

About that type written after variable, or before, I don't think that
matters, whether you write it after or before, if you do it singularily, then
syntaÑtic analyzer is okay with it.

Anyways, the topic is turning into "what language is better" again

 

[Kevin Spencer]

Well, as Jimi Hendrix once said, you can't believe everything you see and
hear, can you?

--
;-),

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Guest]

While this maybe true Kevin, I wonder how many of those clueless employers
are converting applications to C# because they think that it runs faster then
VB.Net.

The real problem exists where employers think that just because someone has
a degree that they will be programming genius. I have a friend that has a
masters in computing and he can barely open a word document, but standing
beside me, with my paltry 10 years development experience he would get the
job.

If Microsoft want to educate anyone, it should be the abundant masses of
non-technical so called managers and directors of IT departments, that don’t
understand the first thing when it comes to development but merely throw the
first ‘catch phrase’ that pops into their head that they have read from a
journal at the HR personnel.

They alone are the sole reason why some snot nosed punk fresh out of college
who is willing to except the lowest of wages are getting jobs and they alone
perpetuate the growing band of clueless developers, whilst winging how they
don’t see value for money and how their poorly specified projects are
delivered late and full of bugs.

 

[Kevin Spencer]

Hi Brennon,

I agree with ALMOST everything you said, except for one thing:

The real problem exists where employers think that just because someone
has
a degree that they will be programming genius.

While I certainly agree that this is a big problem, I can't agree that it is
THE "real" problem. It certainly is one of them!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Guest]

Leaving aside the fact that not everything is a web application, there are at
least 2 questionable assumptions in this:
1) That all C# developers are recycled C/C++ developers. Some in fact (such
as myself, although I had worked with C and with another c-word language that
I won't mention...and even BCPL) are ex-VB/VB Script/ASP developers (and no,
I don't write VB6 code in C# syntax, although I understand how someone might,
and have cleaned up after someone who has). Some are Java developers that
we've brought over to the Dark Side.
2) That ASP/VB Script is necessarily a good background for ASP.NET.
While *any* web experience is useful (otherwise I spend a lot of time
explaining to even very bright people what happens on the server and what
happens in the browser), do we actually want ASP.NET to be written the way a
lot of people wrote ASP? If I'm shortlisting candidates these days I'll quite
happily give equal weight to ASP *and* JSP experience - I might even favour
the latter slightly.

 

[Guest]

I've been coding for more than 20 years, and doing architecture for
enterprise applications for at least a decade now, as well as keeping my hand
in at coding. I'm fluent in 17 "languages" (from machine code, C, C++ through
to Java, C#, VB.NET and Delphi’s .NET implementation, and, yes, even a
smattering of COBOL). I now regularly consult to hire coders for large and
small companies, including government organizations right down to private
entrepreneurs. My own coding (usually just the conceptual structures and hard
bits and pieces these days) is split between VB.NET, C# and Java these days
almost equally. None of this makes me inherently smarter, better, or faster
than a coder with a few years experience right out of school. About all I can
claim is that I have a lot of experience, both good and bad, and maybe a
scrap of wisdom as a result of surviving the long haul. I am not an MVP
(don’t have the inclination or the time); have no real preference between MS
languages and Sun languages, etc.; and those who have worked with me describe
me as too relaxed to be a programmer or IT manager.
That purpose of that descriptive preface is simply to place the following
opinion in perspective:
Anyone who hires primarily on the basis of language skills is a fool,
because none of these languages are weak in the hands of a professional.
About the only legitimate reason for using language as a basis of comparison
during a hiring process is if there is an existing code base in a given
language. Then, it is syntax familiarity that comes into play. HR managers
who do hiring on the basis of language are a bane to the industry, and part
of the reason the vast majority of software projects fail so miserably.
As I read the multitude of posts on this topic, I was reminded of a recent
conversation I had with a client who was asking me to help re-fit a
self-destructive team of coders (they were supposed to be rebuilding a fairly
significant enterprise system in .NET that was previously done in a variety
of languages and cobbled together beneath a VB6 GUI). The client felt the
problem was that the three lead programmers (C++ gurus) could not deal with
the “weaker†members of the team, who “could not understand the OOP issues.â€
A review of the situation and the legacy code-base revealed that what was
actually happening was that the C++ coders (a combined 22 years of experience
under their belts) were drowning in the .NET framework’s scale, and having
trouble translating the legacy constructs to it. Two of the recent hires had
ignited a war in the team by claiming the old dogs couldn’t learn the new
tricks, and instead of proving them wrong by action, the C++ lads decided to
play the OOP purist card. Two days of intensive communication solved the
problem, made the younger coders realize that they were throwing away an
opportunity, and the seasoned coders realize they were betraying their
responsibility to the younger coders, who were for all intents their
apprentices. Not once in those two days did I even speak of a language,
because language was irrelevant to the solution.
Again, this is simply an opinion, but I would say that when “language†is
believed relevant to the solution, the solution is at risk. Each set of
technologies has its place, and there will always be circumstances that make
one the choice for a given project. At the end of the day, as long as the
language choice is fitting, it is correct.
And on the point of C++ versus C# versus VB.NET: C++ is probably superior in
the sense it is closer to the language of the machine, but it is challenging
to write well, especially in the modern era of two-minute turnaround. In the
modern time frames, neither VB.NET nor C# is the better language, because in
professional hands the results are the same, which is a good solution. What
sets the professional apart from the non-professional in the world of .NET
programming is knowledge of the framework. It is far better to hire on the
basis of that knowledge than of syntax and grammar. When coders are hired for
their awareness, flexibility and enthusiasm, results are better.

 

[Kevin Spencer]

Excellent points all, Frank! I couldn't agree more on all aspects of your
message. When I posted the original "spark" to this thread, it was due to an
observation I had made regarding hiring practices and trends. I had made the
same observations privately that you have, and hoped that by sparking some
discussion of it, we might all benefit from the discussion in one way or
another.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Guest]

This morning brought a distant memory to me. I had a mentor who once observed
that talent was the best reason to hire a person, but the hardest quality to
judge. This reminded me indirectly that everything I know that has been of
value was passed onto me by mentors, and made me wonder if maybe as a group
we have a problem in that we no longer take on the responsibility of
apprentices. Perhaps if we did, we could shape the process for hiring to
reflect the idea of quality and encompass the judgement that extends from
experience.

 

[Kevin Spencer]

Well, Frank, I consider these newsgroups as a sort of opportunity to do just
that. However, a good team leader should be a personal mentor, absolutely,
as part of his/her job.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Guest]

Such a good thread well done Mr Spencer!

Good tools only help the creative that's all.
The stone maison can make a most wonderfull statue with a hammer and chisel
no need for a jack hammer.
Imagination and creativity are the key regardless of the language he speaks
or the tools we use.

 

[Guest]

I came from a VB development background and moved to C# about five years
ago.

Hm, is C# that old? I thought the first betas begun on 2001, but I might be
mistaken.

I do not necessarily think that companies look for C# people because
of the tie-in with C++, but rather that C# develops have more of an OOP
sense about them. C++ and C# are object oriented languages and therefore
those people tend to think in object design. VB used to be thought of a toy
and only used for RAD development. There was little emphasis placed on
proper coding styles. It was more of a "let's get it done" mentality rather
then "let's design something for expandability and maintainability". Keep
in mind that until VB.NET was released, the concept of classes was shoddy at
best and certainly did not have inheritance or polymorphism, which means
that VB was NEVER an object oriented languages.

Well, I only have ONE experience of having to work with VB6 code at my
company (the project of a previous developer that left the company). It was
pretty horrible.
There was NO sign of Option Explicit, not EVEN one single Dim variable AS
<type> (although there were some Dim variable).
As if this wasn't enough, this person created a public connection, opened it
at the beggining of program's execution, but since he had to close it in a
some parts of the code, he always included the following check:
If cn.State <> 0 Then cn.Close

Well, I tried to make this thing work (as was mentioned before, this is a
very nice sample of what hackery means, since this project needed constant
changes on it's core). After a week, I abandoned it, archived the code to the
backup HDD, and begun developing it from scratch, using C# and MSDE (he used
MSAccess as the DB, and this database was supposed to be accessed by 5-6
users at the same times - evil laughs).

The result is, that using "proper" OOP techniques and modularisation (this
is the term I use for code reusability, componentisation if you prefer), the
code works perfectly, all changes were almost painless, and is more than
easier to understand the code...

I tend to see it as a difference between VB6 and .net, rather than VB6 and
C#. The reason, is that even by using VB.Net, I would have locked myself out
from all the "unproper" features, such as Option Explicit Off, Option Strict
Off etc etc...

My 2 cents...