Hot answers tagged

149

I think the problem is the task: "I have been tasked with teaching other teams a new codebase". You have been given the wrong job, or maybe misinterpreted the job you've been given. By presenting at the code level, you invite code level thinking. Start at the system level and present the design and the design choices that were made. Don't allow extended ...


108

The specification is virtually never sufficient. Developers who do not have domain knowledge cannot point out when the specification is in error (a frequent occurence most places) and make poor design choices.


84

The key to becoming really good is working in a good team. Many amateurs work alone, so they only get that far. In a team, you learn from others, and you become disciplined because your peers will hit you with whatever comes handy otherwise. For that reason, I propose you join a team, e.g. an open source project, or make a hobby project with some friends.


65

"Park them". At the start of the lesson, explain what you are to discuss, and clearly explain what is considered Off Topic. If you are asked a question that is clearly OT, say so and move on. If they come back to it, write the question on a whiteboard (This is critical) for later discussion and move on. At the end of the lesson, when they are on their own ...


60

In my experience, having worked in 3 very different industries now, you can start out not knowing much about the domain, but you'll need to learn it eventually and someone will have to understand it to a detailed degree. The essential problem is down to the client-developer impedance: they want something but will only know it when they see it and you want ...


53

The road to become good at programming is the same as for singing or playing music: practice, practice, practice. If you spend enough time regularly developing software for several years, chances are you will become good at it - be it inside or outside working hours. Now, apart from spending more time practicing, there is another reason why professionals ...


43

You can look at this as either a as time in limbo; or you can turn it into an opportunity to grow. The core idea of being a maintenance developer is to put yourself out of a job. Each time you have to fix something; take the time to understand the problem well enough so that your solution (which could come a few weeks after you put out the fire) means you (...


42

Say "I'm a bit busy right now, you can ask on stackoverflow.com if you're really stuck." Eventually he will hopefully get the clue. Also, next time he comes to your desk say "Hmm I don't know, let's Google that and see..." or "Let's check the API docs." The combination of these two has worked for me with co-op students in the past - ...


39

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 ...


36

Many people won't like this idea, but I am advocating this wherever I can: regardless of the programming language and environment, if they don't have any experience and if there are maintenance tasks which come up from real world bug reports of customers of yours, try to make sure they get assigned to that kind of task at least for 30-40% (+) of their time. "...


35

In my experience, teaching programming did make me better. It forced me to get a much better understanding of concepts I had previously just accepted or taken for granted. When I had to articulate ideas that were old to me but new to students, in a number of different ways (because not everyone learns the same way from the same examples), it eventually led ...


30

An old University of Texas study made the following findings. People retain: 10 percent of what they read 20 percent of what they hear 30 percent of what they see 50 percent of what they see and hear 70 percent of what they do 90 percent of what they teach Following this logic the best way to LEARN something and retain what you have learned is to ...


23

You can teach them. Everyone does this in the beginning, even you. If this type of code makes it into production, it's the senior folks fault; not the junior. Edit: One of the things that I have done is I personally have taken to pro-actively asking people to review my code (including the juniors) before a release. The code gets reviewed, the junior ...


22

The good thing about learning C++ from C#, is that they look very similar. The bad thing is that they look very similar. You might feel I'm not making sense, but I'm trying to make a point. When I learned C++ coming from Java (I also know C#), I felt it was easy because their syntax are very alike, so that let me to made presumptions in which it made it ...


22

Much like is required on stackoverflow.com when questions are asked, say "show me what you have so far". If that is a big fat nothing, send him packing, with some hints on what to search for of course, until he has something concrete to ask about.


21

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 ...


21

Set expectations correctly and be honest, open and upfront. Make sure your goals are open and transparent. Start off discussions with the high level view as promoted by andy256 (+1) but also make sure that you include your objectives, e.g. "...as we look at this issue, lets make sure we don't focus on x, y and z. Let also make sure that we're not looking ...


20

I agree with others here that Maven seems to have taken over most significant projects that I've looked at. While Ant is highly flexible, the build file is not standardized, so when you move to a new project or company, the targets are named differently, the file is structured differently, the inter-target dependencies may or may not be established, etc. ...


19

Hack their code in front of their eyes then show them how to fix it. Over and over until they understand.


19

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 ...


18

But for an amateur programmer, how can train to become a good programmer? You become better by learning, which is part doing, part reflecting over what was done. So basically, theres no difference between hobbyist and professional, but the 'pitfalls' are arranged a little different. Amateur Pitfalls are, imho the need to finish your project, no matter ...


18

There's a difference between what we do as software engineers and what a violinist (or anything else that requires physical practice would do). A violinist spends hours practicing methodically because they are teaching their brain very specific patterns of how to interact with an instrument. Practicing software engineering also involves learning patterns. ...


18

Keep in mind that I don't have time to read several 1000-page tomes about abstract programming. So are you asking for someone to give you a five step check list that will make you a skilled programmer? That's not going to happen! As with any other discipline, if you want to get good at programming you have to spend time and effort practicing and ...


17

My advice would be to confront him about this particular example and see what he says. If he denies there being anything bad with the code, then I'm afraid there is little you can do. If he accepts that he made a mistake (even if he's defensive about it), then at least there is room for improvement. If you accept the time and effort on improving him, then ...


16

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 ...


16

Being a maintenance developer != being left on the bench. Maintenance dev work can be some of the most frustrating, painful and annoying work in the world as you fix the weird issues the original developer missed. It can also be some of the most rewarding, both personally and professionally, and educational work you can do. If you can take out a bug that's ...


16

So how do you educate other programmers enough that they stop fixating on trivialities and can meaningfully contribute to the design? First, don't think of their concerns as "trivialities" or "bikeshedding". Those are judgmental words, and they're insulting. Their concerns are valid. They're just not important at the moment. The key to any good meeting ...


15

Good question. Programmer on-the-job training is very rarely taken seriously, nor is it talked about often. Some ideas I've seen work well: In your wiki, have a new-hire rampup document (the one you're writing). In that document, describe teh tasks that the new hire will perform for the first 1-2 weeks. Where I work, there's loads to know from the get-go, ...


15

SOMEONE on the project needs to have fairly complete domain knowledge. That person may or may not be the developer. In Agile projects, the client project owner is that person, and they're working collaboratively and closely with the team. In non-Agile projects, somebody on the team needs to acquire that knowledge, but they usually don't, which is one reason ...



Only top voted, non community-wiki answers of a minimum length are eligible