My son the English teacher was asked by a student interested in computer science why he had to do all that reading. I had several answers, but the main one is that programming is a creative task of achieving with running code the goals and requirements expressed informally, in a natural language, by team mates and users. If programmers can't read closely, they cannot understand what they have to do, and they will not recognize gaps that need further discussion to fill in. Their code will not meet the need, and it will behave unexpectedly when the programmer fills a gap in a way that does not match the unexpressed desires of the user. As a professor of freshman CS, one of the most common problems for smart students who thought they knew to program already was their failure to read and interpret correctly a carefully crafted problem statement. They'd sometimes complain that the statement was confusing, but the reality was that the statements they complained about were for the most part complete and unambiguous. The same need for careful, analytic reading pervades practical programming, for interpreting requirements, protocol specifications, algorithm definitions, and language and API documentation.
But why to teach close reading with literature, rather than programming manuals? First, most programming manuals are not that well written, and are pretty boring unless one needs them for a particular task. Second, analyzing literature brings out the varieties of human expression and argumentation, which a programmer will face when dealing with nontechnical users, managers, and critics.
I was surprised just how much code I had to read when I made the transition from academia to industry.
The TopCoder site is great for practice. Their problem defs are very clear and after you code them, you can test against their unit tests. You can even see what others did to code them.
This is very true! I remember figuring out how to ask the right questions and listen to the specifications very carefully.
Post a Comment