cellio: (writing)
Monica ([personal profile] cellio) wrote2004-12-07 11:27 pm
Entry tags:

Joel on davka

A few days ago Joel Splosky posted an article about why (some) software methodologies are bad in which he said that he has trouble explaining a certain concept that comes across more clearly with Hebrew terminology. Being both a technical writer and sufficiently proficient to understand the (simple) terms he was using, I decided to take a crack at it.

His followup, based on a response from an Israeli, was much better than mine (also different in some ways), which is presumably why he chose to publish it. But he complimented mine, which suggests to me that I didn't completely miss the mark.

I wrote (and keep in mind that this is my translation, not necessarily my opinion):

Some people are brilliant in their fields, and it is tempting to try to follow them around and write down everything they do in an attempt to replicate it. But that's not how quality works; part of what a great practitioner does is to make things up as he goes along, informed by his vast experience and knowledge of the world, and you can't distill that down into a recipe or methodology. The master chef is the master chef not because he adds rosemary to the baked haddock but because he understands that this rosemary works with this type of fish with these other ingredients at this temperature. Similarly, you cannot follow a great programmer through code reviews and do what he does without understanding why he structured this code that way and why he used that particular data structure. Not all all software is alike; by trying to follow his methods without being a great programmer yourself, you will end up applying incorrect methods to your own problem.

Methodologies, by their nature, encourage parroting rather than understanding. They're great for McDonalds; they're not so great for the five-star restaurants. So too with programming. The rosh gadol understands; the rosh katan mimics, following a formula. If your task is complicated, a mimic not only fails to help but can actually harm. The last thing you want to do is to encourage people to work that way.

[identity profile] goldsquare.livejournal.com 2004-12-08 04:56 am (UTC)(link)
I touched on this some years ago, in a conversation at work.

The issue is guidance, of knowing not merely what was asked, but what is needed and needful. The process of learning how complete a job needs to be, and how involved other people need to be in updates and status and success of failure, is how one rises in the hierarchy of titles.

The conversation at work was, at the tail end, something like "A senior engineer knows what needs to be done, anticipates what will be needed to be done, and tells everyone who it is appropriate to inform when he is finished - and can instruct other engineers in the same with their tasks. A principal engineer does the same, but can also instruct his boss on what the boss needs to do." :-)

I have managed rosh katanim, and it sucked. They kept telling me I was a lousy manager because I didn't bug them twice a day, nag them, and give them initiative....

[identity profile] goldsquare.livejournal.com 2004-12-08 03:47 pm (UTC)(link)
Joel seems to be saying that methodologies lead one to being a rosh katan. There is truth in that, but beginners also need structure.

This morning, summarizing the discussion for a co-worker, I realized the situation a bit more clearly.

A "rosh gadol" divines the real purpose behind each task or request, and fulfills that purpose. The "rosh katan" observes the task, without reasoning and without fitting it into the universe.

A nascent "rosh gadol" will always ask why, will wonder where a rule came from, wants to know more about purpose. And will grow.

If so, that makes a software methodology irrelevant to the growth of a "katan" to a "gadol". Either you have the curiosity and drive, or you don't.

In the case of a "katan"-stable sort, a methodology can give them enough rigorously defined steps to perform that they can imitate a "gadol" so long as true insight is not required.

A "gadol" can create structures and procedures. A "katan" will only observe them. Not even improve them.

So, what is the English term for this? Follower and leader... and we are back where Joel started, I think.

[identity profile] dr-zrfq.livejournal.com 2004-12-08 11:42 pm (UTC)(link)
Joel seems to be saying that methodologies lead one to being a rosh katan. There is truth in that, but beginners also need structure. The trick is to treat the methodology as a stepping-stone, not an end state. You probably should follow the recipe the first time (to go back to the food thing), but while doing so, you should observe the effects of the work you do so you can apply those principles next time.

To quote one of my college CS professors: "First you have to demonstrate that you can follow the rules. Then we teach you how, when and why to break them."

I've worked for a small company and a big firm. Guess which one I look back upon as "the best job I ever had"...

[identity profile] nancylebov.livejournal.com 2004-12-08 03:24 pm (UTC)(link)
Here are my best guesses for English equivalents to dafka, and neither of them quite cover the ground.

"Contextual" means roughly the same thing, but is somehow too vague and intellectual. It doesn't imply doing a job in a way that actually contributes to the goal.

"Clueful" implies that there's no way of conveying the clue to people who don't have it already.

[identity profile] chaos-wrangler.livejournal.com 2004-12-10 12:53 am (UTC)(link)
How about "stam"? I've taught the word to several otherwise non-Hebrew speaking friends 'cause I use it fairly frequently & can't think of a good English equivalent - "vanilla", "base case", "plain", etc. sometimes work, but they each feel not-quite-right.

[identity profile] chaos-wrangler.livejournal.com 2004-12-12 06:33 pm (UTC)(link)
My first non-thinking reaction was "right and wrong", and on looking back at what I wrote I think I see why. "Ordinary" is good for the adjective form but doesn't work so well for the adverb form (which I completely left out of my proposed translations too), as in "doing something stam", i.e. not for a specific/special purpose. I suppose there it could be translated as "just doing something".

[identity profile] chaos-wrangler.livejournal.com 2004-12-19 08:22 pm (UTC)(link)
To me "routine[ly]" means something different: something that has been done before on a regular basis or as a standard response, whereas "stam" has an implication of lack of special/specific thought.