The following four words should strike fear into the heart of every programmer out there:
Five-Hour Code Review
It is my afternoon.
5 thoughts on “Terror”
Just Some Fuckhead
I’ve just been given the six week project of documenting all the applications written by the developer that just left.
This on top of my own development work and now having to support the ongoing development/debugging of the developer that just left.
So I’m a little envious of your five hour break.
joel hanes
The only way to survive is to prepare, and to employ malicious compliance.
Read the code ahead of time and find five things to say that aren’t bullshit, five actual substantive comments to make. That’s the whole point, anyway, and will achieve the purpose of the meeting.
Dole the first two out one per hour. After the second, you can drive the meeting to an early conclusion yourself by picking up the pace — by the time you’ve gotten the fifth point discussed, at around the three-hour mark, everyone will just want to flee your presence, and a motion to adjourn is always in order.
joel hanes
A novice asked the Master: “Here is a programmer that never designs, documents or tests his programs. Yet all who know him consider him one of the best programmers in the world. Why is this?”
The Master replies: “That programmer has mastered the Tao. He has gone beyond the need for design; he does not become angry when the system crashes, but accepts the universe without concern. He has gone beyond the need for documentation; he no longer cares if anyone else sees his code. He has gone beyond the need for testing; each of his programs are perfect within themselves, serene and elegant, their purpose self-evident. Truly, he has entered the mystery of Tao.”
joel hanes
There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying, “What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure.”
joel hanes
A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity.
A program should follow the `Law of Least Astonishment’. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least.
A program, no matter how complex, should act as a single unit. The program should be directed by the logic within rather than by outward appearances.
If the program fails in these requirements, it will be in a state of disorder and confusion. The only way to correct this is to rewrite the program.
I’ve just been given the six week project of documenting all the applications written by the developer that just left.
This on top of my own development work and now having to support the ongoing development/debugging of the developer that just left.
So I’m a little envious of your five hour break.
The only way to survive is to prepare, and to employ malicious compliance.
Read the code ahead of time and find five things to say that aren’t bullshit, five actual substantive comments to make. That’s the whole point, anyway, and will achieve the purpose of the meeting.
Dole the first two out one per hour. After the second, you can drive the meeting to an early conclusion yourself by picking up the pace — by the time you’ve gotten the fifth point discussed, at around the three-hour mark, everyone will just want to flee your presence, and a motion to adjourn is always in order.
A novice asked the Master: “Here is a programmer that never designs, documents or tests his programs. Yet all who know him consider him one of the best programmers in the world. Why is this?”
The Master replies: “That programmer has mastered the Tao. He has gone beyond the need for design; he does not become angry when the system crashes, but accepts the universe without concern. He has gone beyond the need for documentation; he no longer cares if anyone else sees his code. He has gone beyond the need for testing; each of his programs are perfect within themselves, serene and elegant, their purpose self-evident. Truly, he has entered the mystery of Tao.”
There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying, “What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure.”
A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity.
A program should follow the `Law of Least Astonishment’. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least.
A program, no matter how complex, should act as a single unit. The program should be directed by the logic within rather than by outward appearances.
If the program fails in these requirements, it will be in a state of disorder and confusion. The only way to correct this is to rewrite the program.