They're Doing it Wrong
Firefighters – Are called in when a project spins into a runaway or fires rage out of control in Production. They are highly skilled, very driven and goal oriented. They are there to fix a problem and do so in short order. They don't answer to you they answer to the stakeholder or your boss's boss's boss, and therefore they often care little about the resulting code. Much like a real firefighter will destroy your house with the fire hose to put out the fire in the kitchen. But hey, it’s not on fire anymore, right.
Pitbulls – Can range from non-technical to very technical. The determining criterion is their incessant need to be an ass. They almost never admit when they are wrong, especially in the face of overwhelming evidence. They are agitators used to force a stakeholder’s desires on the project. They are passive aggressive and Roosters. If a pitbull is the product owner the project will fail. The only way to handle a pit is to not step in the ring, but rather deal directly with the stakeholder holding the leash. They are unhappy about something or feel powerless, that is why they aquired a pitbull. Resolve that problem and the pitbull problem will resolve itself.
Architects – Talk a lot. No really A LOT. The rule is if you can get an architect to stop talking, then they aren’t really an architect. Be wary of the ones with charisma and technical skill. They are very dangerous. Where architects tread, ivory grows: this is their job. Regardless of any other consideration get to know your architect. You can learn a lot from just sitting and listening, just don't make them 100% of your information base. It is when an Architect stops practicing the craft of code writing that they become dangerous.
Skillz
Ability to QA a system
This facilitates the developer being able to catch and resolve issues before they become problems.
Write Effective Unit Tests
There is nothing I know of that enforces good Object Oriented design more potently than Unit Tests. It's not about a specific unit testing program because being able to create unit tests is a fundamental skill. It is a skill that translates across all programs and methodologies. Creating good unit tests is a science, and like any science can be perfected with enough experience and practice. The first thing people find when starting to write unit tests for the first time is that their code is not unit testable. They thought they were object oriented design masters and find that they’re doing it wrong. Unit tests flush out this misconception and force good object oriented design. Raw experience writing unit tests is required before quality code coverage is achieved. I would like to see students write unit tests in the major software project courses and give them this experience, as well as force the code into good OO design.
For more information:
http://en.wikipedia.org/wiki/Unit_test
http://en.wikipedia.org/wiki/Test-driven_development (TDD)
Refactoring
If you work your entire career creating new software for clients that don’t change requirements then you are the one, because no one else gets to. You will have to maintain a code base or adopt a code base or have to modify a code base. Refactoring skill is required; otherwise you’re just fumbling around hoping your changes work out, relying solely on your QA department to catch problems before the client does.
Refactoring is key to the new agile implementations, but again, more importantly the ability to transform existing code into unit testable, object oriented, patterned code is key to a successful career as well as being a chief tenant of any agile implementation. Being able to architect a great pattern-rich, mature solution and code it from the ground up is great. It’s still not simple to do, but when done right is a beautiful thing. More likely than not though you aren’t given that opportunity. You are given an existing code base and are asked to make changes. This can be in the form of a rotten code base written years ago, to an existing code base that is part of an active scrum sprint whose requirements were changed at the end of the last sprint. Either way being a code alchemist, being able to transform existing good or rotten code into the appropriate code is a huge skill. It’s also a fundamental skill that permeates through languages, frameworks and platforms. If this skill was focused on you would see the code that people adopt improve in quality, not just being retro fit in any way possible for the immediate need.
For more information:
Refactoring, Martin Fower, 1999.
Design Patterns
So many fields have achieved greatness today because they build upon the lessons learned in the past. For the vast majority of the Computer Science and software development field we restart from scratch every time. There is little growth. We have many of the same problems today that people in the 70s and 80s had. Design patterns facilitate mature initial design and simple/reliable extendibility later among so many other things. This is a key part to all the new agile implementations, but more importantly this is key to growth of the field, and growth in the field. For those looking for shoulders to stand on, here they are. These patterns reflect over 30 years of design refinement and extension. Software developers are foolish not to implement them. That is assuming they know Design Patterns for software development exist. That’s one of the problems, many are not aware of design patterns. Identifying patterns in use in code they are to maintain, identifying when to apply patterns to a new design, and identifying which pattern to refactor to are all difficult skills to master.
For more information:
Head First Design Patterns, Freeman, Sierra, Bates, 2004.
http://www.dofactory.com/Patterns/Patterns.aspx
Performance Testing
If there is a bottle neck, it has to be found before it can be fixed. There is a skill involved in finding the problem and a whole different skill set involved in improving performance.