To continue from an earlier post on the WACD methodology, here are some tips for keeping the pesky 'team' concept from eroding your development sovereignty.
First off, developing applications in teams runs the risk of contaminating your line of thinking with inferior logic. The fewer people on your team (ideally, just you), the more freedom you'll have to solve problems the right way.
Sure, developing in isolation may lead to duplication of efforts in your IT organization but that's OK - IT organizations are full of redundant waist and it's not your job to fix it. Besides your solution will undoubtedly be superior to your look-a-likes. Everyone will benefit by learning from your example.
Development teams like to second guess each other by doing code reviews. This is just a crutch for weak developers with no guts. Be smart and write the code perfectly to begin with. As you already know, writing near-perfect code eliminates the supposed benefit of second-guessing weasels.
In the rare case where factors beyond your control caused you to write a bug, you'll be the only one who'll understand it. Not only is this is great for your job security but it ensures a peaceful debugging process where you're not constantly being asked questions that begin with "Why did you... blah, blah, blah." So friggin annoying.
Last but not least, teams often talk of 'camaraderie' and 'morale.' My advice here is simple: Camaraderie is for commies, morale for pussies. Don't be either. Clint Eastwood didn't ride into town with a Cowboy Support Group and neither should you.
Recent Comments