The team room and types of developers

The devel­op­ment team has recent­ly relin­quished our indi­vid­ual offices in favor of a team room where we are all work­ing togeth­er.  At first, I was skep­ti­cal that I would be able to keep a high lev­el of pro­duc­tiv­i­ty with the dis­trac­tions that a team room, by its very nature, cre­ates.  I could­n’t have been more wrong.  We quick­ly meshed as a team and have become notice­ably more pro­duc­tive.  (You can see the slope change on our burn­down; it is dramatic!)

One of the side-effects of work­ing in a big room with the rest of the team is that I’ve start­ed to notice the dif­fer­ent devel­op­ment and per­son­al­i­ty styles of the dif­fer­ent mem­bers.  I’ve come up with sev­er­al dif­fer­ent gen­er­al cat­e­gories.  Some peo­ple cross these bound­aries, depend­ing on the situation.

Development Styles

The Architect

The Architect has become the de fac­to leader of the team.  In many ways, he dri­ves the deci­sions that are made regard­ing the archi­tec­ture of the new fea­tures being built, as well as the refac­tor­ing of the exist­ing code base.  He also decides the con­ven­tions that the rest of the devel­op­ers use, often by set­ting the exam­ple for oth­ers to fol­low.  The Architect is a by-the-book best prac­tices kind of per­son, with a strong under­stand­ing of the fundamentals.

The Architect’s code tends to be very struc­tured, and fol­lows all of the best devel­op­ment prin­ci­pals.  Sometimes, though, he may tend to over-engi­neer a bit in the inter­est of fol­low­ing the prin­ci­pals to the let­ter, and he spends a lot of time work­ing on things that may not direct­ly affect the time­ly com­ple­tion of the project at hand.  A strong mem­ber of the team, he is nat­u­ral­ly a men­tor and encour­ages oth­ers to pro­duce good, main­tain­able code.

The Artist

The Artist tries to make his code as ele­gant and flex­i­ble as pos­si­ble giv­en the con­straints of the code and the require­ments.  He has a strong grasp of the fun­da­men­tals, but does­n’t adhere as strong­ly to “the book” as the Architect might.  The Artist seeks read­abil­i­ty and self-doc­u­men­ta­tion, and may neglect to appro­pri­ate­ly com­ment his code except in extreme cir­cum­stances, or when par­tic­u­lar­ly proud of a solu­tion.  Artists are gen­er­al­ly strong pro­gram­ming enthu­si­asts.  The Artist needs to watch out for “over­ly ele­gant” solu­tions — those that work cor­rect­ly, but are dif­fi­cult for oth­ers to under­stand.  This can cre­ate risk if some­body else needs to make a change and mis­tak­en­ly breaks things in unfore­seen ways.

In many ways, the Artist and the Architect are sim­i­lar.  Like the Architect, the Artist pro­duces good, main­tain­able code, and can be looked towards as a men­tor.  The major dif­fer­ence is the Artist’s will­ing­ness to break the rules at times for the sake of the ele­gance of the code.  Both the Architect and the Artist thrive in green­field envi­ron­ments, and tend to find excite­ment in the process of design­ing and imple­ment­ing new things.

The DBA

The DBA is, obvi­ous­ly, the data­base guy. When anoth­er devel­op­er touch­es the data­base, he is like­ly to throw in his two (or three) cents, some­times lead­ing to some dis­agree­ments. If a prob­lem can be solved using a stored pro­ce­dure, he will nat­u­ral­ly grav­i­tate toward that solu­tion. The DBA is con­cerned with the secu­ri­ty of his data­base, and will gen­er­al­ly err on the side of max­i­mum secu­ri­ty. Sometimes, this can be a dif­fi­cult thing for the oth­er devel­op­ers to work with.

The Novice

The Novice, or Junior Programmer, is the next gen­er­a­tion of one of the above.  He may not have all of the skills that the oth­er devel­op­ers have, but is will­ing and excit­ed to learn.  Of course he requires men­tor­ing, but he will tack­le increas­ing­ly dif­fi­cult tasks as he pro­gress­es on his way into one of the oth­er cat­e­gories.  Foster your Novices’ skills, and encour­age him to learn and grow in the field.  Be care­ful not to mold him into the Dead Weight cat­e­go­ry, either by giv­ing him tasks too far above his skill lev­el (but always chal­lenge him), or by over­look­ing the ways in which he can help.

We were all Novices at one point in our careers.  Don’t over­look that.

The Dead Weight

Nobody wants to be dead weight, but some just turn out that way. Often, they are not real­ly doing what they have a pas­sion for. Somebody might have told them that get­ting into pro­gram­ming is the way to build a career, or that’s where the “big bucks” are. They might be Novices who have got­ten dis­cour­aged because they don’t feel like they are being chal­lenged. Find out what excites the Dead Weight, and try to give him tasks that flame those pas­sions, hope­ful­ly push­ing him into the cat­e­go­ry above that fits him the best.

Share