A couple short anecdotes.
-------
Sam asks Phil to merge a file for him. After a short explanation, they conclude the right term is patching. So Phil follows with the implementation simultaneously with Sam explaining the idea to him. As they go along, Phil makes a diff between the old and the new version of the file, only to apply the patch to the old version of the file. Well, an odd algorithm for copying a new file over an old file, says Phil, leaving Sam a bit embarrassed.
-------
Phil is being asked by Fred to help pinpoint a problem by observing the stack trace of an exception that has been raised by a Java program. A multithreaded Java program. "So," points out Phil a source file name with a number printed on the sixth line of the stack trace, "this is the probable culprit as lines higher are from library classes. Could you trigger the error again, only printing out the stack traces of other threads, too?" And Phil got met with a blank stare from Fred: "Uh, wait, um, what again are processes and what threads? I forget, I only know they're somewhat similar." Now Fred felt a bit embarrassed as Phil claimed the ownership of Fred's keyboard for the duration of the project.
-------
Phil was asked to code the part of a GUI dealing with representing the content of a particular database table. It was explained to him the table basically connected two entities in a many-to-many relationship. Only it wasn't quite obvious from the design: a table having its own primary key field, and one foreign field from one table and one foreign field from the other table, not even having a unique constraint over the couple of foreign fields. After escalating the issue with the boss and having a refreshing talk with the one that designed it, the table was redesigned properly, not leaving out someone becoming somewhat embarrassed.
-------
Prediction: Phil becomes a one-man-band for software design, development, and support. Everyone else goes to sales and marketing.
-------
Sam asks Phil to merge a file for him. After a short explanation, they conclude the right term is patching. So Phil follows with the implementation simultaneously with Sam explaining the idea to him. As they go along, Phil makes a diff between the old and the new version of the file, only to apply the patch to the old version of the file. Well, an odd algorithm for copying a new file over an old file, says Phil, leaving Sam a bit embarrassed.
-------
Phil is being asked by Fred to help pinpoint a problem by observing the stack trace of an exception that has been raised by a Java program. A multithreaded Java program. "So," points out Phil a source file name with a number printed on the sixth line of the stack trace, "this is the probable culprit as lines higher are from library classes. Could you trigger the error again, only printing out the stack traces of other threads, too?" And Phil got met with a blank stare from Fred: "Uh, wait, um, what again are processes and what threads? I forget, I only know they're somewhat similar." Now Fred felt a bit embarrassed as Phil claimed the ownership of Fred's keyboard for the duration of the project.
-------
Phil was asked to code the part of a GUI dealing with representing the content of a particular database table. It was explained to him the table basically connected two entities in a many-to-many relationship. Only it wasn't quite obvious from the design: a table having its own primary key field, and one foreign field from one table and one foreign field from the other table, not even having a unique constraint over the couple of foreign fields. After escalating the issue with the boss and having a refreshing talk with the one that designed it, the table was redesigned properly, not leaving out someone becoming somewhat embarrassed.
-------
Prediction: Phil becomes a one-man-band for software design, development, and support. Everyone else goes to sales and marketing.
1 comments:
Phill needs to learn how to be a team player! Damn you Phill! Why cant you let anyone else work the keyboard!
Post a Comment