Best way to get a Junior Programmer up to speed

[BK]

Our .Net team has just inherited a junior programmer that we need to
get up to speed as quickly as possible. Unfortunately, his skill set
is largely Access with some VB6 and ASP classic experience. We employ
some parts of XP such as pair programming, and this should help. Other
than books, does anyone have any suggestions? His skill set is pretty
antiquated and we need to get him up to speed as quickly as possible so
any suggestions are appreciated.

Background:
Mixture of Vb.Net and C#.Net code
Mixture of Oracle, DB2, and SQL server backends (we have our own
DataAccess class similar to the MS Enterprise Library Data Access)
Mostly Windows Forms for front ends
Mostly 4 tier design due to the complexity of our needs.

Thanks,

[Stephany Young]

Well ... This one has all the hallmarks of 'how long is a piece of string?'.

Your use of the word 'inherited' indicates to me that you did not recruit
him yourself. How he came to be working for your company is a major factor
in how you approach the exercise. Was he, for instance, in some other
position where he used 'MS Access' etc. and now is being moved into a more
'mainstream' area of the company, or perhaps recruited by someone else in
the company as a personal favour or similar reason. Maybe he, himself
'asked' to moved from weher he was to 'mainstream' area of the company. In
addition, is this person 'new' to you personally or have you known him for
some time. This sort of information is important to you so that you can
gauge his ability to learn, his level of self-motivation and perhaps his
abilities in analysing and solving 'problems', which, after all, programming
is all about.

Realisticly, you have to gaugue his skill levels in various areas and the
best way is to start at the beginning. That is to start him off on 'ye olde
standard' Hello World! console application. This should have the intention
of introducing him to the VS IDE, the VB.NET compiler and the VS Debugger.
It important that he understand what is actually happening when the app hits
the 'Sub Main()' because, in Access, the need to worry about that level of
functionality was hidden from the user.

As you are satisfied that he has mastered each step, increase the complexity
of the exercises at the rate you gauge to be appropriate. Some people learn
faster than others and some are able to grasp very complex concepts very
quickly indeed.

Reinforce the need to have Option Explicit and Option Strict turned on in
ALL projects, again making sure that he understands why.

Reinforce the need, and of course, the reasons, to follow the company
standards for naming conventions and coding styles at all times. Make sure
that he is given a copy of the company standards manual as early as
possible.

In parallel with this, introduce him to existing projects. For example, take
a small app and get him to dissect the code to understand what the app is
doing. It is not good enough for him to tell you he understands it, he must
be able to demonstrate that he understands it. I get people to write a
report (in prose) of their analysis of the application, which also provides
me with a way of gauging their written communication skill level. Make sure
you review the report with the person, reinforcing where they have 'got it
right' and correcting where they haven't.

Once you can gauge that their proficiency levels are at a certain stage you
can send them out 'to play' on their own, but still reviewing what they are
doing. As their skill levels increase you will be able to reduce the amount
of reviewing that you need to do. When he makes a 'mistake' make sure you
don't browbeat him with it, rather, uUse it as an opportunity for analysis
and learning.

At all steps along the way, you, of course, need to make sure that you are
pointing them toward the appropriate references that will provide more
technical explanations on various concepts.

If the person concerned is a 'quick study' and is self-motivated this
process may be as short as a few weeks. For others it may extend into
months.

Unfortunately there is no 'magic bullet' formula that dictates how long such
a process will take just as there is no 'magic bullet' formula that tells
you how you must go about it.

I have a slogan (which is never erased) written in big letters across the
top of my whiteboard. It reads "THERE IS NO SUBSTITUTE FOR TRAINING!'.

Good luck.
"BK" <bk******@hotmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...

Our .Net team has just inherited a junior programmer that we need to
get up to speed as quickly as possible. Unfortunately, his skill set
is largely Access with some VB6 and ASP classic experience. We employ
some parts of XP such as pair programming, and this should help. Other
than books, does anyone have any suggestions? His skill set is pretty
antiquated and we need to get him up to speed as quickly as possible so
any suggestions are appreciated.

Background:
Mixture of Vb.Net and C#.Net code
Mixture of Oracle, DB2, and SQL server backends (we have our own
DataAccess class similar to the MS Enterprise Library Data Access)
Mostly Windows Forms for front ends
Mostly 4 tier design due to the complexity of our needs.

Thanks,

[Tom Leylan]

In the interest of communication (not argument) I'd like to say it was a
treat to read Stephany's well-reasoned reply. And to Dennis, I can
appreciate the fact you run your company that way (how many employees do you
have BTW) but good/smart companies don't. If he was an "employee" it means
he has knowledge of the business and one would prefer not to throw that
away. Besides what is "easy" and what is "complicated" and why must
everybody perform complicated tasks? Are there no routine tasks to perform?

To the original poster... I'd recommend you consider Stephany's response.
What I would add is a question "get up to speed with what?" Are you hoping
the new guy can design new input forms, write new reports, review all the
SQL stored procedures and travel to the Denver office to do training?
Perhaps there is some task that match his current skills. If his Access DB
experience makes it difficult for him to grasp the 4-tier design of your
system right now it would be best not to give him the responsibility to fix
something in that area. Generally speaking people have particular skills
and if you determine what his are he can be of benefit to you immediately.
He might (for instance) be better at designing reports than the people you
currently have doing it. Maybe he is good at finding tricky bugs that have
eluded the rest of the team or that they simply don't have time to look
into.

He is going to need a "tour" of your app and .Net given by somebody who
understands both. If that person also knows something about Access he/she
could even contrast the two languages. All things considered it may not be
..Net command set that gives him the most problem, I know people quite versed
in a language who couldn't make heads or tails of an application written in
that language. An orientation to what was done and why helps alot.

Tom
"Dennis" <De****@discussions.microsoft.comwrote in message
news:96**********************************@microsof t.com...

Simple...assign him something simple to do in VB.Net and see what he
does...if he can't figure out how to learn what he needs to know to get it
done then fire him...if he does then give him something more complicated.
--
Dennis in Houston
"Stephany Young" wrote:

>Well ... This one has all the hallmarks of 'how long is a piece of
string?'.

Your use of the word 'inherited' indicates to me that you did not recruit
him yourself. How he came to be working for your company is a major
factor
in how you approach the exercise. Was he, for instance, in some other
position where he used 'MS Access' etc. and now is being moved into a
more
'mainstream' area of the company, or perhaps recruited by someone else in
the company as a personal favour or similar reason. Maybe he, himself
'asked' to moved from weher he was to 'mainstream' area of the company.
In
addition, is this person 'new' to you personally or have you known him
for
some time. This sort of information is important to you so that you can
gauge his ability to learn, his level of self-motivation and perhaps his
abilities in analysing and solving 'problems', which, after all,
programming
is all about.

Realisticly, you have to gaugue his skill levels in various areas and the
best way is to start at the beginning. That is to start him off on 'ye
olde
standard' Hello World! console application. This should have the
intention
of introducing him to the VS IDE, the VB.NET compiler and the VS
Debugger.
It important that he understand what is actually happening when the app
hits
the 'Sub Main()' because, in Access, the need to worry about that level
of
functionality was hidden from the user.

As you are satisfied that he has mastered each step, increase the
complexity
of the exercises at the rate you gauge to be appropriate. Some people
learn
faster than others and some are able to grasp very complex concepts very
quickly indeed.

Reinforce the need to have Option Explicit and Option Strict turned on in
ALL projects, again making sure that he understands why.

Reinforce the need, and of course, the reasons, to follow the company
standards for naming conventions and coding styles at all times. Make
sure
that he is given a copy of the company standards manual as early as
possible.

In parallel with this, introduce him to existing projects. For example,
take
a small app and get him to dissect the code to understand what the app is
doing. It is not good enough for him to tell you he understands it, he
must
be able to demonstrate that he understands it. I get people to write a
report (in prose) of their analysis of the application, which also
provides
me with a way of gauging their written communication skill level. Make
sure
you review the report with the person, reinforcing where they have 'got
it
right' and correcting where they haven't.

Once you can gauge that their proficiency levels are at a certain stage
you
can send them out 'to play' on their own, but still reviewing what they
are
doing. As their skill levels increase you will be able to reduce the
amount
of reviewing that you need to do. When he makes a 'mistake' make sure you
don't browbeat him with it, rather, uUse it as an opportunity for
analysis
and learning.

At all steps along the way, you, of course, need to make sure that you
are
pointing them toward the appropriate references that will provide more
technical explanations on various concepts.

If the person concerned is a 'quick study' and is self-motivated this
process may be as short as a few weeks. For others it may extend into
months.

Unfortunately there is no 'magic bullet' formula that dictates how long
such
a process will take just as there is no 'magic bullet' formula that tells
you how you must go about it.

I have a slogan (which is never erased) written in big letters across the
top of my whiteboard. It reads "THERE IS NO SUBSTITUTE FOR TRAINING!'.

Good luck.
"BK" <bk******@hotmail.comwrote in message
news:11**********************@n67g2000cwd.googleg roups.com...

Our .Net team has just inherited a junior programmer that we need to
get up to speed as quickly as possible. Unfortunately, his skill set
is largely Access with some VB6 and ASP classic experience. We employ
some parts of XP such as pair programming, and this should help. Other
than books, does anyone have any suggestions? His skill set is pretty
antiquated and we need to get him up to speed as quickly as possible so
any suggestions are appreciated.

Background:
Mixture of Vb.Net and C#.Net code
Mixture of Oracle, DB2, and SQL server backends (we have our own
DataAccess class similar to the MS Enterprise Library Data Access)
Mostly Windows Forms for front ends
Mostly 4 tier design due to the complexity of our needs.

Thanks,

[Spam Catcher]

"Stephany Young" <noone@localhostwrote in
news:OM**************@TK2MSFTNGP04.phx.gbl:

I have a slogan (which is never erased) written in big letters across
the top of my whiteboard. It reads "THERE IS NO SUBSTITUTE FOR
TRAINING!'.

And experience for that matter!

[Cor Ligthert [MVP]]

BK,

I completely disagree with the replies from Stephany and Tom, why are
things as 4 tier so important, is that the first goal of an organisation.
For me that sounds beginners wisdom, use the skills of the Access, ASP
programmer to start with. Those are most probably fine form and output
design coupled with skills how to present a program to an end user. For me
those parts are thousand times more important than if something is so called
4 tier (which I doubt it is because this is mostly nothing more than
multilayer).

Therefore the tone setting of some messages sounds for me derogating too
Access/ASP developers. There is not any need for that. Often they are much
better than dotNet developers in creating what is needed, the latter
sometimes don't come any further than the design instead of bringing the
programs (at the right time) to the end-user.

Just my thought reading the message and some replies.

And let him try this

http://www.vb-tips.com/dbpages.aspx?...2-b1ed16424252

Cor

"BK" <bk******@hotmail.comschreef in bericht
news:11**********************@n67g2000cwd.googlegr oups.com...

Our .Net team has just inherited a junior programmer that we need to
get up to speed as quickly as possible. Unfortunately, his skill set
is largely Access with some VB6 and ASP classic experience. We employ
some parts of XP such as pair programming, and this should help. Other
than books, does anyone have any suggestions? His skill set is pretty
antiquated and we need to get him up to speed as quickly as possible so
any suggestions are appreciated.

Background:
Mixture of Vb.Net and C#.Net code
Mixture of Oracle, DB2, and SQL server backends (we have our own
DataAccess class similar to the MS Enterprise Library Data Access)
Mostly Windows Forms for front ends
Mostly 4 tier design due to the complexity of our needs.

Thanks,

[Tom Leylan]

Interesting Cor.

If they have a multi-tier business app written in VB.Net and C# and a junior
programmer who knows Access then that's what they have. Nobody was putting
the programmer down for using Access but extensive knowledge of Access isn't
going to translate into "I'll implement an Interface in my new business
class." You can see the level of some of the questions posted on this
newsgroup and this is from people who actually use VB.Net. If knowing
Access is the route to good .Net code we could start recommending a side
trip.

They aren't developing in Access if they were I'd suggest the Access guy
orient the .Net folks instead.

Stephany suggested he be taught .Net, I suggested they use the skills he has
gained in Access in developing .Net... I don't think you completely disagree
:-)

Take care.
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

BK,

I completely disagree with the replies from Stephany and Tom, why are
things as 4 tier so important, is that the first goal of an organisation.
For me that sounds beginners wisdom, use the skills of the Access, ASP
programmer to start with. Those are most probably fine form and output
design coupled with skills how to present a program to an end user. For me
those parts are thousand times more important than if something is so
called 4 tier (which I doubt it is because this is mostly nothing more
than multilayer).

Therefore the tone setting of some messages sounds for me derogating too
Access/ASP developers. There is not any need for that. Often they are much
better than dotNet developers in creating what is needed, the latter
sometimes don't come any further than the design instead of bringing the
programs (at the right time) to the end-user.

Just my thought reading the message and some replies.

And let him try this

http://www.vb-tips.com/dbpages.aspx?...2-b1ed16424252

Cor

"BK" <bk******@hotmail.comschreef in bericht
news:11**********************@n67g2000cwd.googlegr oups.com...

>Our .Net team has just inherited a junior programmer that we need to
get up to speed as quickly as possible. Unfortunately, his skill set
is largely Access with some VB6 and ASP classic experience. We employ
some parts of XP such as pair programming, and this should help. Other
than books, does anyone have any suggestions? His skill set is pretty
antiquated and we need to get him up to speed as quickly as possible so
any suggestions are appreciated.

Background:
Mixture of Vb.Net and C#.Net code
Mixture of Oracle, DB2, and SQL server backends (we have our own
DataAccess class similar to the MS Enterprise Library Data Access)
Mostly Windows Forms for front ends
Mostly 4 tier design due to the complexity of our needs.

Thanks,

[Michel Posseth [MCP]]

They also told he was a VB6 programmer

So i would recomend to throw him the Programming Microsoft Visual basic .Net
series of Francesco balena ( Core reference guide of VB )

Wich for a fact has special attention notes for Pre .Net VB programmers

Wit this book as a reference he should be able to pick up VB.Net pretty
quick , also i believe there are big misunderstandings about needed skills in
the pre .Net period

In VB.Net i see nowadays people calling themself proggrammers , while they
can only use drag and drop , and call methods in the framework , if there
is not an out of the box solution they are lostm cause they can`t write the
solution themselves

If you wrote complex programs in VB6 you are probably a much higher skilled
programmer as the current .Net pilots

regards

Michel Posseth [MCP]

"Tom Leylan" wrote:

Interesting Cor.

If they have a multi-tier business app written in VB.Net and C# and a junior
programmer who knows Access then that's what they have. Nobody was putting
the programmer down for using Access but extensive knowledge of Access isn't
going to translate into "I'll implement an Interface in my new business
class." You can see the level of some of the questions posted on this
newsgroup and this is from people who actually use VB.Net. If knowing
Access is the route to good .Net code we could start recommending a side
trip.

They aren't developing in Access if they were I'd suggest the Access guy
orient the .Net folks instead.

Stephany suggested he be taught .Net, I suggested they use the skills he has
gained in Access in developing .Net... I don't think you completely disagree
:-)

Take care.
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

BK,

I completely disagree with the replies from Stephany and Tom, why are
things as 4 tier so important, is that the first goal of an organisation.
For me that sounds beginners wisdom, use the skills of the Access, ASP
programmer to start with. Those are most probably fine form and output
design coupled with skills how to present a program to an end user. For me
those parts are thousand times more important than if something is so
called 4 tier (which I doubt it is because this is mostly nothing more
than multilayer).

Therefore the tone setting of some messages sounds for me derogating too
Access/ASP developers. There is not any need for that. Often they are much
better than dotNet developers in creating what is needed, the latter
sometimes don't come any further than the design instead of bringing the
programs (at the right time) to the end-user.

Just my thought reading the message and some replies.

And let him try this

http://www.vb-tips.com/dbpages.aspx?...2-b1ed16424252

Cor

"BK" <bk******@hotmail.comschreef in bericht
news:11**********************@n67g2000cwd.googlegr oups.com...

Our .Net team has just inherited a junior programmer that we need to
get up to speed as quickly as possible. Unfortunately, his skill set
is largely Access with some VB6 and ASP classic experience. We employ
some parts of XP such as pair programming, and this should help. Other
than books, does anyone have any suggestions? His skill set is pretty
antiquated and we need to get him up to speed as quickly as possible so
any suggestions are appreciated.

Background:
Mixture of Vb.Net and C#.Net code
Mixture of Oracle, DB2, and SQL server backends (we have our own
DataAccess class similar to the MS Enterprise Library Data Access)
Mostly Windows Forms for front ends
Mostly 4 tier design due to the complexity of our needs.

Thanks,

[BK]

First off, thanks for all the input... I won't address all the points
and questions, but here is some feedback from me (the original poster).

The programmer I "inherited" is the last of the VB6 programmers here.
The reason he was a hold out is because he is more old school and
reluctant to change. I actually did want him on the team, it was a way
to further show management how good the move was to .Net (if we can
make him more productive, we can make anyone more productive!) The
rest of us embraced the .Net environment and jumped in feet first over
a year ago. The rest of the team is very productive now, much more so
than when they coded in VB6 (I actually programmed in VFP prior to this
and came into the .Net team as a team lead). We had a few hurdles to
cross initially, but they were mostly related to team development
instead of individual development. We now attack all projects as a
team, divide and conquer. Using OOP principles, eXtreme Programming
techniques, and the .Net framework, we are all doing our job different,
but much more efficiently with fewer bugs and faster turn around. The
customers are happy, management is happy, my job is fun.

The reason for the post is that this programmer has been a challenge,
he wants to revert back to "old ways". FWIW, he is the oldest member
of the team. You can tell he wants to change and he doesn't resist
change, but his programming style is very procedural and he has a hard
time thinking of the Enterprise (Oracle, DB2, SQL Server).

Things are getting slowly better. We do a lot of paired programming
and that has been helpful. We also do a lot of code review, so he
see's other peoples work. Another thing I've found useful is to give
him shorter deadlines... if he has too long to work on something he
tends to bog himself down in minor details that don't enhance the
system or the user experience.

Once again, I do appreciate the replys and I will share my progress in
the hopes that others may benefit.

[Cor Ligthert [MVP]]

I don't think you completely disagree

:-)

You know me,

:-)

Cor

[Dennis]

By fire him, I meant send him back to what he was doing before. Giving him a
problem to solve on his own tests both his learning skills and iniative. By
the way, I manage a worldwide organization with operations in many countries
with several sub-managers and Engineers working with me and we just can't
have people on our staff who can't handle their own learning path. Neither
can any successful organization.
--
Dennis in Houston
"Tom Leylan" wrote:

In the interest of communication (not argument) I'd like to say it was a
treat to read Stephany's well-reasoned reply. And to Dennis, I can
appreciate the fact you run your company that way (how many employees do you
have BTW) but good/smart companies don't. If he was an "employee" it means
he has knowledge of the business and one would prefer not to throw that
away. Besides what is "easy" and what is "complicated" and why must
everybody perform complicated tasks? Are there no routine tasks to perform?

To the original poster... I'd recommend you consider Stephany's response.
What I would add is a question "get up to speed with what?" Are you hoping
the new guy can design new input forms, write new reports, review all the
SQL stored procedures and travel to the Denver office to do training?
Perhaps there is some task that match his current skills. If his Access DB
experience makes it difficult for him to grasp the 4-tier design of your
system right now it would be best not to give him the responsibility to fix
something in that area. Generally speaking people have particular skills
and if you determine what his are he can be of benefit to you immediately.
He might (for instance) be better at designing reports than the people you
currently have doing it. Maybe he is good at finding tricky bugs that have
eluded the rest of the team or that they simply don't have time to look
into.

He is going to need a "tour" of your app and .Net given by somebody who
understands both. If that person also knows something about Access he/she
could even contrast the two languages. All things considered it may not be
..Net command set that gives him the most problem, I know people quite versed
in a language who couldn't make heads or tails of an application written in
that language. An orientation to what was done and why helps alot.

Tom
"Dennis" <De****@discussions.microsoft.comwrote in message
news:96**********************************@microsof t.com...

Simple...assign him something simple to do in VB.Net and see what he
does...if he can't figure out how to learn what he needs to know to get it
done then fire him...if he does then give him something more complicated.
--
Dennis in Houston
"Stephany Young" wrote:

Well ... This one has all the hallmarks of 'how long is a piece of
string?'.

Your use of the word 'inherited' indicates to me that you did not recruit
him yourself. How he came to be working for your company is a major
factor
in how you approach the exercise. Was he, for instance, in some other
position where he used 'MS Access' etc. and now is being moved into a
more
'mainstream' area of the company, or perhaps recruited by someone else in
the company as a personal favour or similar reason. Maybe he, himself
'asked' to moved from weher he was to 'mainstream' area of the company.
In
addition, is this person 'new' to you personally or have you known him
for
some time. This sort of information is important to you so that you can
gauge his ability to learn, his level of self-motivation and perhaps his
abilities in analysing and solving 'problems', which, after all,
programming
is all about.

Realisticly, you have to gaugue his skill levels in various areas and the
best way is to start at the beginning. That is to start him off on 'ye
olde
standard' Hello World! console application. This should have the
intention
of introducing him to the VS IDE, the VB.NET compiler and the VS
Debugger.
It important that he understand what is actually happening when the app
hits
the 'Sub Main()' because, in Access, the need to worry about that level
of
functionality was hidden from the user.

As you are satisfied that he has mastered each step, increase the
complexity
of the exercises at the rate you gauge to be appropriate. Some people
learn
faster than others and some are able to grasp very complex concepts very
quickly indeed.

Reinforce the need to have Option Explicit and Option Strict turned on in
ALL projects, again making sure that he understands why.

Reinforce the need, and of course, the reasons, to follow the company
standards for naming conventions and coding styles at all times. Make
sure
that he is given a copy of the company standards manual as early as
possible.

In parallel with this, introduce him to existing projects. For example,
take
a small app and get him to dissect the code to understand what the app is
doing. It is not good enough for him to tell you he understands it, he
must
be able to demonstrate that he understands it. I get people to write a
report (in prose) of their analysis of the application, which also
provides
me with a way of gauging their written communication skill level. Make
sure
you review the report with the person, reinforcing where they have 'got
it
right' and correcting where they haven't.

Once you can gauge that their proficiency levels are at a certain stage
you
can send them out 'to play' on their own, but still reviewing what they
are
doing. As their skill levels increase you will be able to reduce the
amount
of reviewing that you need to do. When he makes a 'mistake' make sure you
don't browbeat him with it, rather, uUse it as an opportunity for
analysis
and learning.

At all steps along the way, you, of course, need to make sure that you
are
pointing them toward the appropriate references that will provide more
technical explanations on various concepts.

If the person concerned is a 'quick study' and is self-motivated this
process may be as short as a few weeks. For others it may extend into
months.

Unfortunately there is no 'magic bullet' formula that dictates how long
such
a process will take just as there is no 'magic bullet' formula that tells
you how you must go about it.

I have a slogan (which is never erased) written in big letters across the
top of my whiteboard. It reads "THERE IS NO SUBSTITUTE FOR TRAINING!'.

Good luck.
"BK" <bk******@hotmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...
Our .Net team has just inherited a junior programmer that we need to
get up to speed as quickly as possible. Unfortunately, his skill set
is largely Access with some VB6 and ASP classic experience. We employ
some parts of XP such as pair programming, and this should help. Other
than books, does anyone have any suggestions? His skill set is pretty
antiquated and we need to get him up to speed as quickly as possible so
any suggestions are appreciated.

Background:
Mixture of Vb.Net and C#.Net code
Mixture of Oracle, DB2, and SQL server backends (we have our own
DataAccess class similar to the MS Enterprise Library Data Access)
Mostly Windows Forms for front ends
Mostly 4 tier design due to the complexity of our needs.

Thanks,

[Tom Leylan]

I think you will have to admit that "fire him" isn't typically a synonym for
"send him back to what he was doing before" right? The Chairman of the
Board of HP resigned on Sept. 22nd... i.e. the size of your company and your
position doesn't mean everything. A manager at Sears can burn $25 million
and not bat an eye but he/she wouldn't make the same decisions if it was
their own $25 million at risk. Besides did it become a worldwide
organization based upon your firing policy or was it already one when you
got there?

So we're clear I disagreed with your "easy, test them, fire them" response.
If you read the message you will see they almost assuredly don't have "send
him back" as an option but more to the point just because the guy can't
handle what you personally think is easy doesn't mean he isn't very talented
in something you cannot do at all. Perhaps he is good at writing
documentation, you may have gotten rid of the guy who wouldn't write "fire
him" when he meant "send him back."

If he has nothing to add to the project who would argue that he should be
kept on the project? Nobody I know. I've only suggested a hard and fast,
code it or get out test (given he is a "junior programmer") might not be the
best tactic.

Perhaps we should just agree to disagree on "send him back" vs "find out how
he can help".
"Dennis" <De****@discussions.microsoft.comwrote in message
news:B2**********************************@microsof t.com...

By fire him, I meant send him back to what he was doing before. Giving
him a
problem to solve on his own tests both his learning skills and iniative.
By
the way, I manage a worldwide organization with operations in many
countries
with several sub-managers and Engineers working with me and we just can't
have people on our staff who can't handle their own learning path.
Neither
can any successful organization.
--
Dennis in Houston
"Tom Leylan" wrote:

>In the interest of communication (not argument) I'd like to say it was a
treat to read Stephany's well-reasoned reply. And to Dennis, I can
appreciate the fact you run your company that way (how many employees do
you
have BTW) but good/smart companies don't. If he was an "employee" it
means
he has knowledge of the business and one would prefer not to throw that
away. Besides what is "easy" and what is "complicated" and why must
everybody perform complicated tasks? Are there no routine tasks to
perform?

To the original poster... I'd recommend you consider Stephany's response.
What I would add is a question "get up to speed with what?" Are you
hoping
the new guy can design new input forms, write new reports, review all the
SQL stored procedures and travel to the Denver office to do training?
Perhaps there is some task that match his current skills. If his Access
DB
experience makes it difficult for him to grasp the 4-tier design of your
system right now it would be best not to give him the responsibility to
fix
something in that area. Generally speaking people have particular skills
and if you determine what his are he can be of benefit to you
immediately.
He might (for instance) be better at designing reports than the people
you
currently have doing it. Maybe he is good at finding tricky bugs that
have
eluded the rest of the team or that they simply don't have time to look
into.

He is going to need a "tour" of your app and .Net given by somebody who
understands both. If that person also knows something about Access
he/she
could even contrast the two languages. All things considered it may not
be
..Net command set that gives him the most problem, I know people quite
versed
in a language who couldn't make heads or tails of an application written
in
that language. An orientation to what was done and why helps alot.

Tom
"Dennis" <De****@discussions.microsoft.comwrote in message
news:96**********************************@microso ft.com...

Simple...assign him something simple to do in VB.Net and see what he
does...if he can't figure out how to learn what he needs to know to get
it
done then fire him...if he does then give him something more
complicated.
--
Dennis in Houston
"Stephany Young" wrote:

Well ... This one has all the hallmarks of 'how long is a piece of
string?'.

Your use of the word 'inherited' indicates to me that you did not
recruit
him yourself. How he came to be working for your company is a major
factor
in how you approach the exercise. Was he, for instance, in some other
position where he used 'MS Access' etc. and now is being moved into a
more
'mainstream' area of the company, or perhaps recruited by someone else
in
the company as a personal favour or similar reason. Maybe he, himself
'asked' to moved from weher he was to 'mainstream' area of the
company.
In
addition, is this person 'new' to you personally or have you known him
for
some time. This sort of information is important to you so that you
can
gauge his ability to learn, his level of self-motivation and perhaps
his
abilities in analysing and solving 'problems', which, after all,
programming
is all about.

Realisticly, you have to gaugue his skill levels in various areas and
the
best way is to start at the beginning. That is to start him off on 'ye
olde
standard' Hello World! console application. This should have the
intention
of introducing him to the VS IDE, the VB.NET compiler and the VS
Debugger.
It important that he understand what is actually happening when the
app
hits
the 'Sub Main()' because, in Access, the need to worry about that
level
of
functionality was hidden from the user.

As you are satisfied that he has mastered each step, increase the
complexity
of the exercises at the rate you gauge to be appropriate. Some people
learn
faster than others and some are able to grasp very complex concepts
very
quickly indeed.

Reinforce the need to have Option Explicit and Option Strict turned on
in
ALL projects, again making sure that he understands why.

Reinforce the need, and of course, the reasons, to follow the company
standards for naming conventions and coding styles at all times. Make
sure
that he is given a copy of the company standards manual as early as
possible.

In parallel with this, introduce him to existing projects. For
example,
take
a small app and get him to dissect the code to understand what the app
is
doing. It is not good enough for him to tell you he understands it, he
must
be able to demonstrate that he understands it. I get people to write a
report (in prose) of their analysis of the application, which also
provides
me with a way of gauging their written communication skill level. Make
sure
you review the report with the person, reinforcing where they have
'got
it
right' and correcting where they haven't.

Once you can gauge that their proficiency levels are at a certain
stage
you
can send them out 'to play' on their own, but still reviewing what
they
are
doing. As their skill levels increase you will be able to reduce the
amount
of reviewing that you need to do. When he makes a 'mistake' make sure
you
don't browbeat him with it, rather, uUse it as an opportunity for
analysis
and learning.

At all steps along the way, you, of course, need to make sure that you
are
pointing them toward the appropriate references that will provide more
technical explanations on various concepts.

If the person concerned is a 'quick study' and is self-motivated this
process may be as short as a few weeks. For others it may extend into
months.

Unfortunately there is no 'magic bullet' formula that dictates how
long
such
a process will take just as there is no 'magic bullet' formula that
tells
you how you must go about it.

I have a slogan (which is never erased) written in big letters across
the
top of my whiteboard. It reads "THERE IS NO SUBSTITUTE FOR TRAINING!'.

Good luck.
"BK" <bk******@hotmail.comwrote in message
news:11**********************@n67g2000cwd.googleg roups.com...
Our .Net team has just inherited a junior programmer that we need to
get up to speed as quickly as possible. Unfortunately, his skill
set
is largely Access with some VB6 and ASP classic experience. We
employ
some parts of XP such as pair programming, and this should help.
Other
than books, does anyone have any suggestions? His skill set is
pretty
antiquated and we need to get him up to speed as quickly as possible
so
any suggestions are appreciated.

Background:
Mixture of Vb.Net and C#.Net code
Mixture of Oracle, DB2, and SQL server backends (we have our own
DataAccess class similar to the MS Enterprise Library Data Access)
Mostly Windows Forms for front ends
Mostly 4 tier design due to the complexity of our needs.

Thanks,

[aaron.kempf]

I think that you VB.net fags are a bunch of fucking wannabes
VB6 was more powerful than VB.net it was easier; it was consistent--
the code was portable. I could use the same code in Excel, Outlook,
Batch Files (VBS).. I could use the same code on the internet for
clientside code.. for serverside code.

As it is; those dipshits in Redmond expect me to learn THREE LANGUAGES
to be able to do what I used to be able to do in ONE LANGUAGE.

And I would rather eat 20 diseased cocks then ever learn a language
named C _ANYTHING_

I'm not going to do VB.net until I can write a VB.net FUNCTION and
paste it into Excel

eat a dick you cocky bastards; VB.net is going away in the next
version.. My friend at Microsoft told me this several times now

-Aaron


Tom Leylan wrote:

I think you will have to admit that "fire him" isn't typically a synonym for
"send him back to what he was doing before" right? The Chairman of the
Board of HP resigned on Sept. 22nd... i.e. the size of your company and your
position doesn't mean everything. A manager at Sears can burn $25 million
and not bat an eye but he/she wouldn't make the same decisions if it was
their own $25 million at risk. Besides did it become a worldwide
organization based upon your firing policy or was it already one when you
got there?

So we're clear I disagreed with your "easy, test them, fire them" response.
If you read the message you will see they almost assuredly don't have "send
him back" as an option but more to the point just because the guy can't
handle what you personally think is easy doesn't mean he isn't very talented
in something you cannot do at all. Perhaps he is good at writing
documentation, you may have gotten rid of the guy who wouldn't write "fire
him" when he meant "send him back."

If he has nothing to add to the project who would argue that he should be
kept on the project? Nobody I know. I've only suggested a hard and fast,
code it or get out test (given he is a "junior programmer") might not be the
best tactic.

Perhaps we should just agree to disagree on "send him back" vs "find out how
he can help".
"Dennis" <De****@discussions.microsoft.comwrote in message
news:B2**********************************@microsof t.com...

By fire him, I meant send him back to what he was doing before. Giving
him a
problem to solve on his own tests both his learning skills and iniative.
By
the way, I manage a worldwide organization with operations in many
countries
with several sub-managers and Engineers working with me and we just can't
have people on our staff who can't handle their own learning path.
Neither
can any successful organization.
--
Dennis in Houston
"Tom Leylan" wrote:

In the interest of communication (not argument) I'd like to say it was a
treat to read Stephany's well-reasoned reply. And to Dennis, I can
appreciate the fact you run your company that way (how many employees do
you
have BTW) but good/smart companies don't. If he was an "employee" it
means
he has knowledge of the business and one would prefer not to throw that
away. Besides what is "easy" and what is "complicated" and why must
everybody perform complicated tasks? Are there no routine tasks to
perform?

To the original poster... I'd recommend you consider Stephany's response.
What I would add is a question "get up to speed with what?" Are you
hoping
the new guy can design new input forms, write new reports, review all the
SQL stored procedures and travel to the Denver office to do training?
Perhaps there is some task that match his current skills. If his Access
DB
experience makes it difficult for him to grasp the 4-tier design of your
system right now it would be best not to give him the responsibility to
fix
something in that area. Generally speaking people have particular skills
and if you determine what his are he can be of benefit to you
immediately.
He might (for instance) be better at designing reports than the people
you
currently have doing it. Maybe he is good at finding tricky bugs that
have
eluded the rest of the team or that they simply don't have time to look
into.

He is going to need a "tour" of your app and .Net given by somebody who
understands both. If that person also knows something about Access
he/she
could even contrast the two languages. All things considered it may not
be
..Net command set that gives him the most problem, I know people quite
versed
in a language who couldn't make heads or tails of an application written
in
that language. An orientation to what was done and why helps alot.

Tom
"Dennis" <De****@discussions.microsoft.comwrote in message
news:96**********************************@microsof t.com...
Simple...assign him something simple to do in VB.Net and see what he
does...if he can't figure out how to learn what he needs to know to get
it
done then fire him...if he does then give him something more
complicated.
--
Dennis in Houston
"Stephany Young" wrote:

Well ... This one has all the hallmarks of 'how long is a piece of
string?'.

Your use of the word 'inherited' indicates to me that you did not
recruit
him yourself. How he came to be working for your company is a major
factor
in how you approach the exercise. Was he, for instance, in some other
position where he used 'MS Access' etc. and now is being moved into a
more
'mainstream' area of the company, or perhaps recruited by someone else
in
the company as a personal favour or similar reason. Maybe he, himself
'asked' to moved from weher he was to 'mainstream' area of the
company.
In
addition, is this person 'new' to you personally or have you known him
for
some time. This sort of information is important to you so that you
can
gauge his ability to learn, his level of self-motivation and perhaps
his
abilities in analysing and solving 'problems', which, after all,
programming
is all about.

Realisticly, you have to gaugue his skill levels in various areas and
the
best way is to start at the beginning. That is to start him off on 'ye
olde
standard' Hello World! console application. This should have the
intention
of introducing him to the VS IDE, the VB.NET compiler and the VS
Debugger.
It important that he understand what is actually happening when the
app
hits
the 'Sub Main()' because, in Access, the need to worry about that
level
of
functionality was hidden from the user.

As you are satisfied that he has mastered each step, increase the
complexity
of the exercises at the rate you gauge to be appropriate. Some people
learn
faster than others and some are able to grasp very complex concepts
very
quickly indeed.

Reinforce the need to have Option Explicit and Option Strict turned on
in
ALL projects, again making sure that he understands why.

Reinforce the need, and of course, the reasons, to follow the company
standards for naming conventions and coding styles at all times. Make
sure
that he is given a copy of the company standards manual as early as
possible.

In parallel with this, introduce him to existing projects. For
example,
take
a small app and get him to dissect the code to understand what the app
is
doing. It is not good enough for him to tell you he understands it, he
must
be able to demonstrate that he understands it. I get people to write a
report (in prose) of their analysis of the application, which also
provides
me with a way of gauging their written communication skill level. Make
sure
you review the report with the person, reinforcing where they have
'got
it
right' and correcting where they haven't.

Once you can gauge that their proficiency levels are at a certain
stage
you
can send them out 'to play' on their own, but still reviewing what
they
are
doing. As their skill levels increase you will be able to reduce the
amount
of reviewing that you need to do. When he makes a 'mistake' make sure
you
don't browbeat him with it, rather, uUse it as an opportunity for
analysis
and learning.

At all steps along the way, you, of course, need to make sure that you
are
pointing them toward the appropriate references that will provide more
technical explanations on various concepts.

If the person concerned is a 'quick study' and is self-motivated this
process may be as short as a few weeks. For others it may extend into
months.

Unfortunately there is no 'magic bullet' formula that dictates how
long
such
a process will take just as there is no 'magic bullet' formula that
tells
you how you must go about it.

I have a slogan (which is never erased) written in big letters across
the
top of my whiteboard. It reads "THERE IS NO SUBSTITUTE FOR TRAINING!'.

Good luck.
"BK" <bk******@hotmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...
Our .Net team has just inherited a junior programmer that we need to
get up to speed as quickly as possible. Unfortunately, his skill
set
is largely Access with some VB6 and ASP classic experience. We
employ
some parts of XP such as pair programming, and this should help.
Other
than books, does anyone have any suggestions? His skill set is
pretty
antiquated and we need to get him up to speed as quickly as possible
so
any suggestions are appreciated.

Background:
Mixture of Vb.Net and C#.Net code
Mixture of Oracle, DB2, and SQL server backends (we have our own
DataAccess class similar to the MS Enterprise Library Data Access)
Mostly Windows Forms for front ends
Mostly 4 tier design due to the complexity of our needs.

Thanks,

[rowe_newsgroups]

***Warning - Troll Crossing***

Just a friendly reminder to not feed the trolls...

Thanks,

Seth Rowe
aa*********@gmail.com wrote:

I think that you VB.net fags are a bunch of fucking wannabes
VB6 was more powerful than VB.net it was easier; it was consistent--
the code was portable. I could use the same code in Excel, Outlook,
Batch Files (VBS).. I could use the same code on the internet for
clientside code.. for serverside code.

As it is; those dipshits in Redmond expect me to learn THREE LANGUAGES
to be able to do what I used to be able to do in ONE LANGUAGE.

And I would rather eat 20 diseased cocks then ever learn a language
named C _ANYTHING_

I'm not going to do VB.net until I can write a VB.net FUNCTION and
paste it into Excel

eat a dick you cocky bastards; VB.net is going away in the next
version.. My friend at Microsoft told me this several times now

-Aaron


Tom Leylan wrote:

I think you will have to admit that "fire him" isn't typically a synonym for
"send him back to what he was doing before" right? The Chairman of the
Board of HP resigned on Sept. 22nd... i.e. the size of your company and your
position doesn't mean everything. A manager at Sears can burn $25 million
and not bat an eye but he/she wouldn't make the same decisions if it was
their own $25 million at risk. Besides did it become a worldwide
organization based upon your firing policy or was it already one when you
got there?

So we're clear I disagreed with your "easy, test them, fire them" response.
If you read the message you will see they almost assuredly don't have "send
him back" as an option but more to the point just because the guy can't
handle what you personally think is easy doesn't mean he isn't very talented
in something you cannot do at all. Perhaps he is good at writing
documentation, you may have gotten rid of the guy who wouldn't write "fire
him" when he meant "send him back."

If he has nothing to add to the project who would argue that he should be
kept on the project? Nobody I know. I've only suggested a hard and fast,
code it or get out test (given he is a "junior programmer") might not be the
best tactic.

Perhaps we should just agree to disagree on "send him back" vs "find out how
he can help".
"Dennis" <De****@discussions.microsoft.comwrote in message
news:B2**********************************@microsof t.com...

By fire him, I meant send him back to what he was doing before. Giving
him a
problem to solve on his own tests both his learning skills and iniative.
By
the way, I manage a worldwide organization with operations in many
countries
with several sub-managers and Engineers working with me and we just can't
have people on our staff who can't handle their own learning path.
Neither
can any successful organization.
--
Dennis in Houston
>
>
"Tom Leylan" wrote:
>
>In the interest of communication (not argument) I'd like to say it was a
>treat to read Stephany's well-reasoned reply. And to Dennis, I can
>appreciate the fact you run your company that way (how many employees do
>you
>have BTW) but good/smart companies don't. If he was an "employee" it
>means
>he has knowledge of the business and one would prefer not to throw that
>away. Besides what is "easy" and what is "complicated" and why must
>everybody perform complicated tasks? Are there no routine tasks to
>perform?
>>
>To the original poster... I'd recommend you consider Stephany's response.
>What I would add is a question "get up to speed with what?" Are you
>hoping
>the new guy can design new input forms, write new reports, review all the
>SQL stored procedures and travel to the Denver office to do training?
>Perhaps there is some task that match his current skills. If his Access
>DB
>experience makes it difficult for him to grasp the 4-tier design of your
>system right now it would be best not to give him the responsibility to
>fix
>something in that area. Generally speaking people have particular skills
>and if you determine what his are he can be of benefit to you
>immediately.
>He might (for instance) be better at designing reports than the people
>you
>currently have doing it. Maybe he is good at finding tricky bugs that
>have
>eluded the rest of the team or that they simply don't have time to look
>into.
>>
>He is going to need a "tour" of your app and .Net given by somebody who
>understands both. If that person also knows something about Access
>he/she
>could even contrast the two languages. All things considered it may not
>be
>..Net command set that gives him the most problem, I know people quite
>versed
>in a language who couldn't make heads or tails of an application written
>in
>that language. An orientation to what was done and why helps alot.
>>
>Tom
>>
>>
>"Dennis" <De****@discussions.microsoft.comwrote in message
>news:96**********************************@microso ft.com...
Simple...assign him something simple to do in VB.Net and see what he
does...if he can't figure out how to learn what he needs to know to get
it
done then fire him...if he does then give him something more
complicated.
--
Dennis in Houston
>
>
"Stephany Young" wrote:
>
>Well ... This one has all the hallmarks of 'how long is a piece of
>string?'.
>>
>Your use of the word 'inherited' indicates to me that you did not
>recruit
>him yourself. How he came to be working for your company is a major
>factor
>in how you approach the exercise. Was he, for instance, in some other
>position where he used 'MS Access' etc. and now is being moved into a
>more
>'mainstream' area of the company, or perhaps recruited by someone else
>in
>the company as a personal favour or similar reason. Maybe he, himself
>'asked' to moved from weher he was to 'mainstream' area of the
>company.
>In
>addition, is this person 'new' to you personally or have you known him
>for
>some time. This sort of information is important to you so that you
>can
>gauge his ability to learn, his level of self-motivation and perhaps
>his
>abilities in analysing and solving 'problems', which, after all,
>programming
>is all about.
>>
>Realisticly, you have to gaugue his skill levels in various areas and
>the
>best way is to start at the beginning. That is to start him off on 'ye
>olde
>standard' Hello World! console application. This should have the
>intention
>of introducing him to the VS IDE, the VB.NET compiler and the VS
>Debugger.
>It important that he understand what is actually happening when the
>app
>hits
>the 'Sub Main()' because, in Access, the need to worry about that
>level
>of
>functionality was hidden from the user.
>>
>As you are satisfied that he has mastered each step, increase the
>complexity
>of the exercises at the rate you gauge to be appropriate. Some people
>learn
>faster than others and some are able to grasp very complex concepts
>very
>quickly indeed.
>>
>Reinforce the need to have Option Explicit and Option Strict turned on
>in
>ALL projects, again making sure that he understands why.
>>
>Reinforce the need, and of course, the reasons, to follow the company
>standards for naming conventions and coding styles at all times. Make
>sure
>that he is given a copy of the company standards manual as early as
>possible.
>>
>In parallel with this, introduce him to existing projects. For
>example,
>take
>a small app and get him to dissect the code to understand what the app
>is
>doing. It is not good enough for him to tell you he understands it, he
>must
>be able to demonstrate that he understands it. I get people to write a
>report (in prose) of their analysis of the application, which also
>provides
>me with a way of gauging their written communication skill level. Make
>sure
>you review the report with the person, reinforcing where they have
>'got
>it
>right' and correcting where they haven't.
>>
>Once you can gauge that their proficiency levels are at a certain
>stage
>you
>can send them out 'to play' on their own, but still reviewing what
>they
>are
>doing. As their skill levels increase you will be able to reduce the
>amount
>of reviewing that you need to do. When he makes a 'mistake' make sure
>you
>don't browbeat him with it, rather, uUse it as an opportunity for
>analysis
>and learning.
>>
>At all steps along the way, you, of course, need to make sure that you
>are
>pointing them toward the appropriate references that will provide more
>technical explanations on various concepts.
>>
>If the person concerned is a 'quick study' and is self-motivated this
>process may be as short as a few weeks. For others it may extend into
>months.
>>
>Unfortunately there is no 'magic bullet' formula that dictates how
>long
>such
>a process will take just as there is no 'magic bullet' formula that
>tells
>you how you must go about it.
>>
>I have a slogan (which is never erased) written in big letters across
>the
>top of my whiteboard. It reads "THERE IS NO SUBSTITUTE FOR TRAINING!'.
>>
>Good luck.
>>
>>
>"BK" <bk******@hotmail.comwrote in message
>news:11**********************@n67g2000cwd.googleg roups.com...
Our .Net team has just inherited a junior programmer that we need to
get up to speed as quickly as possible. Unfortunately, his skill
set
is largely Access with some VB6 and ASP classic experience. We
employ
some parts of XP such as pair programming, and this should help.
Other
than books, does anyone have any suggestions? His skill set is
pretty
antiquated and we need to get him up to speed as quickly as possible
so
any suggestions are appreciated.
>
Background:
Mixture of Vb.Net and C#.Net code
Mixture of Oracle, DB2, and SQL server backends (we have our own
DataAccess class similar to the MS Enterprise Library Data Access)
Mostly Windows Forms for front ends
Mostly 4 tier design due to the complexity of our needs.
>
Thanks,
>
>>
>>
>>
>>
>>
>>

[aaron.kempf]

Rowe;

I speak the truth, MS_FANBOY

..NET is not a practical solution for anything.
Build a time machine; go back and blow up Microsoft before they start
trying to con us into this whole .NET _CRAP_

Circa terminator 2-- go back in time and fix it so that these dipshits
don't KILL OFF THE WORLDS MOST PROGRAMMING LANGUAGE.

As it is... VB is DEAD... VB6 is dead; and VB.net is a complete and
utter failure.

MS is going to kill it in the next version of Visual Studio.. So what's
going to happen when you force this 'so called Junior Programmer' into
learning a language that will be discontinued?

Right now; he can deliver apps. Right now; he's probably the best
database person-- that includes so called 'SQL Server Experts' at your
company.

Teach him Access Data Projects instead of this .NET crap.

..NET is a total fucking waste of time; it's less productive than
anything called VB6.

These dipshits in Redmond KILLED OFF THE WORLDS MOST POPULAR
PROGRAMMING LANGUAGE JUST BECAUSE THEY WERE SCARED OF A TINY COMPANY IN
CALIFORNIA WITH A MEASLY THREE BILLION DOLLAR MARKET CAP.

Shit the cracker-jax company could buy Sun for all I fucking care.

This dipshit company 'threw out the baby with the bathwater' and killed
off the most popular langauge; and they came out with this new language
called 'C#' that is about 5 times as popular as VB.net right now.. that
means; if C# has a 30% marketshare then VB.net has a 6% marksetshare.

Is it worth it? Is it worth making this developer work his ass off in
order to learn a language that is going away?

On the one hand; moving to .NET isn't as difficult as you think that he
is... he probably knows VBA / VB6 pretty well.

But making him learn a new language NOW and another new language NEXT
YEAR WHEN MS KILLS VB 9?

It's just not efficient.

Teach everyone PHP and fuck Microsoft in the ear.

-Aaron

rowe_newsgroups wrote:

***Warning - Troll Crossing***

Just a friendly reminder to not feed the trolls...

Thanks,

Seth Rowe
aa*********@gmail.com wrote:

I think that you VB.net fags are a bunch of fucking wannabes
VB6 was more powerful than VB.net it was easier; it was consistent--
the code was portable. I could use the same code in Excel, Outlook,
Batch Files (VBS).. I could use the same code on the internet for
clientside code.. for serverside code.

As it is; those dipshits in Redmond expect me to learn THREE LANGUAGES
to be able to do what I used to be able to do in ONE LANGUAGE.

And I would rather eat 20 diseased cocks then ever learn a language
named C _ANYTHING_

I'm not going to do VB.net until I can write a VB.net FUNCTION and
paste it into Excel

eat a dick you cocky bastards; VB.net is going away in the next
version.. My friend at Microsoft told me this several times now

-Aaron


Tom Leylan wrote:

I think you will have to admit that "fire him" isn't typically a synonym for
"send him back to what he was doing before" right? The Chairman of the
Board of HP resigned on Sept. 22nd... i.e. the size of your company and your
position doesn't mean everything. A manager at Sears can burn $25 million
and not bat an eye but he/she wouldn't make the same decisions if it was
their own $25 million at risk. Besides did it become a worldwide
organization based upon your firing policy or was it already one when you
got there?
>
So we're clear I disagreed with your "easy, test them, fire them" response.
If you read the message you will see they almost assuredly don't have "send
him back" as an option but more to the point just because the guy can't
handle what you personally think is easy doesn't mean he isn't very talented
in something you cannot do at all. Perhaps he is good at writing
documentation, you may have gotten rid of the guy who wouldn't write "fire
him" when he meant "send him back."
>
If he has nothing to add to the project who would argue that he should be
kept on the project? Nobody I know. I've only suggested a hard and fast,
code it or get out test (given he is a "junior programmer") might not be the
best tactic.
>
Perhaps we should just agree to disagree on "send him back" vs "find out how
he can help".
>
>
"Dennis" <De****@discussions.microsoft.comwrote in message
news:B2**********************************@microsof t.com...
By fire him, I meant send him back to what he was doing before. Giving
him a
problem to solve on his own tests both his learning skills and iniative.
By
the way, I manage a worldwide organization with operations in many
countries
with several sub-managers and Engineers working with me and we just can't
have people on our staff who can't handle their own learning path.
Neither
can any successful organization.
--
Dennis in Houston


"Tom Leylan" wrote:

In the interest of communication (not argument) I'd like to say it was a
treat to read Stephany's well-reasoned reply. And to Dennis, I can
appreciate the fact you run your company that way (how many employees do
you
have BTW) but good/smart companies don't. If he was an "employee" it
means
he has knowledge of the business and one would prefer not to throw that
away. Besides what is "easy" and what is "complicated" and why must
everybody perform complicated tasks? Are there no routine tasks to
perform?
>
To the original poster... I'd recommend you consider Stephany's response.
What I would add is a question "get up to speed with what?" Are you
hoping
the new guy can design new input forms, write new reports, review all the
SQL stored procedures and travel to the Denver office to do training?
Perhaps there is some task that match his current skills. If his Access
DB
experience makes it difficult for him to grasp the 4-tier design of your
system right now it would be best not to give him the responsibility to
fix
something in that area. Generally speaking people have particular skills
and if you determine what his are he can be of benefit to you
immediately.
He might (for instance) be better at designing reports than the people
you
currently have doing it. Maybe he is good at finding tricky bugs that
have
eluded the rest of the team or that they simply don't have time to look
into.
>
He is going to need a "tour" of your app and .Net given by somebody who
understands both. If that person also knows something about Access
he/she
could even contrast the two languages. All things considered it may not
be
..Net command set that gives him the most problem, I know people quite
versed
in a language who couldn't make heads or tails of an application written
in
that language. An orientation to what was done and why helps alot.
>
Tom
>
>
"Dennis" <De****@discussions.microsoft.comwrote in message
news:96**********************************@microsof t.com...
Simple...assign him something simple to do in VB.Net and see what he
does...if he can't figure out how to learn what he needs to know to get
it
done then fire him...if he does then give him something more
complicated.
--
Dennis in Houston


"Stephany Young" wrote:

Well ... This one has all the hallmarks of 'how long is a piece of
string?'.
>
Your use of the word 'inherited' indicates to me that you did not
recruit
him yourself. How he came to be working for your company is a major
factor
in how you approach the exercise. Was he, for instance, in some other
position where he used 'MS Access' etc. and now is being moved into a
more
'mainstream' area of the company, or perhaps recruited by someone else
in
the company as a personal favour or similar reason. Maybe he, himself
'asked' to moved from weher he was to 'mainstream' area of the
company.
In
addition, is this person 'new' to you personally or have you known him
for
some time. This sort of information is important to you so that you
can
gauge his ability to learn, his level of self-motivation and perhaps
his
abilities in analysing and solving 'problems', which, after all,
programming
is all about.
>
Realisticly, you have to gaugue his skill levels in various areas and
the
best way is to start at the beginning. That is to start him off on 'ye
olde
standard' Hello World! console application. This should have the
intention
of introducing him to the VS IDE, the VB.NET compiler and the VS
Debugger.
It important that he understand what is actually happening when the
app
hits
the 'Sub Main()' because, in Access, the need to worry about that
level
of
functionality was hidden from the user.
>
As you are satisfied that he has mastered each step, increase the
complexity
of the exercises at the rate you gauge to be appropriate. Some people
learn
faster than others and some are able to grasp very complex concepts
very
quickly indeed.
>
Reinforce the need to have Option Explicit and Option Strict turned on
in
ALL projects, again making sure that he understands why.
>
Reinforce the need, and of course, the reasons, to follow the company
standards for naming conventions and coding styles at all times. Make
sure
that he is given a copy of the company standards manual as early as
possible.
>
In parallel with this, introduce him to existing projects. For
example,
take
a small app and get him to dissect the code to understand what the app
is
doing. It is not good enough for him to tell you he understands it, he
must
be able to demonstrate that he understands it. I get people to write a
report (in prose) of their analysis of the application, which also
provides
me with a way of gauging their written communication skill level. Make
sure
you review the report with the person, reinforcing where they have
'got
it
right' and correcting where they haven't.
>
Once you can gauge that their proficiency levels are at a certain
stage
you
can send them out 'to play' on their own, but still reviewing what
they
are
doing. As their skill levels increase you will be able to reduce the
amount
of reviewing that you need to do. When he makes a 'mistake' make sure
you
don't browbeat him with it, rather, uUse it as an opportunity for
analysis
and learning.
>
At all steps along the way, you, of course, need to make sure that you
are
pointing them toward the appropriate references that will provide more
technical explanations on various concepts.
>
If the person concerned is a 'quick study' and is self-motivated this
process may be as short as a few weeks. For others it may extend into
months.
>
Unfortunately there is no 'magic bullet' formula that dictates how
long
such
a process will take just as there is no 'magic bullet' formula that
tells
you how you must go about it.
>
I have a slogan (which is never erased) written in big letters across
the
top of my whiteboard. It reads "THERE IS NO SUBSTITUTE FOR TRAINING!'.
>
Good luck.
>
>
"BK" <bk******@hotmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...
Our .Net team has just inherited a junior programmer that we need to
get up to speed as quickly as possible. Unfortunately, his skill
set
is largely Access with some VB6 and ASP classic experience. We
employ
some parts of XP such as pair programming, and this should help.
Other
than books, does anyone have any suggestions? His skill set is
pretty
antiquated and we need to get him up to speed as quickly as possible
so
any suggestions are appreciated.

Background:
Mixture of Vb.Net and C#.Net code
Mixture of Oracle, DB2, and SQL server backends (we have our own
DataAccess class similar to the MS Enterprise Library Data Access)
Mostly Windows Forms for front ends
Mostly 4 tier design due to the complexity of our needs.

Thanks,

>
>
>
>
>
>