How to keep your code from destroying you

난이도 : 초급

Jeff Vogel, President, Spiderweb Software

2007 년 10 월 23 일

개 발자로서, 시간은 가장 가치 있는 자산이다. 관리가 가능한 코드를 작성하는 방법에 대한 여섯 가지 팁을 배우면 시간을 절약할 수 있고 좌절감에서 극복할 수 있습니다. 주석을 작성하는데 1분만 투자하면, 1시간 동안 분노에 떨지 않아도 됩니다.

깔끔하고, 관리가 쉬운 코드를 어려운 방법으로 작성하는 방법을 배웠다. 지난 12년 동안, 컴퓨터 게임을 만들고 쉐어웨어라고 하는 한때 유명했던 마케팅 기술을 사용하여 넷을 통해서 판매했다. 블랙 스크린에서 시작하여, 코딩을 시작하고, 그 다음에 수십 만 라인의 코드를 작성해야지만, 판매할 수 있는 무엇인가가 생긴다는 것을 의미한다.

소셜 북마크 > >mar.gar.in Digg > >del.icio.us > >Slashdot

다시 말해서, 잘못을 저지르게 되면 온전히 자신의 몫이 된다. 새벽 3시에 버그와 싸우면서, 스파게티 코드 무리들을 보면서, "하나님 아버지, 어떤 망할 자식이 이 같은 쓰레기를 만들었나요?"라고 묻지만, 이 질문에 대한 답은 "바로 나"이다.

따라서, 필자는 제대로 된 프로그래밍 기술에 대해 배우게 되었다. 그 중 일부가 이 글에 소개될 것이다. 숙련되고, 경험이 풍부하며, 도덕적으로 고결한 코더들이라면 기본적으로 이것을 알고 있다. 이 글을 읽고 도움을 받는 사람들은 필자의 유쾌한 작문 스타일을 익힐 수도 있으며, 깔끔한 코드 종교로 개종하기 전의 삶이 얼마나 끔찍했는지를 새삼 느끼게 될 것이다.

필자처럼 예기치 않았거나 비정상적인 방법으로 프로그래밍을 해왔고, 이러한 방식을 한번도 경험하지 않은 사람들도 많이 있다. 이것은 대부분의 사람들에게는 기본적인 것이지만, 어떤 사람들에게는 쓸데 없는 기술이다. 이 글은 더 이상 실수로 모든 것을 엉망으로 만들고 싶지 않는 사람들을 위한 글이다.

예제 케이스

이 글에 사용될 우리의 예제 프로그램은 Kill Bad Aliens라고 하는 가상의 컴퓨터 게임이다. 이 게임에서 우주선을 제어한다. 스크린 바닥에서, 수평으로 움직이면서, 총알을 앞으로 쏜다. 우주선은 키보드로 제어한다.

이 게임은 Waves라고 하는 기간 동안 발생한다. 각 Wave 동안, 스크린 위에서 외계인들이 하나씩 나타난다. 날아다니면서 폭탄을 투하한다. 외계인은 고정된 시간 간격으로 나타난다. 특정 수의 외계인을 죽인 후에 Wave는 종료한다.

외계인을 죽이면 포인트가 생긴다. Wave를 끝내면, 얼마나 빨리 끝냈는지에 따라서 보너스 포인트를 얻는다.

폭탄을 맞으면, 우주선은 폭발하고 다른 것이 나타난다. 세 번 폭발하면, 게임은 끝난다. 높은 점수를 받으면, Valuable이 된다. 점수가 낮으면 그렇지 않다.

따라서, 여러분은 앉아서 C++로 Kill Bad Aliens를 작성해야 한다. 객체를 정의하여, 우주선, 총알, 적, 적들의 총알을 나타내야 한다. 코드를 작성하여 모든 객체들을 그린다. 코드를 작성하여 시간이 흐름에 따라 이들을 이동시킨다. 게임 로직, 외계인 AI, 코드를 작성하여 키보드에서 사용자의 의중을 읽는다.

포괄적이고, 관리가 쉬우며, 제대로 된 코드를 작성하기 위해 우리가 해야 할 일은 무엇인가?

위로

팁 1: 똑똑한 사람답게 주석을 달라.

코드에 주석을 달라. 확실하게! 프로시저를 작성하고, 주석을 달지 않고, 몇 달 후에 재 작업을 위해 코드를 보면, 주석이 없기 때문에 많은 시간이 걸린다. 시간은 가장 귀중한 자원이다. 잃어버린 시간은 돌아오지 않는다.

주석을 다는 것은 하나의 기술이다. 연습하면 더 나아질 수 있다. 좋은 주석이 있고, 나쁜 주석이 있다.

너무 많이 쓸 필요는 없다. 코드를 이해하는데 십분 정도의 시간을 절약해 줄 수 있는 함수에 대해 주석을 단다고 생각해 보자. 좋다. 하지만, 그 주석이 너무 장황해서 쓰는데도 5분이 걸리고, 읽는데 5분이 걸린다면? 정작, 절약된 시간은 0이다. 좋을 것이 하나도 없다.

또, 너무 적게 쓰지 않도록 해야 한다. 코드가 한 두 페이지 정도 중단점 없이 진행된다면, 그 코드가 크리스탈처럼 깔끔하기를 바랄 뿐이다. 그렇지 않다면 미래의 시간 낭비는 자명하기 때문이다.

어리석은 방식으로 주석을 달지 않도록 한다. 사람들이 처음 주석을 작성하면, 지나치게 되어 다음과 같이 쓰게 된다.

// Now we increase Number_aliens_on_screen by one.
Number_aliens_on_screen = Number_aliens_on_screen + 1;

무엇인가 분명하다면, 주석이 필요 없다. 매 줄마다 주석을 달아야 할 만큼 코드가 난잡하다면, 우선은 코드를 단순하게 만드는 것이 더 나은 방법이다. 주석이라고 해서 시간을 절약하게 하는 것은 아니다. 시간이 더 들 수도 있다. 읽는데 시간이 걸리고, 스크린에 실제 코드를 전개하기 때문에, 한번에 모니터에서 검토할 수 있는 부분이 더 적어질 수 있다.

그리고, 어떤 경우에라도 다음과 같이 하지 말아야 한다.

Short get_current_score()
{
	[insert a whole bunch of code here.]

	return [some value];

	// Now we're done.
}

이미 그렇게 한 것은 아닌지? 알려주어서 고맙다. 큰 오른쪽 괄호와 빈 공간의 무한 확장을 필자는 이해하지 못한다. "Now we return a value" 라는 리턴 문에 앞서 주석이 필요 없다.

여러분이 코드를 작성하고 있고, 무엇을 해야 할지에 대해 말해주는 보스나 회사 정책이 없다면, 어떻게 주석을 달 것인가? 필자가 코드를 위해 늘 고수하는 것이 있다면 그것은 머리말(introduction)을 쓰는 것이다. When I return to a procedure I forgot that I wrote, I want to see an explanation for what is going on. 이 기계가 무엇을 하는지 이해하면, 실제 코딩을 이해하는 것이 더욱 쉬워진다. 다음과 같은 것이 포함되어 있다.

1. 이것이 무엇을 수행하는지를 말해주는 프로시저/기능 앞에 몇 줄의 문장.
2. 전달되는 값에 대한 설명.
3. 함수일 경우, 이 함수가 리턴하는 것의 디스크립션.
4. 프로시저/함수 내에, 코드를 더 짧은 태스크로 나누는 주석.
5. 어려운 코드 청크를 위해, 무엇이 발생하고 있는가에 대한 빠른 설명.

따라서 우리가 가는 길에 대한 설명과 사인이 필요하다. 이것은 매우 빠른 길이며, 장기적으로 봤을 때 많은 시간을 줄여준다.

다음은 가상의 Kill Bad Aliens의 예제이다. 플레이어가 발사하는 총알을 나타내는 객체에 대해 생각해 보자. 여러분은 자주 함수를 호출하여 이것을 위로 이동시키고 이것이 무엇을 공격하는지를 봐야 한다. 아마 다음과 같은 코드가 될 것이다.

// This procedure moves the bullet upwards. It's called
//NUM_BULLET_MOVES_PER_SECOND times per second. It returns TRUE if the
//bullet is to be erased (because it hit a target or the top of the screen) and FALSE
//otherwise.
Boolean player_bullet::move_it()
{
	Boolean is_destroyed = FALSE;

	// Calculate the bullet's new position.

	[Small chunk of code.]

	// See if an enemy is in the new position. If so, call enemy destruction call and
	// set is_destroyed to TRUE

	[small chunk of code]

	// See if bullet hits top of screen. If so, set is_destroyed to TRUE

	[Small chunk of code.]

	// Change bullet's position.

	[Small chunk of code.]

	Return is_destroyed;
}

코드가 충분히 깔끔하다면, 이러한 수준의 주석으로도 충분하다. 그리고 이전의 바보 같은 실수를 고치기 위해 함수로 돌아가는 시간도 줄일 수 있다.

위로

팁 2: #define을 많이 사용하라. (LOT가 아니다.)

이 가상 게임에서, 플레이어가 외계인을 맞출 때 10 포인트를 얻는다고 생각해 보자. 이를 작성하는 방법은 두 가지이다. 다음은 잘못된 방법이다.

// We shot an alien.
Give_player_some_points(10);

다음은 좋은 방법이다. 글로벌 파일에서, 다음과 같이 한다:

#define		POINT_VALUE_FOR_ALIEN	10

그리고 나서, 일부 포인트를 포기하면, 다음과 같이 작성한다.

// We shot an alien.
Give_player_some_points(POINT_VALUE_FOR_ALIEN);

대부분의 프로그래머들은 이와 같이 하는 것을 알고 있다. 하지만, 이를 충분히 활용하려면 훈련이 필요하다. 상수를 정의할 때, 이것을 하나의 중앙 장소에서 정의하는 것을 심각하게 고려해야 한다. 예를 들어, 플레이 영역이 800x 600 픽셀이라고 가정해 보자. 다음과 같이 해야 한다:

#define PIXEL_WIDTH_OF_PLAY_AREA	800
#define PIXEL_HEIGHT_OF_PLAY_AREA	600

나중에, 게임 창의 크기를 변경하려면, 이러한 한 지점에서 값을 수정할 수 있다면 시간을 두 배로 절약할 수 있다. 우선, 플레이 영역 넓이가 800 픽셀인 곳을 찾아 코드를 검색할 필요가 없다. 두 번째, 여러분이 예외 없이 놓치게 될 레퍼런스에 의해 예외 없이 발생하는 버그를 픽스할 필요가 없다.

Kill Bad Aliens 작업을 할 때, 한 Wave를 끝내기 위해 얼마나 많은 외계인들을 죽여야 하는지, 스크린에 한번에 나타나야 할 외계인의 수, 이들이 나타나는 속도를 결정해야 한다. 예를 들어, 모든 Wave에서 동일한 수의 외계인들이 같은 비율로 나타나게 하려면, 다음과 같이 작성한다.

#define		NUM_ALIENS_TO_KILL_TO_END_WAVE	20
#define		MAX_ALIENS_ON_SCREEN_AT_ONCE		5
#define		SECONDS_BETWEEN_NEW_ALIENS_APPEARING	3

매우 명확하다. 나중에, 이 Wave가 너무 짧거나 외계인들간 시간이 너무 빠르면, 이러한 값을 조정하고 즉각적으로 게임의 밸런스를 맞춘다.

이와 같이 게임 값을 설정하는 것의 한 가지 장점은 빨리 수정하는 기능이 더 많은 재미를 가져다 줄 수 있고 여러분이 마치 신처럼 느껴지게 할 수 있다. 예를 들어, 위 내용을 아래와 같이 변경할 수 있다:

#define		NUM_ALIENS_TO_KILL_TO_END_WAVE	20
#define		MAX_ALIENS_ON_SCREEN_AT_ONCE		100
#define		SECONDS_BETWEEN_NEW_ALIENS_APPEARING	1

이렇게 되면 재컴파일만 남는다.

그런데, 위 값에 대한 어떤 주석도 작성하지 않았다. 이들의 의미가 변수 이름에서 명확하기 때문이다. 다음 포인트로 넘어가 보자.

위로

Tip 3: 여러분을 모방할 변수 이름을 사용하지 말라.

전체적인 목표는 단순하다. 누군가가 코드가 의미하는 것이 무엇인지 모를 때 빠르게 이해할 수 있도록 코드를 작성하는 것이다.

이러한 목표를 달성하는 한 가지 핵심 전략은 변수, 프로시저 같은 설명적인 이름을 제공하는 것이다. 누군가가 변수 이름을 보고, "이것이 무엇인지 알았다.."라고 말한다면, incremeter_side_blerfm이 무엇을 의미하는지에 대한 단서를 찾기 위해 프로그램을 검색하는 5분의 시간이 절약되는 것이다.

여기에서 균형을 잡아야 한다. 사람들이 이해할 수 있을 정도의 길이와 명확성을 가진 이름을 부여해야 하지만, 너무 길거나 어색해서는 안된다.

예를 들어, 실제로 필자는 이전 섹션에서 상수 이름을 제공했다면 상수 이름을 제공하지 않았을 것이다. 이렇게 하는 이유는 독자들이 어떤 정황 없이도 그 의미를 이해할 수 있도록 하기 위함이다. 대신, 프로그램 정황에서는:

#define		MAX_ALIENS_ON_SCREEN_AT_ONCE		5

의심할 여지없이 다음과 같이 쓴다:

#define		MAX_NUM_ALIENS		5

더 짧아진 이름 때문에 생긴 혼란이 매우 빨리 가셨고, 더 짧아진 이름으로 더욱 가독성 있는 코드가 만들어졌다.

이제, 스크린 주위를 자주 돌아다니도록 하는 코드 스니펫을 생각해 보자. 다음과 같이 작성하게 될 것이다.

// move all the aliens
for (short i  = 0; I < MAX_NUM_ALIENS; i++)
	if (aliens[i].exists()) // this alien currently exist?
		aliens[i].move_it();

모든 외계인의 어레이는 aliens라고 한다. 완벽하다. 필자가 무엇을 원하는지를 정확하게 설명하고 있지만, 큰 어려움 없이 짧은 시간에 타이핑 할 수 있을 정도로 짧다. 이것은 LOT를 사용하는 어레이일 것이다. 이것을 all_aliens_currently_on_screen이라고 한다면, 코드는 10마일 정도로 길어질 것이다.

마찬가지로, 필자는 추가 주석 i 없이 루프 변수라고 했다. 처음, 전체적인 설명 변수 이름에서, 이것을 "카운터" 또는 이와 비슷한 것으로 부르고 싶어질 수도 있다. 하지만 꼭 그럴 필요가 없다. 변수 네이밍의 핵심은 독자가 그 의미를 즉각적으로 알 수 있도록 하는 것이다. 이것이 "i", "j" 같은 것으로 불린다면, 모든 사람들은 이것이 루프에 사용된다는 것을 알 것이다. 어떤 설명도 필요 없다.

물론, 이보다 더 변수 네이밍에 신경을 쓸 수 있다. 예를 들어, Hungarian Notation이라고 하는 것이 있다. 이것의 기본적인 개념은 변수 이름 앞 부분에 태그를 달아서 그 유형을 알리는 것이다. (따라서, 모든 서명되지 않은(unsigned) 긴 변수들은 ul로 시작한다.) 이는 약간 더 까다롭지만, 여러분도 알아두어야 한다. 무엇인가를 단순하게 하기 위해 더 많은 시간을 보낼 수 있지만, 더 많은 노력이 든다.

위로

팁 4: 에러를 검사하라. 에러는 여러분이 만든다.

이것이 알맞은 크기의 프로그램이라면, 많은 함수와 프로시저가 있을 것이다. 이들 각각에 대해 에러 체크를 수행해야 한다.

여러분이 프로시저/함수를 생성할 때, "어떤 정신 나간 사람이 말도 안되는 값을 전달할 수 있다. 이렇게 형편없는 코드로는 방어할 수 없고 컴퓨터를 지킬 수 없다."라는 것을 언제나 생각해야 한다. 그리고 나서, 이상한 데이터로부터 방어할 코드를 작성한다.

여기 한 가지 예가 있다. 우리의 우주 게임의 주요 목표는 외계인을 죽이고, 포인트를 얻는 것이기 때문에, 점수를 수정하는 프로시저가 필요하다. 더욱이, 포인트가 추가되면, 점수에 스파클을 그리는 루틴을 호출해야 한다. 다음은 첫 번째 패스이다.

Void change_score(short num_points)
{
	score += num_points;

	make_sparkles_on_score();
}

지금까지는 좋다. 이제 스스로 물어보라. 잘못된 것은 없는가?

먼저, 확실한 한 가지가 있다. num_points가 음수라면? 플레이어의 점수가 내려가도록 하고 싶은가? 그렇다면, 이것이 가능하다. 하지만, 점수를 잃도록 언급한 게임 디스크립션은 없었다. 게다가, 게임은 재미있어야 하고, 점수를 잃는 것은 전혀 재미있지 않다. 따라서, 음수 포인트를 에러로 간주하고 이를 잡아야 한다.

이렇게 하는 것은 쉬웠다. 하지만, 보다 미묘한 문제가 있었다. (그리고 이것은 필자의 게임에서 늘 다루어야 했던 문제이다.) num_points가 0이라면?

이는 매우 가능한 상황이다. 플레이어가 얼마나 빨리 게임을 끝내는지에 따라서 모든 Wave의 끝에 보너스를 준다. 플레이어가 지나치게 느리다면? 이와 같은 상황에 보너스 0점을 주기로 결정했다면? change_score를 호출하고 0을 전달하기까지 새벽 3시에 끝난다.

여기에서의 문제는, 디스플레이 된 숫자가 바뀌지 않을 때 예쁜 색깔로 반짝거리는 스코어보드를 원하지 않는다는 것이다. 따라서, 우리는 이 문제를 해결해야 한다. 다음 코드를 실행해 보자.

Void change_score(short num_points)
{
	if (num_points < 0)
	{
		// maybe some error message
		return;
	}

	score += num_points;

	if (num_points > 0)
		make_sparkles_on_score();
}

훨씬 나아졌다.

그리고, 이것은 매우 단순한 함수였다는 것을 주목하라. 멋있거나 새로운 포인터들이 전혀 없다. 어레이나 포인터들을 전달한다면, 에러나 잘못된 데이터를 더욱 잘 관찰할 수 있다.

이렇게 하는 것의 이점은 프로그램이 망가지는 것을 방지하는 것을 끝나지 않는다. 좋은 에러 체크는 디버그도 빠르다. 일부 어레이 영역 밖에서 데이터를 작성하고 있다는 것을 안다면, 이것이 어디에서 발생하는지를 찾으면서 코드를 검사한다. 모든 에러 체크가 순서대로 수행되는 절차를 찾으면, 실수를 찾기 위해 이를 검사하는데 시간을 보낼 필요가 없다.

이는 수 많은 시간을 절약해 주고, 반복되지 않도록 해준다. 시간은 가장 귀중한 자원이다.

위로

팁 5: "섣부른 최적화는 모든 악의 근원이다." - Donald Knuth

위 문장은 필자가 지어낸 말이 아니다. Wikipedia에서도 나와있기 때문에 믿어도 좋은 말이다.

사람들을 고통스럽게 하려는 것이 아니라면, 코드를 작성할 때 여러분의 최우선 목표는 명확성(clarity)이어야 한다. 간단한 코드는 작성하기도 빠르고, 나중에도 이해하기도 쉽고, 디버그도 빠르다.

최적화는 명확성의 적이다. 가끔씩, 최적화를 할 필요가 있다. 특히, 게임에 있어서는 더욱 그렇다. 하지만, 이것은 중요한 포인트이고, 실제로 코드를 작동시키고 이를 프로파일러로 테스트 하기 전까지는 무엇을 최적화해야 하는지를 대부분 모르고 있다. (프로파일러는 프로그램을 감시하고, 다른 호출들을 사용하는데 얼마나 많은 시간이 걸리는지를 파악하는 프로그램이다. 매우 놀라운 프로그램이다. 사용해 보기 바란다.)

필자의 게임들을 최적화 할 때마다, 반드시 날벼락을 맞았다. 필자가 가장 걱정했던 코드는 늘 좋았다. 전혀 걱정하지 않았던 코드가 매우 느렸다. 무엇이 빠르고 무엇이 느린지 전혀 알지 못했기 때문에, 실제 데이터를 얻기 전에 모든 최적화 시간은 낭비 그 자체였다. 낭비보다 더 나쁜 것은 코드를 엉망으로 만든다는 것이다.

이것은 따르기 힘든 규칙이다. 만약 쉬웠다면, 규칙이 될 필요가 없었지만 말이다. 훌륭한 프로그래머는 더 빨라질 수 있는 보기 흉한 코드로 공격을 당하는 경우가 있다.

하지만 기뻐하라! 이를 수행하는 방법을 알면 이것은 드물고도 귀중한 시간이 될 것이다.

깨끗하고 작동하는 것을 작성하라. 최적화는 나중에 생각하라. 하지만, 올바른 일을 하고 있다는 것을 확신하기 전까지는 최적화를 시도하지 말라.

이제, 마지막 충고가 하나 남아있다.

위로

팁 6: 너무 똑똑해지지 말라.

IOCCC라고 하는 것이 있다. "International Obfuscated C Code Contest"를 뜻하는 것이다. C와 C++이 매우 복잡한 코드를 만든다는 것은 여러분도 알고 있다. 이 콘테스트는 비정상적인 것에 상을 줌으로써 명확한 코드의 가치를 드러내고 있다. 매우 놀랍다.

프로그래밍 언어에 대한 해박한 지식으로 얼마나 일을 크게 그르칠 수 있는지를 알아둘 필요가 있다. 이것을 충분히 알고 있다면, 열 줄의 코드를 한 줄로 만들 수 있다. 여러분은 아마도 버그를 픽스할 수 없게 될 것이다.

여러분이 작성하는 코드는 이전의 복잡한 규칙에 대한 상세한 지식이 필요하거나 책을 뒤적이며 무엇을 하고 있는지를 파악하고 있다면, 여러분은 너무 똑똑해 지고 있는 것이다.

모든 사람들은 코드 복잡성에 대한 어느 정도의 인성을 갖고 있다. 필자도 개인적으로, 전형적인 할머니들이 운전하는 것 같이 프로그램을 작성한다. 필자가 알고 있기로는, 여러분의 C 코드도 i++와 ++i의 차이를 알아야 할 것을 요구한다면, 이는 매우 복잡해진다.

필자가 소심하다고 생각할 수 있다. 여러분이 맞다. 하지만, 이런 방식을 통해서 코드를 더욱 빠르게 이해하고 있다.

위로

결론

이쯤에서, 여러분은 "휴, 이것은 시간 낭비였어. 모든 사실은 내가 다 알고 있는 것이었어. 왜 이런 글을 쓰는 거야?" 라고 말할 생각할 수도 있겠다. 정말 이렇게 생각하기를 바란다. 여러분이 똑똑하다는 증거니까 말이다.

하지만, 이 모든 것을 모든 사람이 다 알고 있는 것은 아니다. 잘못된 코드가 언제나 작성되고 있다. 그러한 방식으로 해서는 안 되는 데도 말이다.

여러분이 많은 코드를 작성하고 있고 이것이 여러분을 파멸시키지 않게 하려면, 이 글에서 도움을 얻기 바란다. 단순하고, 명확하게 유지하면, 많은 시간을 절약할 수 있다.

참고자료

• Hungarian Notation의 다양한 특징: Wikipedia.
  
  
• 프로파일러
  
  
• Obfuscated C 콘테스트 우승자 엔트리
  
  
• 관리가 쉬운 코드를 만드는 17개의 팁: Bram Cohen(관리가 쉬운 코드를 작성하는 방법 9, Sean Kelly(더욱 관리가 쉬운 코드 6), Joel-on-software(더 나은 코드를 위한 12 단계).
  
  
• 100 tongue-in-cheek anti-tips : Roedy Green "How to write Unmaintainable Code (Humorous Article)."
  
  
• 필자가 만든 게임들
  
  
• 필자가 쓴 아티클들
  
  
• developerWorks 리눅스 존, 리눅스 튜토리얼, 지난 달의 인기 리눅스 기술자료와 튜토리얼 (영문).
  
  
• developerWorks 기술 이벤트와 웹캐스트.

• 리눅스용 SEK 주문: DB2®, Lotus®, Rational®, Tivoli®, WebSphere®에서 제공하는 리눅스용 IBM 소프트웨어 평가판(DVD).
  
  
• IBM 시험판 소프트웨어
  
  

• developerWorks 커뮤니티: 개발자 블로그, 포럼, 팟캐스트, 커뮤니티 토픽과 developerWorks spaces.
  
  

필자소개

		Jeff Vogel은 1994년부터 Spiderweb Software를 운영했다. Windows와 Macintosh용 롤 플레잉(role-playing) 게임을 만들었으며, 이 중에는 Exile, Avernum, Geneforge 등이 있다. The Poo Bomb: True Tales of Parental Terror의 저자이다. 현재 시애틀에 거주하고 있다.