There was an interesting article posted few weeks ago claiming that We’re Teaching Coding All Wrong by Nathan Esquenazi. As I see it, this article contains some good advice along with some bad advice. So I’m going to explore what I agree with and what I disagree with.
Individual Success Valued Over Team Victories
The author begins with the claim that all technology breakthroughs are the result of a team effort. However, from day one in the classroom, students are told to value individual success over team victories. He claims that liberal arts majors have a heavy focus on communication, and business/medicine programs emphasize group work, while CS programs value technical output over the soft skills.
In a sense, I think he’s basically correct here. Although I don’t have experience in the liberal arts, business or medicine programs, I find it plausible that they put more focus on team work and collaboration.
The interesting question to me is, should CS programs put more focus on team work and collaboration? From my days at the University of Illinois, I distinctly recall helping other students through their machine problems at the engineering computer labs. I remember being shocked that students in a 300 level programming course were not able to use a debugger to step through their code, inspect the values of variables, and identify the error in their code. To me, the university had clearly failed to either teach these students how to code or identify these students as incapable before unleashing them into the work force.
Are the Universities Doing a Good Job?
In a sense, we did work together as students – without being classified as “cheating” as the author claims such collaboration to be identified. And I hope that the students I helped learned something along the way. However, through my experiences hiring entry level CS grads, I have seen a large number of engineers who are unable to program at a professional level, and who IMO are dangerous employees.
When a candidate tells me that they are completely confident that their solution is correct, and there is a blatant error in the code, that is a dangerous person to bring on the team. That is a person likely to tell a customer that the problem “isn’t in our code” when it is. That kind of behavior directly damages our integrity, degrades customer trust, and ultimately harms the company, including the person’s coworkers.
Are All Accomplishments Team Based?
Throughout the article, the author seems to implicitly state an alternative. He states that accomplishments are either completely individualistic, or completely team based – as a binary choice. However, I think any experience in the world working on building software (or anything for that matter) shows that is an overly simplistic view.
At the end of the day, it is an individual who spots a bug. It is an individual who writes code. It is an individual who thinks of some new aspect of an architecture. Yes, teams of individuals can accomplish more than an individual on his/her own. But only if that team is made up of competent individuals. To take the extreme case, a team comprised entirely of incompetent engineers would accomplish nothing.
As a manager, finding the right people for the team is a critical job function. The team needs to have the right people, so that it can perform optimally. And this means that a manager must judge the individuals on the team according to their individual contributions – not by the team’s accomplishments. If the manager judges the individuals on the team solely by the group’s accomplishments, then it completely takes away the manager’s ability to improve the team.
The Lone Wolf
But this doesn’t mean that programmers must be lone wolves, each in their own world, each working in silos. Collaboration, communication, and conflict resolution are valuable skills in the work place – there is no question about that. And I essentially agree with the author’s point that the universities do a poor job of producing quality engineers. However, I think that the author’s message is muddled and confused.
The alternative is not, lone wolf programers vs collaborators judged solely on the team’s accomplishments. There is a third option. It is to build teams of competent individuals (judged according to their individual merits) who are able to effectively collaborate. That is when the greatest results are achieved, and I think that’s exactly what you’ll find if you look into exactly how the revolutionary technology that we use today has evolved. Whether you consider the history of Robert Noyce and Fairchild Semiconductor, Steve Jobs and Apple, or Bill Gates and Microsoft – they all created teams of fantastically brilliant individuals who were able to effectively work together.
Ryan Sawatzky 