Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Here's some background:

  • I have someone who is motivated to help me out on a project that already has a good chunk of code written
  • The person does not have a CS background, but knows the basics (functions, variables, objects, classes, etc)
  • The goal isn't to make this person a rockstar developer overnight - they just need to be able to pull their weight on this specific project.
  • The project is a Rails project, but if there are general responses, I'd like to favor them.

The current approach that is being taken is to give this person a simple feature (that has a similar feature already written). Then nudging them when they get confused, while trying not to give them full chunks of code.

Regardless, they're very confused and frustrated, and moving slowly. Not unexpected, but I'm wondering if there are any tips or tricks to help them learn more effectively, and get to the wonderful "ah-ha!" moments.

share|improve this question

migrated from stackoverflow.com Aug 14 '11 at 20:58

This question came from our site for professional and enthusiast programmers.

    
Possible duplicate - programmers.stackexchange.com/questions/22165/… –  ChrisF Aug 14 '11 at 21:15
add comment

3 Answers

up vote 2 down vote accepted

I think the most important thing you can do is show them how to fix their own problems. There are so many threads on this site about interns or new workers or someone of that stature asking for help over every little issue. You also see the other side about young developers who just toil through and waste so much time because they refuse to ask for help.

The best way to help him is to show him resources. Tell him how you solve your problems. Talk about stack overflow, how to search google effectively, printf debugging, and stuff like that. Tell him that when he has an issue, he should basically go down this checklist and try to figure out what's going wrong and see if he can fix it, BUT that he shouldn't spend too much time on something potentially trivial. When he does come for help, make him tell you what all he's tried, what he figured out, and guide him from there.

When I was first starting programming, I learned a ton by trying to fix my errors. That's because oftentimes I'd try to fix "x" when my problem was really "y", but in the process I'd learn about both x and y. In the future, if I saw problems related to x or y, then I'd know where to go back to dig deeper. You pick up a lot just by reading, and by searching for answers, you can pick up what's wrong.

Just to reiterate an earlier point, show him how to use a debugger, or at least how to go through his code. To quote Alan Perlis:

To understand a program you must become both the machine and the program.

A lot of new programmers just stare at code trying to get an epiphany (turns out people try to solve a lot of problems this way), but that's unnecessary with the tools we have at our disposal. Tell him about how you read through a program and "imagine" it working, and help him think through his code. Show him how to either use a debugger, or how to insert print statements to confirm his understanding.

That'll put him way ahead of the curve. The rest will come with his own efforts.

share|improve this answer
add comment

When we are introducing people to work on new areas in our software, we are usually doing some pair programming with a programmer, that has deeper knowledge in this particular field. (of course you would have to have the resources for that). This helps people to faster understand existing code.

share|improve this answer
add comment

When I started programming with Rails, not knowing the language, the framework or too much about web development, I had around two or three weeks on my own to explore all of this to some extend. I used the time mostly to develop a very simple web shop. This gave me the opportunity to get a good overview of the whole framework and experiment with the single elements like routing, models, views, validations, tests, ajax, layouts, partials and so on, without the risk to break anything. After this time I had at least seen each part and new very well, where it would fit into the whole system, what to expect from a Rails project and where to look for certain functionality. Of course I didn't know everything but I knew how to ask smart questions and was able to get a small prototype project successfully to a customer without bothering my new team mates with too many stupid ideas.

In my humble opinion Rails works as a whole. Trying to start working in a single area without knowing the connections won't work and he will lose time. Let him have at least one or two weeks to explore the framework without doing any serious work on an existing project. I was working on my own, I guess if he has some experienced people around him to ask questions and who can point out important concepts, he should be able to get into this fast enough.

Having a few good books available like those by David H. Black won't hurt either.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.