The development team has recently relinquished our individual offices in favor of a team room where we are all working together. At first, I was skeptical that I would be able to keep a high level of productivity with the distractions that a team room, by its very nature, creates. I couldn’t have been more wrong. We quickly meshed as a team and have become noticeably more productive. (You can see the slope change on our burndown; it is dramatic!)
One of the side-effects of working in a big room with the rest of the team is that I’ve started to notice the different development and personality styles of the different members. I’ve come up with several different general categories. Some people cross these boundaries, depending on the situation.
Development Styles
The Architect
The Architect has become the de facto leader of the team. In many ways, he drives the decisions that are made regarding the architecture of the new features being built, as well as the refactoring of the existing code base. He also decides the conventions that the rest of the developers use, often by setting the example for others to follow. The Architect is a by-the-book best practices kind of person, with a strong understanding of the fundamentals.
The Architect’s code tends to be very structured, and follows all of the best development principals. Sometimes, though, he may tend to over-engineer a bit in the interest of following the principals to the letter, and he spends a lot of time working on things that may not directly affect the timely completion of the project at hand. A strong member of the team, he is naturally a mentor and encourages others to produce good, maintainable code.
The Artist
The Artist tries to make his code as elegant and flexible as possible given the constraints of the code and the requirements. He has a strong grasp of the fundamentals, but doesn’t adhere as strongly to “the book” as the Architect might. The Artist seeks readability and self-documentation, and may neglect to appropriately comment his code except in extreme circumstances, or when particularly proud of a solution. Artists are generally strong programming enthusiasts. The Artist needs to watch out for “overly elegant” solutions — those that work correctly, but are difficult for others to understand. This can create risk if somebody else needs to make a change and mistakenly breaks things in unforeseen ways.
In many ways, the Artist and the Architect are similar. Like the Architect, the Artist produces good, maintainable code, and can be looked towards as a mentor. The major difference is the Artist’s willingness to break the rules at times for the sake of the elegance of the code. Both the Architect and the Artist thrive in greenfield environments, and tend to find excitement in the process of designing and implementing new things.
The DBA
The DBA is, obviously, the database guy. When another developer touches the database, he is likely to throw in his two (or three) cents, sometimes leading to some disagreements. If a problem can be solved using a stored procedure, he will naturally gravitate toward that solution. The DBA is concerned with the security of his database, and will generally err on the side of maximum security. Sometimes, this can be a difficult thing for the other developers to work with.
The Novice
The Novice, or Junior Programmer, is the next generation of one of the above. He may not have all of the skills that the other developers have, but is willing and excited to learn. Of course he requires mentoring, but he will tackle increasingly difficult tasks as he progresses on his way into one of the other categories. Foster your Novices’ skills, and encourage him to learn and grow in the field. Be careful not to mold him into the Dead Weight category, either by giving him tasks too far above his skill level (but always challenge him), or by overlooking the ways in which he can help.
We were all Novices at one point in our careers. Don’t overlook that.
The Dead Weight
Nobody wants to be dead weight, but some just turn out that way. Often, they are not really doing what they have a passion for. Somebody might have told them that getting into programming is the way to build a career, or that’s where the “big bucks” are. They might be Novices who have gotten discouraged because they don’t feel like they are being challenged. Find out what excites the Dead Weight, and try to give him tasks that flame those passions, hopefully pushing him into the category above that fits him the best.
