Here's what I've changed.

Discussion in 'C++' started by Noah Roberts, Aug 3, 2009.

  1. Noah Roberts

    Noah Roberts Guest

    So I am walking by the desk and actually asking for more than, "Fine,"
    now. I ask how it's going and try to actually get them to start showing
    me some code if they have any. This has helped somewhat but some things
    have slipped through still. Don't think it can be perfect.

    Second thing I've done is that I've asked for a plan before code. I
    told them they can branch the code, play with the code, etc... but that
    I want to see a plan before anything is done in the trunk. So far this
    hasn't actually happened, must have been a miscommunication or
    something. However, it's a weird change so I expect a little backlash.

    I hope that this second part will help me catch whether they understand
    the problem, the code, and have a relatively decent solution before they
    do a bunch of stuff I have to make them redo.

    What do you think?
    Noah Roberts, Aug 3, 2009
    #1
    1. Advertising

  2. Noah Roberts

    Noah Roberts Guest

    DAMN! [OT] was Re: Here's what I've changed.

    Noah Roberts wrote:
    > So I am walking by the desk and actually asking for more than, "Fine,"
    > now. I ask how it's going and try to actually get them to start showing
    > me some code if they have any. This has helped somewhat but some things
    > have slipped through still. Don't think it can be perfect.
    >
    > Second thing I've done is that I've asked for a plan before code. I
    > told them they can branch the code, play with the code, etc... but that
    > I want to see a plan before anything is done in the trunk. So far this
    > hasn't actually happened, must have been a miscommunication or
    > something. However, it's a weird change so I expect a little backlash.
    >
    > I hope that this second part will help me catch whether they understand
    > the problem, the code, and have a relatively decent solution before they
    > do a bunch of stuff I have to make them redo.
    >
    > What do you think?


    This was meant to go in the thread about junior programmers. Something
    got munged.
    Noah Roberts, Aug 3, 2009
    #2
    1. Advertising

  3. Noah Roberts

    Ian Collins Guest

    Noah Roberts wrote:
    > So I am walking by the desk and actually asking for more than, "Fine,"
    > now. I ask how it's going and try to actually get them to start showing
    > me some code if they have any. This has helped somewhat but some things
    > have slipped through still. Don't think it can be perfect.


    It really does sound like you have a serious communication problem in
    your team. The fact that standup meetings didn't work is a bad sign.
    Did you read Martin's paper (the link)? There are some good tips there
    on good and bad standup meetings.


    I suggest you spend some time pairing with them to see what they are
    really up to and make an effort to get good standup meetings going.


    --
    Ian Collins
    Ian Collins, Aug 3, 2009
    #3
  4. On 3 août, 18:07, Noah Roberts <> wrote:
    > So I am walking by the desk and actually asking for more than, "Fine,"
    > now.  I ask how it's going and try to actually get them to start showing
    > me some code if they have any.  This has helped somewhat but some things
    > have slipped through still.  Don't think it can be perfect.
    >
    > Second thing I've done is that I've asked for a plan before code.  I
    > told them they can branch the code, play with the code, etc... but that
    > I want to see a plan before anything is done in the trunk.  So far this
    > hasn't actually happened, must have been a miscommunication or
    > something.  However, it's a weird change so I expect a little backlash.
    >
    > I hope that this second part will help me catch whether they understand
    > the problem, the code, and have a relatively decent solution before they
    > do a bunch of stuff I have to make them redo.
    >
    > What do you think?


    I have skimmed through the old thread (it is so big) and you have my
    sympathy.
    One question nobody raised was:
    do you want compliance or do you want to change/introduce methods ?

    In the first case, you can simply set the tools and the rolee:
    activate access control in the svn and create a integrator role that
    review the code before comitting it to the main line. A perverse
    effect can be that a parallel trunk can start to exists (everybody
    using it) so it takes some checking.

    If you want to introduce change or new practices, it is hard work. The
    first step is to convince them. You may find some help from
    "Peopleware" (Tom DeMarco and co) and more recently "Fearless
    Change" (Linda Rising and Mary Lynn Manns) which introduce a pattern
    language for changing organization. I have heard of a new book from
    Tom DeMarco and co "Adrenaline Junkies..." that seems to also address
    teamwork patterns but I have not (yet) put my hands on it.

    As for your immediate concern, IMHO you'd better have compliance for
    the short term until the junior got some more experience and use
    tutoring on the open-minded ones (on a voluntary basis).
    Introducing change for a short term such as standup meeting (as you
    did IIRC) should be short in time (2 weeks) before a review of the
    process (retrospective) where you ask them how they feel about it and
    how they think it can be improved (i.e. they build their own ways that
    work best for them). Retrospective is subtle management and orienting
    this kind of meeting can be challenging, if you have not yet read
    about it, you'd better do it before.

    --
    Michael
    Michael Doubez, Aug 4, 2009
    #4
  5. Noah Roberts <> writes:

    > So I am walking by the desk and actually asking for more than, "Fine,"
    > now. I ask how it's going and try to actually get them to start
    > showing me some code if they have any. This has helped somewhat but
    > some things have slipped through still. Don't think it can be
    > perfect.
    >
    > Second thing I've done is that I've asked for a plan before code. I
    > told them they can branch the code, play with the code, etc... but
    > that I want to see a plan before anything is done in the trunk. So
    > far this hasn't actually happened, must have been a miscommunication
    > or something. However, it's a weird change so I expect a little
    > backlash.


    As a programmer, I find it extremely difficult to "plan" a design
    process. The problem is that some parts that seems difficult before
    hand, and for which you'd plan a lot of time or subtasks, may once
    you've thought about them resolve to a simple and elegant solution,
    while some other parts that seem easy and straightforward will finally
    need a lot of grunk work, or even more thinking before an elegant
    solution can be found.

    See also: http://c2.com/xp/TheSourceCodeIsTheDesign.html


    > I hope that this second part will help me catch whether they
    > understand the problem, the code, and have a relatively decent
    > solution before they do a bunch of stuff I have to make them redo.
    >
    > What do you think?


    'redo'. That's also something that you should plan to do anyways.
    http://c2.com/cgi/wiki/wiki?PlanToThrowOneAway

    Well, unless you have a spiral project life cycle, in which case you
    will be constantly redoing parts...

    --
    __Pascal Bourguignon__
    Pascal J. Bourguignon, Aug 4, 2009
    #5
  6. On 4 août, 11:17, (Pascal J. Bourguignon)
    wrote:
    > Noah Roberts <> writes:
    > > So I am walking by the desk and actually asking for more than, "Fine,"
    > > now.  I ask how it's going and try to actually get them to start
    > > showing me some code if they have any.  This has helped somewhat but
    > > some things have slipped through still.  Don't think it can be
    > > perfect.

    >
    > > Second thing I've done is that I've asked for a plan before code.  I
    > > told them they can branch the code, play with the code, etc... but
    > > that I want to see a plan before anything is done in the trunk.  So
    > > far this hasn't actually happened, must have been a miscommunication
    > > or something.  However, it's a weird change so I expect a little
    > > backlash.

    >
    > As a programmer, I find it extremely difficult to "plan" a design
    > process.  The problem is that some parts that seems difficult before
    > hand, and for which you'd plan a lot of time or subtasks, may once
    > you've thought about them resolve to a simple and elegant solution,
    > while some other parts that seem easy and straightforward will finally
    > need a lot of grunk work, or even more thinking before an elegant
    > solution can be found.
    >
    > See also:http://c2.com/xp/TheSourceCodeIsTheDesign.html


    As a junior, I've had to write documentation before code; it was
    reviewed and signed by a peer, the manager and the QA manager. It was
    not a perfect process and I can't say it caught a lot of design issue
    but but I got a lot of value from it from the design perspective.

    > > I hope that this second part will help me catch whether they
    > > understand the problem, the code, and have a relatively decent
    > > solution before they do a bunch of stuff I have to make them redo.

    >
    > > What do you think?

    >
    > 'redo'.  That's also something that you should plan to do anyways.http://c2.com/cgi/wiki/wiki?PlanToThrowOneAway


    But the key is in:
    [...]rebuild what has to be a better version, *given the advantages of
    hindsight*.

    If the junior hasn't sweat a bit over the issue and simply follow the
    advice, he won't get an hindsight. He will simply say "Ok! let do it
    your way".

    As they say in Zen: the finger is not the moon.

    > Well, unless you have a spiral project life cycle, in which case you
    > will be constantly redoing parts...


    Spiral project (does it have the same name in english ?) involves a
    refinement of functional specs at each iteration, this is not the case
    here: it is within an iteration.

    --
    Michael
    Michael Doubez, Aug 4, 2009
    #6
  7. Noah Roberts

    James Kanze Guest

    On Aug 4, 11:17 am, (Pascal J. Bourguignon)
    wrote:
    > Noah Roberts <> writes:
    > > So I am walking by the desk and actually asking for more
    > > than, "Fine," now. I ask how it's going and try to actually
    > > get them to start showing me some code if they have any.
    > > This has helped somewhat but some things have slipped
    > > through still. Don't think it can be perfect.


    > > Second thing I've done is that I've asked for a plan before
    > > code. I told them they can branch the code, play with the
    > > code, etc... but that I want to see a plan before anything
    > > is done in the trunk. So far this hasn't actually happened,
    > > must have been a miscommunication or something. However,
    > > it's a weird change so I expect a little backlash.


    > As a programmer, I find it extremely difficult to "plan" a
    > design process.


    Or a coding process, or much of anything else. This is
    something beginning programmers have to learn, and they need
    help learning it from the experienced programmers. The problem
    is that many experienced programmers (myself included) never
    really learned it well, either. In a commercial environment,
    however, it's essential---good management has a nasty tendency
    to want to know how much something is going to cost before they
    approuve the budget for it. (Stop and think about it: would you
    sign a contract to have a house built, and to pay for it,
    without any mention of the cost, or what the house will look
    like when it's done?)

    > The problem is that some parts that seems difficult before
    > hand, and for which you'd plan a lot of time or subtasks, may
    > once you've thought about them resolve to a simple and elegant
    > solution, while some other parts that seem easy and
    > straightforward will finally need a lot of grunk work, or even
    > more thinking before an elegant solution can be found.


    > See also:http://c2.com/xp/TheSourceCodeIsTheDesign.html


    Note that pretty much anyone can (and does) post at that site.
    Whether they know what they're talking about or not. (Note too
    that being an expert in OO design does not qualify one as an
    expert in software process. Or vice versa.)

    > > I hope that this second part will help me catch whether they
    > > understand the problem, the code, and have a relatively
    > > decent solution before they do a bunch of stuff I have to
    > > make them redo.


    > > What do you think?


    > 'redo'. That's also something that you should plan to do
    > anyways.http://c2.com/cgi/wiki/wiki?PlanToThrowOneAway


    It's often useful to budget a prototype. But you still have to
    budget it---define how much it's going to cost, and what you
    expect to learn from it.

    > Well, unless you have a spiral project life cycle, in which
    > case you will be constantly redoing parts...


    That's pretty much the case everywhere.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 4, 2009
    #7
  8. Noah Roberts

    James Kanze Guest

    On Aug 4, 2:06 pm, Michael Doubez <> wrote:
    > On 4 août, 11:17, (Pascal J. Bourguignon)
    > wrote:


    [...]
    > As a junior, I've had to write documentation before code; it
    > was reviewed and signed by a peer, the manager and the QA
    > manager. It was not a perfect process and I can't say it
    > caught a lot of design issue but but I got a lot of value
    > from it from the design perspective.


    How was the review process carried out? I've found good reviews
    catch a lot of errors (but the manager and the QA manager are
    never part of the review team---that's not their role).

    Another thing which helps junior employees a lot is having them
    act as part of the review team. They may not catch many errors
    (although one never knows---one of the most difficult errors
    I've ever seen was found by a "stagiaire" (not sure of the
    English word)), but they sure do learn a lot that way. (A good
    review process helps at several different levels: it catches
    errors, of course, but it also ensures that the code is easily
    readable, it teaches less experienced programmers what is
    expected, and it helps build a consensus with regards to what is
    needed, and creates a community feeling.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 4, 2009
    #8
  9. On Aug 4, 1:22 pm, James Kanze <> wrote:

    > Or a coding process, or much of anything else.  This is
    > something beginning programmers have to learn, and they need
    > help learning it from the experienced programmers.  The problem
    > is that many experienced programmers (myself included) never
    > really learned it well, either.  In a commercial environment,
    > however, it's essential---good management has a nasty tendency
    > to want to know how much something is going to cost before they
    > approuve the budget for it.  (Stop and think about it: would you
    > sign a contract to have a house built, and to pay for it,
    > without any mention of the cost, or what the house will look
    > like when it's done?)


    Yes, but the problem is that software development is a creative
    process involving insight, it´s not a simply deductive process. My way
    of developing goes: My goal is a software that does this and that. My
    restriction is I must use C++ and this operating system. Ok, it´s
    possible, let´s go. As I focus on it I start thinking, "ok I need a
    form here". That´s an iteration. 'Now I need this", another iteration.
    I find it usually impossible to tell in advance how many iterations
    will it take. Think about it, before writing a book, would you be able
    to tell in advance how many sentences are you going to use ? I´ve seen
    problems occur when a manager divided a problem in chunks in which he
    thought his subordinates could do it in a one-only waterfall process
    (perhaps he could) and asked him to write the documentation for it. In
    the process, however, the guy needed a few other iterations which he
    hadn´t predicted, and had to add things that were not in the original
    document causing a little stress.

    Rafael
    Rafael Anschau, Aug 4, 2009
    #9
  10. On Aug 4, 1:28 pm, James Kanze <> wrote:

    > Another thing which helps junior employees a lot is having them
    > act as part of the review team.


    Very effective, but pride usually gets in the way.
    "Junior programmers reviewing *my code* ? How dare them!"

    Sad.

    Rafael
    Rafael Anschau, Aug 4, 2009
    #10
  11. On Aug 3, 12:07 pm, Noah Roberts <> wrote:
    > So I am walking by the desk and actually asking for more than, "Fine,"
    > now. I ask how it's going and try to actually get them to start showing
    > me some code if they have any. This has helped somewhat but some things
    > have slipped through still. Don't think it can be perfect.


    As you and your team gain experience with Early Review, you will
    become more efficient and effective. Over time less and less will
    slip through the combined dragnet of Early Review, Peer Review,
    and testing.

    > Second thing I've done is that I've asked for a plan before code. I
    > told them they can branch the code, play with the code, etc... but that
    > I want to see a plan before anything is done in the trunk. So far this
    > hasn't actually happened, must have been a miscommunication or
    > something. However, it's a weird change so I expect a little backlash.


    To make sure we are on the same page, is the "plan" you speak of
    above the Daily Plan or Clear Spec notion? Or something else? If
    it is the Daily Plan notion can you post an example Daily Plan
    from one of your team?

    > I hope that this second part will help me catch whether they understand
    > the problem, the code, and have a relatively decent solution before they
    > do a bunch of stuff I have to make them redo.


    Hmm, the above makes me thing the "plan" above is the Clear Spec
    notion; but, I'll wait for you to confirm. Have you implemented
    the Daily Plan yet?

    > What do you think?


    KHD
    Keith H Duggar, Aug 4, 2009
    #11
  12. Noah Roberts

    Noah Roberts Guest

    Keith H Duggar wrote:
    > On Aug 3, 12:07 pm, Noah Roberts <> wrote:


    >> Second thing I've done is that I've asked for a plan before code. I
    >> told them they can branch the code, play with the code, etc... but that
    >> I want to see a plan before anything is done in the trunk. So far this
    >> hasn't actually happened, must have been a miscommunication or
    >> something. However, it's a weird change so I expect a little backlash.

    >
    > To make sure we are on the same page, is the "plan" you speak of
    > above the Daily Plan or Clear Spec notion? Or something else? If
    > it is the Daily Plan notion can you post an example Daily Plan
    > from one of your team?
    >
    >> I hope that this second part will help me catch whether they understand
    >> the problem, the code, and have a relatively decent solution before they
    >> do a bunch of stuff I have to make them redo.

    >
    > Hmm, the above makes me thing the "plan" above is the Clear Spec
    > notion; but, I'll wait for you to confirm. Have you implemented
    > the Daily Plan yet?


    It's not a daily plan, I've asked for an overview of how they intend to
    address a particular problem once they've figured it out. Many of us
    may not work with up-front design but none of us works in a vacuum and
    just starts changing code willy-nilly. At some point you get an idea of
    what is going to be necessary to get the job done and it is there that
    I've asked to hear from them.

    I hope this will give me a chance to be involved in that process a bit.
    For example, had the one guy come to me and said he plans to just add
    all the logic for a new feature in a function within the 'document' I
    would have had a chance to explain why that's not such a great idea
    instead of later after it's done having to say, "This is not good." I
    am hoping that the process of talking about the planned approach will
    give me better mentoring opportunities and be a more positive feedback
    mechanism than having to tell someone they need to throw away everything
    they just did...and unfortunately I have felt the need to do this a
    couple times and no matter how well you word it...

    I also really think some of my team needs to start looking at the
    problem first rather than just code until it works. If I can get them
    to think about it more then I think I could also get better design and
    code from them. It's not like any of them are unintelligent or bad
    programmers, they just are too focused on code and don't have enough
    experience working with design to even consider what is going to cause
    problems later.
    Noah Roberts, Aug 4, 2009
    #12
  13. Noah, I know what you mean. Large projects need a well defined
    architecture in order
    to grow from a solid base, or else the software becomes an
    unmanageable mess. Do they
    know what the system´s main goal is, what the basic architecture or
    the system is, and how to grow from there on ? Because all of those
    imposes restrictions that they don´t seem to be getting.

    Rafael
    Rafael Anschau, Aug 4, 2009
    #13
  14. On 4 août, 18:28, James Kanze <> wrote:
    > On Aug 4, 2:06 pm, Michael Doubez <> wrote:
    >
    > > On 4 août, 11:17, (Pascal J. Bourguignon)
    > > wrote:

    >
    >     [...]
    >
    > > As a junior, I've had to write documentation before code; it
    > > was reviewed and signed by a peer, the manager and the QA
    > > manager. It was not a perfect process and I can't say it
    > > caught a lot of design issue but  but I got a lot of value
    > > from it from the design perspective.

    >
    > How was the review process carried out?


    The design document was passed around and improvement were done from
    comments and informal discussions.

    > I've found good reviews
    > catch a lot of errors (but the manager and the QA manager are
    > never part of the review team---that's not their role).


    It was creative work and part of the specs were functional specs. The
    CTO or the architect had to have a look into it in order to validate
    the strategy and the QA role ensured it was up to standard in the form
    and in the content (naming, glossary, reference ...).

    The main review was performed with the peer.

    > Another thing which helps junior employees a lot is having them
    > act as part of the review team.


    Yes. For the particular case I speak about, we were all junior. In
    practice, we shared a lot about our current work and everybody had a
    look to what others were up to which mean a lot of eyeballs had seen
    the design.

    > [snip]A good
    > review process helps at several different levels: it catches
    > errors, of course, but it also ensures that the code is easily
    > readable, it teaches less experienced programmers what is
    > expected, and it helps build a consensus with regards to what is
    > needed, and creates a community feeling.


    And IMO, also importantly, it allows to show up work and get feedback:
    the designer feel less alone knowing that somebody else appreciated
    his work and get opportunities to improve or to discuss in-depth a
    design decision.

    --
    Michael
    Michael Doubez, Aug 5, 2009
    #14
  15. Noah Roberts

    James Kanze Guest

    On Aug 4, 8:01 pm, Rafael Anschau <> wrote:
    > On Aug 4, 1:28 pm, James Kanze <> wrote:


    > > Another thing which helps junior employees a lot is having
    > > them act as part of the review team.


    > Very effective, but pride usually gets in the way. "Junior
    > programmers reviewing *my code* ? How dare them!"


    In that case, you have a serious problem. Code reviews haven't
    been introduced correctly, and will not be effective.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 5, 2009
    #15
  16. Noah Roberts

    James Kanze Guest

    On Aug 5, 9:03 am, Michael Doubez <> wrote:
    > On 4 août, 18:28, James Kanze <> wrote:
    > > [snip]A good
    > > review process helps at several different levels: it catches
    > > errors, of course, but it also ensures that the code is easily
    > > readable, it teaches less experienced programmers what is
    > > expected, and it helps build a consensus with regards to what is
    > > needed, and creates a community feeling.


    > And IMO, also importantly, it allows to show up work and get
    > feedback: the designer feel less alone knowing that somebody
    > else appreciated his work and get opportunities to improve or
    > to discuss in-depth a design decision.


    That "someone else appreciated his work" is really the key to
    good code review. When done correctly, programmers obtain a
    real sense of satisfaction ("Erfolgserlebnis"---one of those
    beautiful German compounds which simply aren't translatable) and
    pride when the review comments says things like "this is really
    well written" or "I had no problem understanding it". And end
    up writing code with this in mind, with the goal of obtaining
    such comments.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 5, 2009
    #16
  17. Noah Roberts

    James Kanze Guest

    On Aug 4, 7:58 pm, Rafael Anschau <> wrote:
    > On Aug 4, 1:22 pm, James Kanze <> wrote:


    > > Or a coding process, or much of anything else. This is
    > > something beginning programmers have to learn, and they need
    > > help learning it from the experienced programmers. The
    > > problem is that many experienced programmers (myself
    > > included) never really learned it well, either. In a
    > > commercial environment, however, it's essential---good
    > > management has a nasty tendency to want to know how much
    > > something is going to cost before they approuve the budget
    > > for it. (Stop and think about it: would you sign a contract
    > > to have a house built, and to pay for it, without any
    > > mention of the cost, or what the house will look like when
    > > it's done?)


    > Yes, but the problem is that software development is a
    > creative process involving insight, it´s not a simply
    > deductive process.


    So? Lot's of creative processes are subject to a budget.

    > My way of developing goes: My goal is a software that does
    > this and that. My restriction is I must use C++ and this
    > operating system. Ok, it´s possible, let´s go. As I focus on
    > it I start thinking, "ok I need a form here". That´s an
    > iteration. 'Now I need this", another iteration. I find it
    > usually impossible to tell in advance how many iterations will
    > it take.


    And yet, no responsible organization will let you even start
    without some sort of reasonable estimate.

    > Think about it, before writing a book, would you be able to
    > tell in advance how many sentences are you going to use?


    Not exactly, but editors are known to request specific word
    counts. And delays. Software isn't like a novel, it's more
    like a technical book, and these often have specific delivery
    dates, set in advance.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 5, 2009
    #17
  18. On Aug 5, 6:49 am, James Kanze <> wrote:

    > In that case, you have a serious problem.


    I don´t, the place I worked did.
    Rafael Anschau, Aug 5, 2009
    #18
  19. On Aug 5, 6:57 am, James Kanze <> wrote:

    >> I find it
    > > usually impossible to tell in advance how many iterations will
    > > it take.

    >
    > And yet, no responsible organization will let you even start
    > without some sort of reasonable estimate.


    Straw man. This was said in the context of conformance to plans, not
    with estimates. Even so, you know very well the there are usually
    unexpected issues in the middle of the process that make most projects
    say bye bye to deadline.

    Rafael
    Rafael Anschau, Aug 5, 2009
    #19
  20. On 4 août, 20:01, Rafael Anschau <> wrote:
    > On Aug 4, 1:28 pm, James Kanze <> wrote:
    >
    > > Another thing which helps junior employees a lot is having them
    > > act as part of the review team.

    >
    > Very effective, but pride usually gets in the way.
    > "Junior programmers reviewing *my code* ? How dare them!"


    You can reverse the comment:
    By looking at your code, juniors will have the opportunity to learn
    from you.

    If the junior is smart enough to ask question and not comment on the
    code. It should go well with any proud programmer.

    --
    Michael
    Michael Doubez, Aug 6, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    678
    Rosanne
    Oct 11, 2005
  2. George Hester

    Try over here likely more to the point here

    George Hester, Sep 30, 2004, in forum: Javascript
    Replies:
    0
    Views:
    110
    George Hester
    Sep 30, 2004
  3. FAQ server
    Replies:
    0
    Views:
    154
    FAQ server
    Aug 10, 2006
  4. FAQ server
    Replies:
    0
    Views:
    128
    FAQ server
    Oct 7, 2006
  5. mxbrunet
    Replies:
    1
    Views:
    210
Loading...

Share This Page