cellio | 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.

Flat | Top-Level Comments Only

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....

"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."

Yes.

Not everyone will be a rosh gadol, but not every rosh katan is destined to stay that way. I think almost all of us start out that way, so it all boils down to the guidance we get. One reason I'm kind of averse to managing people is that I fear I am not a good teacher, and I don't want to mess up someone else's career. I know how to be a rosh gadol (I wouldn't have the option of being otherwise, actually), and I know what to tell people to work on in abstract terms like you described, but I'm less confident of shaping the day-to-day stuff to lead them there.

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. But if all you do is mindlessly follow the recipe, you'll never be a master cook.

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.

Or perhaps "innovator" rather than "leader", but yeah, it's still back to the original problem.

I think you're right, though; it comes down to that curiosity and drive, which people have to different degrees. A "rosh gadol" stuck in a "rosh katan" world will still look for ways to improve things (while also looking for a better place, of course :-) ).

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"...

Yup, me too. There is some risk that my current employer will grow too large to maintain its present culture, but I hope we can prevent that outcome -- my current position is in the running for "best job I ever had".

Joel on davka

no subject

no subject

no subject

no subject

no subject

no subject