Tag Info

New answers tagged

0

All 3 ways look good to me. Actually trying 10 different agile ways at the same time should give you good results soon, at least you'll know which way works and which one does not (which one will work best depends a lot on the personalities of the players). The pair programming problem will not occur if you stick to the process with the typing/thinking hats ...


1

I think it depends on which area you want that junior developer to improve. When I was (very) junior they used to give me API's that I need to build one particular confined thing, such as: this function gives N number of personnels from Personnel table this function provides personnel statistics given the personnel's id -> Task: build a page with a list ...


12

I recommend the following guidelines: Involve the junior developer in your design meetings and solicit his input. This will get him thinking about the big picture, even if he is not ready to do the high-level design himself. Try to isolate and clearly define a module of the application to assign to the junior developer. Describe in writing what the ...


5

Often the previous person left because it was such a mess. You don't mention how big the code base is, or how quickly you are expected to produce results. People generally have one of three ways of understanding something new get the big picture overview, then fill in the details, get a general idea of the thing, then "spiral" out to get all the ...


6

Find out the information you need. Everything is fair game: code, debugger, test, users of the system, logs... Tell your boss what particular information you're missing - they might be able to help - or not. If they're good they'll realize it will take time and value the understanding of the system you're acquiring. Your job as a developer is to change ...


1

I've been there too. Sometimes you just have to spend a few weeks chasing rabbit trails through someone else's spaghetti code until you finally understand it. In one of my previous jobs, there was often a clear original plan, but then the maintenance staff piled on lots of uncommented band-aids over the years until it became such an unworkable mess that ...


4

I wouldn't call it "normal" because that implies that it's typical or expected, but yes, this not at all uncommon. In an ideal situation, management would ensure that all software is well-documented and would make sure to cross-train enough people on the software so that it's very unlikely all the knowledge will walk out the door. But that will translate to ...



Top 50 recent answers are included