Tag Info

Give him the chance to shine I've actually had a very similar position for some time but now I think I'm making some progress with the developer. I think in the end it will only be a case of commit shyness but I just told him "I need you to commit and push to the server so I can help you better if you get stuck, and you can help me better to oversee the ...

Some hints: Learn other languages. Then compare them to the language(s) you already know, and try to look at the ways you can improve your coding skills in those languages by using things you learnt from other languages. "Free your mind" before learning those new languages, and don't try to simply clone the concepts of one into another. Read code. I don't ...

Anywhere from 0 to 5 or 7 (or so). Arguments for the low side: Not everyone is set out to be a mentor. I have worked with some developers who were so gruff that they would have scared someone into a new career. If you expect the senior devs to maintain the same level of output, then keep the number low. Arguments for a higher amount: Some devs ...

I had an experience like this with a junior programmer. I'll give you the anecdote, along with the obvious warning that what worked for her wouldn't necessarily work for anyone else. Her problem was that she had never had to deal with anything in college that wasn't a toy system you could reasonably be asked to do in a homework set. And so when she faced ...

In my experience (and this is a gross generalization with tons of exceptions), older developers tend to believe in a seniority-based chain of command. "I've been here for 10-years longer than you so you'll do what I say." Younger developers tend to be more egalitarian. They acknowledge that each person has a unique set of strengths and weaknesses, but for ...

If at all possible, give them real work to do. If they're really enthusiastic, nothing will kill that enthusiasm faster than being given some clean-up work or put on a toy project. I've also observed that most of our junior developers seem most excited about working on the UI part of the project. Probably because they've always worked with a computer ...

Having a mentor is very important. Experience is irreplaceable and getting the advice and ideas from someone experienced will help you be a better developer and a productive professional. Coding is usually half the battle, you have to know how to communicate effectively, lead meetings, etc. This is where a mentor can help you guide. Your mentor(s) does not ...

No more than two per senior developer if you are hiring people straight out of college. The recent college grads I've had to deal with in the past have a good understanding of the basics, but they had no idea what it was like to program in the business world. You will you have to spend time teaching them how to program professionally, it is quite a shock ...

I'm reiterating some of the things that have been said already but I have two views. Business: As a business, you want productivity and lower risks. Although senior developers are doing the bulk of the work, you want them to transfer their knowledge of the system down which lowers risk. Productivity wouldn't be affected that much because you need to give ...

I had this situation at a previous company. The senior developers, which were only a few, were mentoring an increasing number of junior developers to the point where they could not do the other tasks assigned to them. After a while the senior developers brought it up with our manager and it was decided that the developers who were somewhere in between junior ...

Look at this from another angle. What kinds of skills and knowledge are you wanting to have transferred amongst the programmers here? If the senior programmers are doing most of the real, important work doesn't this maintain a bit of isolation in terms of who knows which system? Getting the juniors in to know the system so that they can be backups for the ...

Depending on where he went to school he may not have more than a few months experience doing very trivial things in one language. That can be fixed, but make certain it is worth the effort. It sounds like you need to tell if he can be salvaged or not. put the code away for a little while explain a small to medium sized problem that exists in the project ...

DO Give them work in small chunks at first, then increase; Let them be a real member of the team: code reviews are great, blocking the SCM is not they have to be part of team events (keep in mind their finances may be a bit weaker, so throw them a bone gracefully every once in a while) they have an equal right to talk at meeting (and urge them to) or do ...

Start giving her small projects with well-laid out requirements, and don't hold her hand through the process. See how she does. At the end of it ask yourself, Is her project working? Was her project done in a timely fashion? Was her work easy to understand? Was her work easy to maintain? If the answers are yes, then she is doing great. She might need to ...

When I started, I didn't have a mentor as such. I was assigned to a guy who would leave the place in three months and told to pick his brains to learn as much as I could. What have I learned? Working in a place without any knowledge management strategies sucks. Since then I've been assigned a bunch of interns / trainees / new people and told to mentor them. ...

It's largely just par for the course for experience programming, and is one of the key reasons why programmers need quiet space and uninterrupted time to work. Simply put, you need to learn to keep quite a few different things in "working memory" in your mind. There are aids you can use, though. Task comments. Any editor or IDE can parse (or has a plugin ...

Find out more about his background and what he is familiar with. If he has a computer science degree, presumably he has done some coding (maybe not Javascript though). Whatever language he is familiar with, see if you can explain problems/solutions in terms of that language. If he can see the similarities, maybe things will start to click. People learn ...

Developers who don't fundamentally understand the code usually make blatant mistakes belying it, whether they are copy/paste/modifying or not. For example, people that don't fundamentally understand pointer code will add random references or dereferences that make the code compile, but otherwise make absolutely no sense. People who don't fundamentally ...

If you have a lot of juniors coming in, let's say >30, it might be worth it to dedicate a senior developer to mentoring them full time. At my first job they hired about that many of us fresh out of college and had a dedicated team member helping us learn the ropes for the first 6 months. It made the transition a lot easier and he taught us a lot. Not only ...

My main solutions to that over the past 2 years have been: networking socially: I have particularly found that meetup.com is a great way to find programming groups in your area. Twitter is also great for this. When you find people you like and respect, follow them. Using http://www.stackoverflow.com I initially used it for occasional questions. Now it ...

I'm going to go back and think about coming out of college as an undergrad and compare it to graduate school. The relationship with professors changes. Undergrads are treated as sponges. The professor is in front of a usually larger class and gives dictation. This is not the relationship you want with your interns. In graduate school, the classes are ...

Simple answer: the person who does the training should be the person who is best at training who also wants to do training. Some people enjoy training and mentoring. Some people hate it. You don't want people doing things they hate - it's bad for them, it's likely bad for the person being trained, and it's probably bad for the whole team. It doesn't add ...

Well if the senior programmers in the team don't really master their trade more than the juniors, only have been around longer and/or have a higher social/political status within the team, then indeed it doesn't really make a big difference who - if anyone - mentors the newcomers. Chances are, they will all gravitate towards the same level of mediocrity ...

Tough one. Unfortunately, some people get through their programming courses by the skin of their teeth, and often on the help (and code) of others, so it is inevitable that someone comes straight out of college without having the first clue as to where to begin. (I could go on and blame the educational system a bit, here, as I think there is the tendency to ...

it he's incompetent, do not protect him - you're doing your client no favors by stringing along someone who cannot perform sorry to be harsh, but that's business; not everyone with a degree makes a good programmer that said, if you want to help him improve suggest that he participate in code katas, join a local user group, try coding competitions, and in ...

Four experienced programmers can probably put an outline of everything you need to know, but they may miss some of the steps to learn it or may take knowing basic concepts for granted. You least experienced member may have a better recollection of her training. Start with an intern and do a short run. Then reevaluate the program and put something together ...

I don't think trainee programs are common in many countries, but are such a really good idea if you have the company's commitment behind such an investment (an investment of the time of the other developers and internal resources, plus the investment in the people you're selecting to train up). As to what to focus on, of course that depends on the ...

The short version: Should interns have a mentor? Yes Should junior devs have a mentor? Probably The long version: Mentors should exist, but they are like the people on SO. They should not be used as a primary resource, but rather as a safety net when you can't google whatever it is you are banging your head against. Examples: Some very specific ...

Just because I'm reading quite a bit of hierarchy in(to) your question: Learn from the people under you. Software development is about communication, between humans, often through the medium of code. Since good communication should go both ways, learn from the people you program with. (my assumption is that you're not at a 1-man company)