# A series of unfortunate things I programmed one time

I’ve been thinking lately about what makes good engineering. Actually, let’s be honest. As engineers, that’s not what we focus on. We get hung up on the failures—which always seem to outnumber the successes. Of course once you get out into the real world of programming for a livelihood, success is measured in terms of project completion and client satisfaction, but as easy as it is to put your head down and focus on the next ticket, that doesn’t absolve us of having to master our craft, to learn new things and better understand and utilize the old.

But I won’t try to say anything intelligent on good engineering. Instead, I’ll try to communicate the regrets that surfaced last weekend when I plugged in my old laptop and sifted through a decade-old folder called projects.

## How I started programming

The first thing I went looking for was one of my first major programming efforts, the result of the reason I started programming. A pretty long time ago, I came across a paper called Visual Simulation of Smoke by some pretty impressive people at Stanford. Research like this is what makes those Pixar movies possible. That you can simulate such complex dynamics from a set of simple principles fascinated me. This was about halfway through high school, so I decided to learn vector calculus and linear algebra just to make this happen.

It was a long, slow process. Timestamps indicate that I finally got something working five years later in about 2005 (Junior year of college). Frankly, I still feel pretty good about the result!

## Down the Rabbit Hole

In hindsight, this shouldn’t really amount to more than a week or two of work, but learning is the process of making hindsight obvious. One way or another though, I had something special: knowledge. And experience. At this point, I had three options:

1. Learn from what I’d done and improve
2. Learn from what others have done and improve
3. Go down the rabbit hole and see how complicated I can make things

Given my experience at the time, it’s hard to say I chose the wrong option, but let’s be clear: I chose (3), and I didn’t just slowly wade into it. I sought out complexity. I enhanced the complexity. No, seriously. I took the basic method and made it as absolutely opaque as I could. I wanted to enter it into the International Obfuscated C Code Contest:

 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43  #include #include #include #include #include #define R(x)(x)/2 #define r(w)_(w,0) #define V(w)(w)*(w) #define _(w,Z)u[w][p+Z] #define p a+l*b+V(l+1)*c+b #define o(x,j,S)U(x,j,l-j,S) #define L(w,Z,z)(1-z)*(w)+z*(Z) #define M(Z,j)(Z>j?j:(Z<0?0:Z)) #define T(x,j)o(c,x,o(b,x,o(a,x,j))) #define U(w,Z,j,x)for(w=Z;w2)r(1)+=(r(3)+_(3,l+1))*3.5/(1+4*(S==1));if(b<3){d=b;b=l-2+ (d==1);r(d)=_(d,-l-1);b=d;})U(d,0,3,h=k;k=j;j=i;i=h;U(c,1,l-(k!=2),U(b,1,l -(j!=2),U(a,1,l-(i!=2),F[d]=r(d);K(j)K(i)I))))T(1,U(d,0,3,F[d]=R(r(d)+_(d, O[d]));)I)T(0,r(8)=0;U(d,0,3,r(8)+=_(4+d,O[d])-r(4+d);))f=80;while(f--){U( a,0,l,U(b,0,l,c=0;P()c=l-1;P(-)))T(1,Q=-r(8);U(d,0,3,Q+=_(9,O[d])+_(9,-O[d ]);)r(9)+=0117*(Q/6-r(9))/0620;)}T(1,U(d,0,3,if(a)r(d)=r(d+4)-r(9)+_(011,- O[d]);))W=u[3],u[3]=u[7],u[7]=W;}if(S-2)putchar(05);else{if(getchar()-05){ rewind(stdin);getchar();}}usleep(9<<9);}}

This has basically all the features of the video above, except it’s dramatically less useful. I even RLE-encoded the University of Michigan ’M’ on line 22 and a small part of line 21. It has a X-Windows interface. It doesn’t run correctly unless line 1 starts with a tab.

So am I proud of this code? Yeah, a little. (It’s on github by the way.) But that’s vastly outweighed by the regret I have over not having used this period of my life more effectively. It’s likely I may never again have the combination of time, motivation, and inspiration that it takes to dive so deep into this particular confluence of math, science, and programming.

## Still more

Actually, I went a bit farther. The next stop on this journey through my time capsule was into the pejoratively named field of Colorful Fluid Dynamics (CFD) (not to be confused with the more useful field of Computational Fluid Dynamics). Colorful Fluid Dynamics is what you get when you leave behind rigor and accuracy and just try to make pretty pictures.

In 2006, I got my Incomplete LU-Preconditioned Bi-Conjugate Gradient Stabilized (ILU-Preconditioned BiCG-Stab) solver working and used it to solve Laplace’s equation (think: stretched membrane) on a two-dimensional finite volume grid. I’m pretty certain it remains the most complicated thing I’ve ever programmed successfully, but by the time I finally got it working, I was so exhausted and burned out on my search for complexity that the rest of my career in Aerospace Engineering was really just a slow coming-to-terms with the fact that I no longer wanted anything to do with it.

I found the complexity I was looking for, but it didn’t have the meaning I’d hoped for.

## So did I learn anything?

I’m not trying to bash all my old projects. I learned a lot. I made some things I’m proud of. But for such a large amount of effort, there are so many ways I could’ve put this effort and energy to better use. So has anything changed? I’d definitely say so—at least I like to think I’m finally failing less—but for someone who codes full-time now, it’s hard to look at my github page and convince myself that I’m actually doing a better job of integrating meaningfully into a larger community of developers. Of course to be frank, that’s not the goal I’m after anyway. Tools are fun to use, learn, and create, but they’re not inherently meaningful. They are means to an end. So my real goal?

## goal:

### communicate passion and knowledge about things I find meaningful

And frankly, I think I’ve been doing a pretty poor job. But I’m trying real hard.