Tag Info

Hot answers tagged

145

In your case, as you're self-taught and already have what seems to be a good, healthy and no-BS approach to learning. Still some suggestions... Practice Makes Perfect I think you should dive into progamming exercises, like the: Project Euler, the classic 99 Prolog Puzzles (just as good for any language), TopCoder, Google Code Jam, and so forth. Even ...


144

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


107

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.


81

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.


64

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


61

I didn't have the if($n1 % $n2 == 0) method memorized. I haven't been coding for very long (started teaching myself SQL about 27 months ago and started coding in Perl about 20 months ago), but the quote above sounds like some things that I've heard from former students: How am I supposed to memorize which integration technique to use for every ...


59

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


51

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


41

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


36

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


34

Sounds like a scam, not a job. Nigerian job offer? heh. I have never worked at, nor know anyone who has worked at a place that would require something of the likes of that in the field of software development in over 12 years of experience from startups to gov't to edu to fortune top 20. Keep looking - it will only get worse.


34

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


33

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


31

Absolutely not. And IMHO it's a crazy policy. I can see the logic that the business doesn't want to get trapped in paying for training for staff who then leave. However, this generally happens in companies that under-pay staff - it should pay for the job someone will do, not for what they can do when they walk in the door. Two obvious consequences of this ...


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


27

You may think FizzBuzz is a toy problem; when will I ever need to use the modulus operator in a real program. But really you use it all the time. Three common examples: You are displaying a table and you want alternating background colors for different rows. You check if a row is even (row_number % 2 == 0) and display one color for even rows and one ...


23

Source Control: From my experience, colleges don't teach this well if at all. Unit Testing: Same as above (also reduces the amount of time they need to spend in a debugger) DRY/SRP/SOLID: Good, fundamental design techniques. DRY alone will help make them a better programmer, developer, and produce better quality code. IoC


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

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.


22

But I was stranded yesterday trying to figure out (not google) a solution for the FizzBuzz test because I didn't have the if($n1 % $n2 == 0) method memorized. Nobody memorizes that thing. You're supposed to come up with it on your own. If you know the modulus operator and you know what it does, then it's trivially a great fit to the FizzBuzz ...


22

First, don't panic. Imagine the worst that can happen. You try your hardest to understand the code base, can't get your head around it, tell your mentor, and he is disappointed and takes the responsibility away from you. But something good happened: you were honest about your limitations and didn't get in over your head and produce a bad product. That's ...


20

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


20

The problem is you are changing what the meaning of a branch is part way through the process. Initially, the v1 dev branch is for development. All new features go there. At some point in the future, it becomes a maintenance branch for the v1 release branch. This is the crux of the problem. Its not that the developers are sloppy, its that the permissions ...


20

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


19

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


18

No he shouldn't pay! You got it for free (according to your question). If your contract states he must pay back the costs, and the costs were zero. Then he should pay zero. Unless I've misunderstood the question and your company paid for the training but got a discount (certain amount of free seats) because you provided the venue. In which case I think it ...


18

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


18

Not every top programmer is a top teacher. I would recommend to make the training by somebody who can explain and who has an overview on the 'environment' of your company (technical things, but also organizational like contacts).


18

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



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