|
JT/Brad I'm afraid from my personal experience I can't agree with this 'two-person' concept. It's not that I am opposed to criticising (or being criticised). My objection is that I find coding a very personal endeavour. I find that each programmer has a certain 'style', which is quite evident in the way they approach their job, even within constraints established by departmental standards. This is not to say that someone uses CMD3 to exit, while another uses CMD24. By 'style', I mean the way the code itself flows, the naming conventions, the use and design of reads/chains or DOW/DOU, etc. If I could use an analogy here (I know it's always risky doing this, but I feel it is valid), if we equate programming to painting (start with a blank canvas, working to a goal that is only in our imagination at the moment), I see the only real way a 'tag team' programming development can work is if you have a basic 'paint by numbers' scenario, where purely technical skill is involved, without imagination (or even understanding of where we will end up). If, however, you need something with a bit of imagination, then the rotating programmers would lead to something like a collaboration between Picasso and Van Gough - fine individually but a mess when combined. I find a far better approach is to divide the project in two. Work in tandem, with frequent consultation, and both stop at certain points and test each others work against your own, to ensure the development is staying compatible all along the line. This way, each programmer can concentrate on producing their best result, while the team as a whole stays in touch with the overall development. Possibly I should be a litlle less precious about the individual's 'personal flair', but I don't find programming to be a soulless application of standard statements, one after the other. To me, it is a mental construction, transferred via my fingers to the system. As such, each program represents my mental process, and to try to write half a program my way, and half someone else's, is not the best way to work effectively (and happily). "jt" <jt@ee.net> Sent by: To: <midrange-l@midrange.com> midrange-l-admin@mi cc: drange.com Subject: RE: Two persons per product" 10/12/01 15:50 Please respond to midrange-l Can't agree more. But unless you've done it, may not seem possible. I've never tried alternating like that. Probably would work best. The KEY is the focus of the person who's not keying. That's the tough job, keeping up with the other, as the fingers can work quicker than the brain, sometimes (sometimes...?!? LOL...!). The other KEY is that the person can accept criticism. That's where I've found the apprenticeship approach works well, as there are "roles", as long as the "master" doesn't mind learning from the "apprentice". I gather you've had more experience than I have, Leif. My experience is that this works in small doses. A few hours a day. I've not had much luck with day-in and day-out... What about you...? I've found it to be much tougher to pair two "masters". I've had luck pairing two "apprentices" but I didn't actually observe them working together, much, at the time. I've found complementary personalities to be the bigger factor. (Tired, so will look forward to reply tomorrow, if any.) | -----Original Message----- | From: midrange-l-admin@midrange.com | [mailto:midrange-l-admin@midrange.com]On Behalf Of Leif Svalgaard | Sent: Sunday, December 09, 2001 11:32 PM | To: midrange-l@midrange.com | Subject: Two persons per product" | | | From: Brad Jensen | > debugging yes, writing no | | I have on many occasions practiced the "two-person" method. | One person at the keyboard, the other one criticizing and correcting; | change places every 30 minutes. This actually works with "truly" | professional people. Also in other professions. One measure of | being professional is the "interchangeability" of persons. | "Cowboy" mentality is not desirable. Unfortunately, many (most?) | programmers see it otherwise. This contributes to keeping our | field one predominantly dominated by amateurs. _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.