The Meaning of Team, Part 2

So, what is a “programming team” exactly? It almost seems a contradiction in terms: programming is, by its nature, a solitary occupation.
It’s sort of like an “electrician team” – do you as a homeowner want your electrician to obtain consensus so s/he doesn’t cross the wires the wrong way and incinerate your house?


One thing I’m sure of: you need at least one architect, a person who’s been through the wars, so to speak.
I think back to my first programming job. There were 4 coders, one of whom considered herself the “manager”, and the rest of us.
What perhaps made it work is that among the rest of us was a REAL senior programmer/architect type person, and not the self-appointed one.
He was a real craftsman and a superb debugger. He came up the hard way, through places like Digital, where technology was, in the old days, valued as an art and practiced with discipline and structure.
Under his guidance, roles were clear, and non-overlapping. We each had our own specialty areas. As the junior, I was lucky because I got to work with and learn from some fantastically gifted, highly skilled people who were generous with their time and their knowledge.
As I recall, there was no showboating or grandstanding, no back-stabbing to the boss about programming style or differences of opinion about methodologies.
If you got stuck, there was someone there to quietly help.
Plus, we each had our own, semi-private work areas. That kept down on the amount of office BS about things unrelated to the work at hand.
I think it significant that the self-appointed “manager” was not in the office all the time, and when she was there, she mostly either kept to herself or talked to our boss.
That left the rest of us to freely exchange ideas without judgment or the approval/disapproval of people in authority – very important, and it resulted in a better product and happier people.
It was a good place to work and, unfortunately, I didn’t appreciate how really special it was. Of course. What a jerk!