SitePoint Sponsor

User Tag List

Results 1 to 20 of 20
  1. #1
    SitePoint Wizard mPeror's Avatar
    Join Date
    Mar 2005
    Location
    Saudi Arabia
    Posts
    1,724
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Exclamation How do I prepare someone else to work with me?

    Hi,

    My employer used to give me projects that I could handle alone. However, they've recently assigned me a project (that I've been working on for a while), that requires another developer to join the team.

    The developer is going to join us soon, and I have no idea how to prepare him to work with me. I've never work within a development team before.

    I obviously don't want to take him through every single detail of how I do things. And I don't want to keep fixing his bad code either.

    What am I supposed to do here since I'm in a leading position? any tips? I'm just hoping someone would point me to the right direction so I could research the details.


    Your help would be much appreciated

  2. #2
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There is no easy way out. Also it much depends on the other team player personality.

  3. #3
    SitePoint Wizard mPeror's Avatar
    Join Date
    Mar 2005
    Location
    Saudi Arabia
    Posts
    1,724
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I understand, but development teams usually set some standards to keep work organized and the quality of the code high, right?

  4. #4
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

  5. #5
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A few ideas that might help...

    1. Use frameworks to reduce the amount of code that needs to be written.
    2. Use an existing coding standard
    3. Use content revision management software like Subversion or GIT
    4. Use a project management tools to keep track of what is done and what needs to be done.
    Creativity knows no other restraint than the
    confines of a small mind.
    - Me
    Geekly Humor
    Oh baby! Check out the design patterns on that framework!

  6. #6
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    "Knowledge flows to he who knows", so the first thing is to relax, it doesn't matter how nervous you are, he/she will be twice as more nervous than you.

    Ask him/her questions to get the ball rolling, that'll relax the two of you.

    Coding standards is a good one to start with - and unless the arguments are utterly convicing he/she will have to adhere to yours from day one (and reviewed in a few weeks) then tackle source management (I'd guess).

    Then breakout and do some whiteboard stuff with arrows and blocks and circles, then don't be afraid to ask more questions "... but how would you have gone about it?".

    Done right this :
    shows you value their opinion
    shows their possible strengths and weaknesses
    generates new ideas
    works as a very valuable yardstick for what has gone before, fresh pair of eyes etc
    builds confidence, builds trust.

    Have some idea of a bite-size project or some refactoring you want done. After all if he/she breaks something important in the first week, that is solely your fault.

    See what issues those smaller tasks throw up.

    Be prepared to handle the fact he/she may be a better coder than you are, and make sure your brain is fully engaged to make the most of that fact and not lose a valuable opportunity to profit from that by being defensive and worst, hiding or obfuscating things in a protectionist way.

    Anyhow, weren't you in on the interviews?

  7. #7
    SitePoint Guru risoknop's Avatar
    Join Date
    Feb 2008
    Location
    end($world)
    Posts
    834
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just choose some good framework like Zend or Symfony. Make sure everybody in the team has read the whole documentation and understands framework's conventions.

    Also tell your developers to properly comment and indent their code so others will have it easier to pick up and continue.

    Finally, it is a good idea to divide tasks between developers. It's not a good idea to let everyone work on everything. Somehow divide the responsibility into smaller chunks. For example, say you have 4 developers.

    One can work on schema, models and all other stuff related with the database. Another one can work on the business logic, controllers, actions etc. Thirdly, a more experienced developer might be an "advisor" - his objective would be to act as a sort of supervision over the project, he would have to make sure the developers are writing quality and maintainable code, help them if there were any problems. Finally, a web designer who would take care of stylesheets, templates, use of proper tags, semantics, SEO etc.

    You get the idea - divide the work into smaller yet consistent parts so every developer can fully concentrate on his part of the project. This is where team communication is crucial. Make sure you that team members are able to communicate together smoothly and update each other about the progress they have made.

    Just my two cents.

  8. #8
    SitePoint Wizard mPeror's Avatar
    Join Date
    Mar 2005
    Location
    Saudi Arabia
    Posts
    1,724
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    elias:
    Thanks, even though they're not directly helpful.

    imaginethis:
    I already have 1 and 3 covered. I'll check 2 and 4. Thanks.

    Cups:
    Thanks for your valuable input. And regarding your question: Unfortunately the guy was hired because he's related to one of the company's executives, not because he was competent.

    risoknop:
    I don't have a documentation besides the comments within my code. Would that do it?

    And thanks for your advice, that was very helpful.


    If anyone else has more tips, I'd really appreciate it.

  9. #9
    Use The Cloud
    Join Date
    Jan 2006
    Location
    Boise, ID
    Posts
    556
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mPeror View Post
    I don't have a documentation besides the comments within my code. Would that do it?
    Documentation in your code is usually more than good enough. You should probably setup a cron job to generate some HTML docs so you don't always have to go digging.

    This is trivial though if your documentation is sufficient.

    http://www.phpdoc.org/
    Brad Hanson, Web Applications & Scalability Specialist
    ► Is your website outgrowing its current hosting solution?
    ► PM me for a FREE scalability consult!
    ► USA Based: Available by Phone, Skype, AIM, and E-mail.

  10. #10
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,832
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Whatever standards you adopt there are going to be situations that arise that are either not covered by the standards or where there are reasons for making an exception. For situations not covered you need as a group to decide on an appropriate standard to cover the situation and document it so as to apply it to future instances. For an exception you need to agree that it is actually an exception and then document in the code itself as to why it is an exception to the regular standards.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  11. #11
    Coding and Breathing CoderMaya's Avatar
    Join Date
    Feb 2008
    Location
    Atlit, Israel
    Posts
    470
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The best way is a training phase. You could write a simple guide that would explain the way you like to work, and be next to him to answer questions while you keep working. In a matter of a few days, hopefully, he could join and help you work.
    Learn about the new Retro Framework
    Code PHP the way it was meant to be coded!

  12. #12
    SitePoint Member
    Join Date
    Jan 2009
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mPeror View Post
    Cups:
    Thanks for your valuable input. And regarding your question: Unfortunately the guy was hired because he's related to one of the company's executives, not because he was competent.
    Ouch. Hopefully he isn't INcompetent.

    I'd definitely have a sit down with him before any coding is done and set out how things will be done. Since you're in the lead, decide how workflow will be done. I also agree with the above that you'll want some project management software. I use basecamp with clients which works very well, but there are plenty out there.

    Start him off doing easy, grunt type work. Handle the really important, lower layers yourself, and let him do things that aren't quite as critical.

    You never know, he might turn out to be a great coder and you'll wonder how you got along without the help
    Adrian
    Need help on your next project? Hire me

  13. #13
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by mPeror View Post
    The developer is going to join us soon, and I have no idea how to prepare him to work with me. I've never work within a development team before.
    It's difficult to answer this without knowing your environment. The risks are different for a public facing web server or accounts database server than say an intranet app.

    Also, what are your current coding practices? Version control? Unit testing? Acceptance testing?

    What's the code like? Homebrew framework? Hacked together so only you could figure out how it works? OO?

    One practice that I would definitely recommend in this situation is pair programming. Just share a computer for a bit (alternate between theirs and yours) and do whatever work is imminent. You'll soon work out a mutual coding style. You'll also discover what they are good at. Building a team requires mutual respect.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  14. #14
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Plano
    Posts
    643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    well it seems like everything i was going to mention has already been mentioned but i'll emphasize some points i feel are pretty important.

    coding standards / conventions. make it clear how you expect the code to look. if you use an IDE, phpdoc comments are amazing as they allow you to type hint as well as take advantage of auto-completion.

    svn is also a powerful tool. there are scripts that allow you to review any code checked in before it actually gets committed to the repository...for the first few weeks this can give you a greater perspective on his coding skills.

    lastly--and this is something i am guilty of quite often--don't be negative towards his work. keep an open mind that he is a great coder but just has some of his own coding techniques. just because they are different than yours doesn't make them wrong. laying out your preferred coding conventions up front will help keep this from happening most of the time but there will always be cases where someone else on the team does something that you would have done differently.

  15. #15
    SitePoint Addict
    Join Date
    Nov 2005
    Location
    Germany
    Posts
    235
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I agree. We usually do some pair programming. Something less complex like an easy view will give the new developer an overview of your framework, standards and tools.

  16. #16
    SitePoint Wizard mPeror's Avatar
    Join Date
    Mar 2005
    Location
    Saudi Arabia
    Posts
    1,724
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sorry for the late response guys. I posted one a few days ago, but apparently it didn't go through.

    Thanks everyone for your input, I really appreciate it.

    Quote Originally Posted by lastcraft
    Also, what are your current coding practices? Version control? Unit testing? Acceptance testing?

    What's the code like? Homebrew framework? Hacked together so only you could figure out how it works? OO?
    - I do have coding practices. Not a standard though. I'll probably write them all down for the new developer to read.

    - I use version control, but not unit testing nor acceptance testing. I'll look into those. Thanks.

    - For the framework, I'm using CodeIgniter. So that's covered.

    svn is also a powerful tool. there are scripts that allow you to review any code checked in before it actually gets committed to the repository.
    For Windows or just linux? I'm using TortoiseSVN as my SVN client if that matters.

  17. #17
    SitePoint Addict ruby-lang's Avatar
    Join Date
    Aug 2007
    Posts
    389
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The best way to introduce a new developer to a codebase is to give him a relatively simple task, preferably something that has been in your todo list for some time, and for which you don't have a firm deadline. As an example, you could ask him to go through the code and make sure all input is properly sanitized; a task like this has the bonus of forcing him to skim a lot of the codebase and start assimilating your style.

    Your fledgeling will have lots of questions at first; don't let him feel unwelcome, or he may clam up and cause a lot of headaches with assumptions -- making asses of both of you.

    If you decide you have to document stuff to help the new hire, concentrate on the why; the what and the how should be evident in your code.

  18. #18
    SitePoint Wizard mPeror's Avatar
    Join Date
    Mar 2005
    Location
    Saudi Arabia
    Posts
    1,724
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Very wise advice ruby-lang. Thanks a lot.

  19. #19
    SitePoint Evangelist
    Join Date
    Aug 2005
    Location
    Winnipeg
    Posts
    498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is where effectively compartmentalized code comes in really handy.

    If you have at least followed MVC you could start the individual off with models, eventually move into views and then controllers or whatever order you find most effective.
    The only constant in software is change itself

  20. #20
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by mPeror View Post
    - I do have coding practices. Not a standard though. I'll probably write them all down for the new developer to read.
    Make it minimal. Only put in stuff you definitely want done your way and have reasons to back it up. You have to grow standards together. They are a team thing.

    Quote Originally Posted by mPeror View Post
    - I use version control, but not unit testing nor acceptance testing. I'll look into those. Thanks.
    Unit testing would help a lot if you have to refactor a mess. Without it, code quality becomes a matter of life and death.

    You must pair if you don't unit test, and you must code a little slower than usual so that you can discuss code quality and play around a little. Ideally you do this alongside unit testing anyway, but it will be essential if you don't.

    Acceptance testing helps you document requirements in a very precise way. You should both attend requirements meetings anyway (they are not a substitute for communication). Developers often try to design the system in their head during the meeting. This is a good thing, as it exercises the requirements with the stakeholder in the same room. A side effect is that the developer documents their design, not the requirements. Besides being more error prone, it hamstrings the other developer to a design that they probably would not have done. Acceptance tests force a more literal recording of what's wanted.

    Do design sessions at the whiteboard until you are comfortable working together. It will force you to talk through scenarios and communicate teh design, rather than one person typing and the other's eyes glazing over.

    Quote Originally Posted by mPeror View Post
    For Windows or just linux? I'm using TortoiseSVN as my SVN client if that matters.
    You'll need tools you can pair with. Decide on these together and try out several. Install a complete set on both machines, so you can hop seamlessly between them.

    yours, Marcus
    Last edited by lastcraft; Jan 12, 2009 at 17:24.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •