|the Hidden Realities of Computer Industry in Japan||Japanese|
Let me tell you some stories about my experience as a programming instructor at a software house. I can remember how hard I had demonstrated on a whiteboard and tried to give my learners good advice. But every effort I had made did not seem to be helpful for them. My lecture consists of trifle comments from general knowledge and lacked in their enthusiasm or active involvement. It was clear that most of them were totally short of experiences, and I could easily imagine that they were facing and tackling their programs day and night without enough understanding.
Every piece of mistake reflects the author's character. I wondered it would be far more effective for the students if I could actually comment on their own program. So, one day I requested them to prepare their programs and some questions about them for the following lecture.
Certainly no one had brought his or her programs. I said to them, "Any program will do for all of you as long as it was written by yourself. I could point out and correct your mistakes, and that will give you convenient and useful tips for programming." But most of them hesitated about it. Everybody was in a "forget-about-it" mode, and some had given up and run away from the seminar.
Situation had not changed ever after. No one had submitted his/her program. My lecture was suffering the symptom of emptiness and tastelessness. There would be no merit for both my audience and me. It was certainly a very silly waste of time. In the end, the seminar has lost its primary purpose and has become the place where people get together for a chat over tea after the meeting.
Attendance at my lecture had been fallen off. I could no longer seek any reason to continue except my obligation to the president of the house. Naturally this seminar had broken up and disappeared forever.
Of course, there were a few promising attendants, though. They didn't prepare their program, but they used to come to me with questions after the meeting. It is clear that these kinds of people would eagerly seek knowledge for themselves without any help from others. Their programming skill seemed to be at the highest level at the seminar.
I was asked from a computer-magazine publisher to write an explanatory article on programming. I decided to accept this offer as long as I could make it in more practical fashion. First of all, I needed a "real," or commercially oriented, program as a material. In order to collect materials, I put a want ad in a magazine for "poor program."
The great majority of the program gathered was not satisfying at all. The quality level of these programs was too high for the "poor" level. If the Japanese software industries consisted of such highly skilled labor, how could we explain this incurable level of current software products?
Fortunately, I was able to get an "hopelessly poor" program. One of the editors of the publisher had sent the program to me with a message saying, "What on earth is it? It's all Greek to me." I nearly fainted when I saw it. The program was technically incoherent and confusing. In Chapter 3, you can see how confusing the program was.
An interesting thing was that the program was not provided by its author, but his boss. The author might be a rookie programmer, and his boss would want me to diagnose and criticize his program. Memo from the boss was attached with the program. Reading the memo I felt like I had known how things were going in his company. At the same time, I felt certain that the problems would lay with the boss, rather than with the rookie.
I fully understand the feeling when someone wants to conceal his/her programs. Once your program is checked by someone, it reveals every thing about your mistakes. What makes your program look poor? What kind of misunderstanding did you committed in the program? Is your project based on a good teamwork? These things will disclose the honest level of your programming skill in public.
You might be unwilling for such disclosure. But how can you improve your skill without finding your fault?
A goal is not to find fault with someone. And you are not the only one who makes mistakes. When you find someone's mistake and recognize his/her program's bad point, the most difficult thing is to point it out so that he/she won't make the same mistake again. Certainly, It would be one of the biggest challenges for the Japanese computer industry.
The first company that I worked for had a system that gave us a chance to disclose our programming mistakes at the end of the weekly section meeting. We could not afford the time to discuss each of our mistakes in full details; we were allowed a half or one hour or so. We were supposed to present our poor stuff that had resulted in a total waste of time.
Every member had enjoyed that system. Actually, listening to the other's mistakes is a great fun. You could definitely feel relaxed at the meeting of that kind. Of course, nobody would attack your mistake itself. What we had been concerned is to exchange our opinions with each other in order to prevent it from happening again. We had focused on some pieces of advice on what you should have done to avoid that mistake.
In fact, creating such atmosphere in your office might be really difficult. In most cases, there are wide differences in programming ability among the programmers. In igo" or "shogi" (Note), you can enjoy the game only with someone whose level is fairy close to you. If your competitor is far above you, you will be no match for him. It must be a hopeless challenge forever, indeed. Same thing can happen to programmers, too.
As igo is one of my hobbies, I sometimes read some igo magazines, which give us detailed comments and illustrations based on actual games between professionals and amateurs. Some amateur players will improve their technique through such magazine's demonstrations. These magazines and other manuals of any kind always includes bad examples together with good ones, providing explanations on how bad these examples are. Most pages are devoted entirely to these explanations.
You must acquire necessary techniques in order to improve your skill. This can be a common essence when you want to make progress in games, computers, and any other fields. That's why I had collected a poor program as an appropriate sample that is subject to my advisory comments. In the end, I knew that was too difficult an attempt, though.
I've not meant that all programmers want to conceal their works. In fact, some programmers have no hesitation about revealing or sacrificing their own works. Some of them often bring their program to expert programmers to seek advice when they are in trouble.
In general, these students are talented or promising programmers. They would successfully improve their skill in a short period. They are not afraid of showing their mistakes even when they don't have any confidence at all. They are just accustomed to showing or referring to each other's programs. As they have already got out of the habit of hiding their mistakes, they can be open to supports from expert programmers. This allows them to improve their skills, which would make significant differences in their abilities.
Note 1: "Igo" is a Japanese board game that is similar to Othello.
Note 2: "Shogi" is like chess. Japanese traditional game along with igo.
|the Hidden Realities of Computer Industry in Japan||Japanese|