Need some advice on 'social' stuff and getting up to speed
-
Hey all. I've followed the site for, oh jeeze, awhile now, but never felt compelled to post. That said, it looks like a pretty awesome place to frequent, so here goes:
I'm a coop student (like an intern, but paid) who just got employed by $company. Now, $company wants me to work on a project that a team of four other coop students from my school have been banging on for awhile. It's actually fairly functional - basically a streamlined way for airports to do inspections. The inspectors don't have to carry around a clipboard with all those nasty sheets of paper, just a tablet PC running the client. Looks kinda neat; that's not the part that I need help with.
My perceived problems are twofold. First, I need to get up to speed in the project before everyone on the previous dev team goes back to school. I've got until Friday, and if I weren't starting unexpectedly early (read: during most peoples' spring break), I would have no time whatsoever to talk to them. I've gotten a list of tasks to work on before the next deadline. What questions should I be asking?
Second, as mentioned, the dev team is composed entirely of coop students. This means that they've learned as they've gone; okay, fine, I did the same thing at my last coop job. Mistakes are how you learn, and believe me, I created some horrible, horrible turds while I was getting my feet under me. Anyway, having been down the path of madness and repented (Rands and Joel are handy folk, if you're not in a position to critique their ideas), I'm interested in avoiding that situation again. It's a Microsoft shop, so they use Visual Studio; they've got a Visual SourceSafe server set up somewhere, although I'm not at all sure they know what version control means. To the best of my knowledge:
- there is no spec
- there is no bug tracking
- there is no build process
Oh, and I'm on a borrowed machine with stuff personalized for the previous user, who is now positioned right across from me in the developer "combined office".
My trouble is that, to my way of thinking, I need the previous team around in order to get used to the existing code. At the same time, though. I need to be getting some decent practices in place so that I don't go strak raving mad while trying to get work done. My questions are these: a) howshould I balance these two goals, and b)being socially inept, how do I go about improving things without pissing off the dev team and my manager?
Thanks in advance.
-
I'd suggest plugging all your CAT5 cables into the first 220 volt industrial outlet you can find. If you survive the shock I'd suggest writing a design spec even if its a one page google document.
-
There's no perfect solution here. You simply don't have enough time to truly know the system before you're on your own, and you have no specs or bug reports to start with. Still, you really don't need to be familiar with all of the code. The most important parts are probably the data storage system, and the business logic. Find out where they are and dive in. When you reach a part that doesn't make sense, you'll have a starting point for picking their brains. The key is probably to understand how they thought about the program, because that'll reveal as much about the program as a cursory glance at the code will.
-
As to jumping in with both feet, get used to that. Sadly, I think that's the way most companies work. They hire you fresh and let you screw up until you figure it out. The better companies don't fire you for your screwups, the worse ones do. I don't like that, but in my 20-year career to date, I've never worked for a company that offered a training/get-your-feet-wet period.
As to the bug tracking and code management, that can be political which I think you sense. If your management is good but just a little clueless you can demonstrate how things should work and they'll let you volunteer to implement it, and will then help you enforce it. If your management is simply lazy like mine, they will let you try but won't back you up on enforcing the use of such tools. For example, we have two bug-tracking systems that don't talk to each other. The one that my group uses primarily has a half-empty code database so we can barely even enter problem logs correctly. And nobody makes us either enter them descriptively nor makes us follow up on them, so the information in the system is completely useless for anything other than to say that we use it. We can point to the log number and say there it is. We can't search for similar problems or solutions because it's just garbage. Management could care less. In this kind of situation the only solution is to - well, fix management...
