Summary:
Pragmatic Programmers Andy Hunt and Dave Thomas talk with Bill Venners about a gardening metaphor for software development, the reasons coding is not mechanical, and the stratification of development jobs.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: May 21, 2003 7:29 AM by
Tasos
|
Dave Thomas says, "With a garden, there's a constant assumption of maintenance. A garden is something that you're always interacting with to improve. We want people to view software as being far more organic, far more malleable, and something that you have to be prepared to interact with to improve all the time." Read this Artima.com interview: http://www.artima.com/intv/garden.htmlHere's an excerpt: Dave Thomas: What we should be doing is creating an environment in which people get to use all their skills. Maybe as time goes on, people move through the skill set. So today, you're 80% coder 20% designer. On the next project, you're 70% coder and 30% designer. You're moving up a little bit each time, rather than suddenly discovering a letter on your desk that says, "Today you are a designer."
Andy Hunt : If the designer also has to implement what he designs, he is, as they say, getting to eat his own dog food. The next time he does a design, he's going to have had that feedback experience. He'll be in a much better position to say, "That didn't quite work the way I thought last time. I'm going to do this better. I'm going to do this differently." Feedback paths contribute to continual learning and continual improvement. What do you think of Dave and Andy's comments?
|
|
|
I must agree because I've seen a lot of code recently that could do with "pruning" and even chucking on the compost heap (or is that stack???). Even better would be to stick the entire ASB under a pile of horse shit and pray it matures into a real commercial product!
|
|
|
I'd like to hear Andy's and/or Dave's views on the stratification of roles advocated in a good deal of the J2EE material I've read.
The <i>J2EE Tutorial</i> from Sun, for example, talks about there being developers, authors and deployers all involved in getting the product out.
|
|
|
> I'd like to hear Andy's and/or Dave's views on the > stratification of roles advocated in a good deal of the > J2EE material I've read.
Well, I'm certainly no expert on J2EE development (as J2EE seems to me to be one of those technologies best avoided given the luxury of choice), but I have two comments:
1. Roles aren't necessarily the same as people: in the article I believe we discuss individual people doing design some of the time and coding at other times; these people do multiple roles. To me, that seems healthy.
2. I've not read the documentation that advocates all these layers, but perhaps the wording is just a consequence of the target audience: when selling to the enterprise layer, perhaps the customers want to hear enterprise-style terms for things.
Cheers
Dave
|
|
|
It seems, from the last stages of this interview, that the software professional is somehow driven through a career path by someone... I think that your career path is something that you drive! You have an agreement with another entity (normally a company) to provide certain software skills. It is your responsibility, while exercising those skills, to further develop them. This could be done through: various experiences, reading, seminars, etc. that YOU are willing to 'chase/grab'. If your manager takes the role of a mentor and 'breaks you in' certain new role/skill that is welcome, but not what you should rely on or expect. If your environment doesn't allow you to develop any further (assuming that this is what you wish), you should be looking for alternative employ-ment/-er!
To give an example: I am a Java developer, but almost always get involved in analysis and design, development of web interfaces and databases, testing, debugging, etc. I continually keep reading articles (like the very interesting Artima ones :-) ), books (on various software fields), attend seminars/exhibitions, etc. I also have deep discussions with coleagues on various issues. I periodically examine code examples of new APIs, frameworks, etc in order to keep aware of available options/alternatives. In general, I've set myself as the main mentor of myself.
My manager is not a professional of a higher degree just because he is managing my time/assignments. We are both specialist(hopefully) professionals who interact in a certain environment protocol. The idea of a manager parent-figure, responsible for my career path, makes me feel unwell... And if "I want to get my hands dirty every now and then" then I arrange for it to happen!
I suppose you were possibly trying to influence the way some policy-decision-maker should think, but in the process (IMO)implied that the receivers, of such policies, should either welcome your suggested policies or accept their fate in their current working environment (, which doesn't have such satisfying policies!
|
|