> None of these strategies work if you're not really an excellent contributor. If you don't write good code, and lots of it, you're just going to be resented for messing around with bug databases when you "should be" writing code. There's nothing more deadly to your career than having a reputation of being so concerned with process that you don't accomplish anything.
It took me a few years to learn this lesson. Every so often I have to re-learn it, when starting in a new environment.
Maybe I'm overreacting here, but if one of my coworkers set up their own bug-tracking system and used it to repeatedly nag me about bugs I hadn't fixed yet, it would probably convince me to write them off as a passive-aggressive whiner long before it would help me to "see the value of bug tracking". Why aren't they emailing me (personally) or asking me to fix it to my face instead, first?
Granted, Joel's flagship product is a bug tracker, so maybe that's part of it. It's hardly a flattering plug, though -- like the time I saw a pulp paperback in a used book store that had some sort of endorsement deal with HeftyTM trash bags.
Uff, does that work? You really don't have bug-tracking system, and instead of entering bugs there, you just use email or word of mouth? How do you track the whole process then?
> Nobody on your team wants to use source control? Create your own CVS repository
Oh for God's sake, stop! Create a git repository, a subversion resository, a darcs repository, but not a CVS repository.
[Edit] Also, I don't get this thing Americans seem to have for private offices. I guess cubicle farms are ugly, and if your co-workers are all annoying nerds being able to shut a door might be nice, but I've always preferred open, multi-desk offices where you can discuss things with the people around you.
Also, I don't get this thing Americans seem to have for private offices. I guess cubicle farms are ugly, and if your co-workers are all annoying nerds being able to shut a door might be nice, but I've always preferred open, multi-desk offices where you can discuss things with the people around you.
Joel has written at length about the need for programmers to have spaces where they cannot be interrupted, and from personal experience I agree wholeheartedly.
Here's the simple algebra. Let's say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we're really blowing away 15 minutes of productivity. For this example, lets put two programmers, Jeff and Mutt, in open cubicles next to each other in a standard Dilbert veal-fattening farm. Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).
Now let's move them into separate offices with walls and doors. Now when Mutt can't remember the name of that function, he could look it up, which still takes 30 seconds, or he could ask Jeff, which now takes 45 seconds and involves standing up (not an easy task given the average physical fitness of programmers!). So he looks it up. So now Mutt loses 30 seconds of productivity, but we save 15 minutes for Jeff.
In fairness to the article, it was written in 2001, before git or darcs existed, and while subversion development and awareness was still at an early stage. CVS was the reasonable free choice at that time.
I think an open plan is ok when everybody is doing the same kind of work (creation vs. communication). But I sit in a cube farm with half and half. I need silence to write code, but the guy next to me has to be on the phone most of the day to coordinate his world. Both of us can try to do our jobs, but we will interfere with each other.
> Strategy 6 Become Invaluable
> None of these strategies work if you're not really an excellent contributor. If you don't write good code, and lots of it, you're just going to be resented for messing around with bug databases when you "should be" writing code. There's nothing more deadly to your career than having a reputation of being so concerned with process that you don't accomplish anything.
It took me a few years to learn this lesson. Every so often I have to re-learn it, when starting in a new environment.