by Asim Jalis
I had another extremely positive programming experience today.
There was a task that was estimated at 12 hours and we finished
it in 4. There was a lot of refactoring and repositioning old
code to make it do the new things that we needed to do.
1. I want to figure out what is going on here, why I am enjoying
programming now. If I understand this I might be able to recreate
this experience at will.
2. This figuring out is connected with a pattern I have noticed
in INTP thinking (or at least in my own thinking). The pattern is
that we extract general patterns from specific cases and then
apply the patterns to new cases. In fact this paragraph is a neat
example of the thing that it is talking about. We switch from
general to specific and then back to general. A fluidity in
beliefs and viewpoints makes this weaving extremely easy and
almost natural. Let me call this the G-S (General <-> Specific)
style of thinking.
3. So now I want to apply the same approach to determining why I
am enjoying my current programming experiences so much.
4. I have been refactoring a lot. In fact refactoring has a deep
G-S flavor. Elegant programs are fun to write, but programs with
a lot of special cases are tedious to write. Except that when you
apply G-S you can begin to see patterns in the tedium, and it can
become possible to turn messiness into sublime elegance. The most
satisfying programming experiences I have had so far have had
this flavor: Initially the problem looks messy, but then once the
variation between the different cases is subtracted out it
becomes the manifestation of the same deep abstraction.
5. Mathematics has the same flavor of extracting out specific
variation and then finally arriving at an abstraction that covers
all the specific cases but also contains something more than the
original cases.
6. Why is it so hard to get into this G-S state in programming?
One reason might be that we are always in a hurry. There are
deadlines to meet and tasks to complete. G-S refactoring requires
pause and reflection. It's not possible in a frenetic work
environment.
7. Another possibility is that some problems are more amenable to
G-S reasoning and others are not. This worries me.
8. One reason I might not have experienced it before is that this
requires a critical mass of engagement. It's not possible to see
the opportunities for refactoring if I don't open the editor and
study the program.
9. So there might be small steps that could be used to get
initially engaged with a program and then once one is immersed in
it to ramp up the engagement by refactoring it into elegance.
10. Another insight here is that it is usually much easier to
refactor tests. However, once you refactor the tests that begins
to suggest ways to refactor the code. In fact this might be the
key to having the sweet refactoring experience.
11. This also explains why this experience is not possible in a
hurry. When I am hurrying I don't have time to refactor the
tests. And soon I don't have time to refactor the code.
