Thursday, June 19, 2008

learning things from the ground up (or being buried in the mud?)

I feel like I've been learning certain things lately in the slowest, worst way possible.
I have to get results out of this code that I didn't write, but I have been trying to turn into something more friendly, familiar and reliable. I collaborate with one other person who has slightly different aspects of the code he is interested in developing. We try to keep in synch, but changing things break other things and I often find myself with a broken code and the tortuous question of whether to push on and fix the problems or go back to a slightly worse previous version that I know works (or at least the parts I have checked).

During this process, I am forced to learn about things that I don't feel like learning at that particular time. In the end I do learn certain things, and after I know them, I also have a sense of how they can break, how one can confuse them for something else.

I'm somewhat reminded of a comment by one of my physics professors during college relating to thermodynamics. One of the math professors suggested that there is a beautiful way to understand thermodynamics. If one just understands a certain structure, then thermodynamics fits into it very nicely. (sorry for vagueness, I never actually learned thermodynamics very well)
But the physics professor responded that he thought it was better for students to first muck around in details before getting the clearer grander picture.

So what am I afraid of? I do learn in this process. I think the problem is that I am encountering real design flaws, or perhaps imperfect implementation. As a result, I will likely never actually rise to that level of clarity, and then have only gained an extremely obscure skill: familiarity with a code very few people use. Perhaps I won't know the ultimate value of this until later. I have a feeling that much of the technical details I am learning could be learned much faster and easier in some other way. But perhaps there are lessons involving people, egos, creations, and collaboration that will be very valuable (if I can ever escape from this situation!!)

3 comments:

Deborah said...

Boaz,

(i told you I like your blog!)

arn't the details of what your professor mentioned that are prior to the result on the same level as the mistakes and imperfect design you encountered? Wouldn't the mistakes that you are discovering mean not that you won't see that result of clarity but that you will it will just include this (mistake) stuff as part of it as well?

Boaz said...

Thanks Deborah.
Yes, I think that that's what I was getting at. I'm not sure whether knowing something always needs to involve the ways that thing can go wrong. Though I suppose being an expert does.
In the case of learning to effectively use this code, the problem is that its too big of a job. It needs to be broken into smaller pieces. I suppose its not that I won't learn things in the process, but that what I am trying to put together is just too big, and if I put everything on hold until this big picture comes together, I may not have a job, or much sanity left by the time that comes about. So design flaws are particularly damaging when the project at hand is too big. There's a certain amount of faith you have to put into something, that it will hold together and not fail you. Otherwise, it was useless: just build your own.

Deborah said...

hmmm.. I have to think about this.


Deborah