Evil Stick Blog

Somewhere along the line I read an article (I think it was on http://www.joelonsoftware.com, but I can’t be sure) that stated that it takes a new programmer anywhere from 6 months to a year to become fully productive and competent in a new environment. In my experience this has been pretty accurate. Mind you I’m not saying that you can expect a new programmer to sit there with his thumb up his ass for 180 days - far from it! It’s just that there’s a certain amount of sluggishness in their work as they flounder in the unfamiliar code, finding their way around much as a new citizen would wander the town without a map. I typically take 4-6 months before I feel competent enough in a system to have strong opinions about its general function. Of course I’ll have made contributions by then - with my past jobs I’ve typically had functional code released within the first two weeks (depending on the company and the release cycle) - but inexperience with the system coupled with a need to discover the lay of the land tend to put a dampening effect on my desire to rock the boat.

My new position has been more of the same, so far, but with this being my fourth company over the past 5 or so years, I’m starting to notice some patterns:

Whether or not you realize it, you are being unconsciously judged by your coworkers based on how long it takes you to pick things up.

This is not something that will necessarily be set in stone for the duration of your employment, but it can color many of your early interactions. Of course you never exactly know how you measure up, not until it’s too late to change anything, but you can gauge your progress based on interactions with coworkers. Call it the “time to guru rapport” measurement - every company has its guru programmers, the guys that have been there since the beginning and know everything there is to know. The sooner you are on a comradely level with a majority of them, the better you are doing.

A coherent, well-documented code architecture is invaluable to ramping up new programmers.

80% of your development time should be spent in design. The architecture of a system is by far the best indicator of an organization’s dedication to code quality. It’s also the first evidence that a new developer will see of the type of coding environment at your company - will that neophyte see a culture that praises re-use and judicious application of patterns in a logical manner? Or will they see five solutions to the same problem written under a looming deadline?

No matter how intuitive something looks, it is not as intuitive as you think it is.

Everyone comes from different perspectives. Coworker A may have 5 years in .NET, coworker B 6 years in LISP, and you’re all writing in FORTRAN. What passes the “5 minute” test with you may not do so for someone used to a different idiom. What’s obvious in functional programming may be anathema in procedural programming (we’ll hold the “FP makes coders better” discussion at another time), and what seems like the simplest thing in the world may be a foreign concept to the most surprising of people.

There’s no such thing as too many comments for a programmer stumbling his way through a new system.

It doesn’t matter how ridiculous your current programmers think comments are. “Preposterous!” they say, “Good code comments itself! Anyone who can’t grasp this is a moron!” The question we need to ask ourselves is that if our organization is spending $50 an hour on a programmer, and one comment that takes thirty seconds to write can reduce their ramp-up time by an hour, how can you not write comments? I have yet to hear a decent argument that convinced me that there is any such thing as too many comments in the code - at the absolute worst, you lose nothing by having them (no matter how unnecessary they seem).

You can tell about a company’s commitment to code by the discussions that take place around its architecture.

If you kick off projects without an architecture meeting, you’re doing things wrong. It may seem like too corporate a model for your company, but keeping the knowledge of the overall program structure in the head of two or three people leads only to labor duplication. Conversely, multiple discussions for a simple service may point to a process that is too top-heavy.

Process is good if it is well thought-out, but process for the sake of process is overkill.

Having a clear sequence of steps from conception to realization is invaluable. On the flip side, though, one page of documentation per line of code is excessive. Similar to the previous item, balance is key in this area.

One can tell if a development shop is a firehouse with the answer to one simple question

“Was my workstation ready to go when I got to my desk?” An oversight such as this says more about the company than any two of these points combined. If your infrastructure group is not on the ball enough to have desks configured for new employees, or if there is not some process built up around onboarding, you’re sending a message that you like to fly by the seat of the pants and get things done quickly as opposed to getting things done well.

Firehouse development, while edge-of-your-seat cool, doesn’t lead to good code.

Every office has a hero - that guy who’s in until 4 AM, on his second pot of coffee working towards a release. Does your environment encourage this style of development? Many people have pointed out the negative correlation between hours worked per week and code quality, but organizations still persist in encouraging long hours in development with shortened schedules. The only time a programmer should be pulling 12 hour days is if something is metaphorically (or sometimes literally, depending on your job description) on fire. Any other time and it’s a failure of management, process, or both.

In any case, these are the things I tend to notice. What do you people look for in your first couple weeks on the job?

This morning I came up with an answer to a programming/logic question I was given during an interview back in early February. Before going into the rest of it, let me give the problem (and the solution I belatedly derived):

Problem: Given a dimension n, output an array that represents an n x n matrix of numbers beginning at (n*n)-1 and decreasing to 0. The numbers must be output in such a manner as to “wrap around” the resulting matrix, and must be output as a single array. For example, if the function is given the number ‘3′, the output will be as follows:

8, 7, 6, 1, 0, 5, 2, 3, 4

Which is a linear, row-major representation of the matrix

8, 7, 6

1, 0, 5

2, 3, 4

You may not pre-calculate the matrix and index into it, nor may you store an array of results and index them based on the dimension. In other words, you need to develop a function that, when given a position (i, j) and a dimension n, outputs the appropriate value for (i, j).

My solution:

int calc(int i, int j, int n)

{

  if(i == 0 || j == (n-1))

  {

    return ((n*n) - 1 - i - j)

  }

  if(i == (n-1) || j == 0)

  {

    return (((n-1)*(n-1)) - ((n-1) - j) - ((n-1) - i))

  }

  if(n > 2)

  {

    return calc(i-1, j-1, n-2)

  }

  // should never get here

  return 0

}

Explaining the solution:
I don’t claim that this solution is optimal, or that this solution is the “right” solution. All I can say for it is that when I worked out the “wrapped” matrices for several dimensions and then ran those resulting matrices cell-by-cell through the above algorithm the results matched, meaning that if nothing else the function above successfully takes a coordinate input and returns the “wrapped” value. Indeed, if anyone has a better solution to the problem, please let me know!

One of the first things that should be obvious in this solution is the recursion (when n > 2), and I figure that deserves some explanation. If you write out several examples, you start to notice a pattern. For example, take a look at the matrices for n = 3 and n = 5:

            24, 23, 22, 21, 20

8, 7, 6,     9,  8,  7,  6, 19,

1, 0, 5,    10,  1,  0,  5, 18,

2, 3, 4     11,  2,  3,  4, 17,

            12, 13, 14, 15, 16

The larger dimension, n = 5, actually contains the matrix for n = 3 verbatim. In fact, this is true of all odd and all even dimensions - the matrix for n = 6 contains n = 4, and the matrix for n = 7 contains both n = 5 and  n = 3 (I’ll leave it to you to work out these matrices to see that this is true). So the recursion needs to occur on n -2 in each case, to move to the next odd or even dimension as applicable. A dimension of 1 outputs 0 in a single location, and a dimension of 2 outputs the matrix 3, 2, 0, 1 as expected given the above conditions, meaning that the guard against n > 2 is unnecessary, but I felt uncomfortable leaving it out.

Once you figure out the recursion, you then need a means to calculate the “border” values. The two equations you see above are the results of two or three hours of deliberations and testing by hand. There is a division between how you count each edge - the top and rightmost edge use one formula, while the bottom and leftmost edge use another. This is reflected in the two conditions above. (I originally wrote it out as four separate conditions, but condensed it into 2). The conditions check only for the edge cases - when i = 0 (top edge), when j = 0 (left edge), when i = n-1(right edge, or when j = n-1 (bottom edge).

OK, so what’s the big deal?
This problem has been bothering me for almost two months now. It was something I should have been able to do (and, indeed, I was eventually able to do it), and I’m pretty sure that my inability to provide the complete answer during the interview resulted directly in me not getting the job (especially considering I nailed the technical portion of the interview). More than that, though, it exposed a worry that I had that I was actually losing intelligence as I age. I felt strongly that I should have been able to solve it sooner, and indeed some anxiety as a result of this internal assertion probably led to my inability to provide the complete solution during the interview. That and the general stress of interviewing with a company whose phone screen was so technically intense that anyone who could make it into their offices for the in-person pretty much officially Knows Their Stuff (or so I’m told).

This problem bugged me so much that I spent time solving it while on vacation, sitting around with graph paper and a pen while my family socialized around me. For some reason I let this one problem, this one failed interview get to me in a very primal way, and I’ve been wracking my brains trying to figure out why I just couldn’t get over it. I tied my ability to solve problems (which, as a programmer, is pretty much my bread and butter) to my self-worth, and became slightly obsessed as a result. Indeed the obsession is still fading - half the reason for this post is the hope that someone out there in internet-land has a better solution, or at the very least can confirm my efforts!

One of the biggest problems any coder looking for work has is in proving themselves. Companies are looking for programmers who know what they claim to know, who aren’t bullshitting the interviewer into a job they’ll be forced out of in 6 months due to incompetence. Furthermore, many companies ascribe to the philosophy that a great programmer is many times more productive than a mediocre programmer (a philosophy I don’t necessarily disagree with, but more on that later) and thus orient their screening process towards ferretting out these artisans of ascii. This basically boils out into one of three interview patterns:

1 - The candidate is subjected to several intense hours of technical interviews covering topics ranging from mathematics to algorithms to data design
2 - The candidate is subjected to a programming or logic test designed to be unique enough so as not to be easily searchable on the web and to test the candidate’s ability to both work under pressure and produce excellent code
3 - The candidate is subjected to both pattern 1 and pattern 2.

The problem faced by the companies, of course, is that there are a lot of people out there who would attempt to subvert the interview process by learning a few buzzwords and faking their way through the process. As a result, these charlatans have caused the rest of us decent people trouble and made companies highly selective.

The problem faced by the job candidate, though, is more insidious. First off, some people (I am not one of them, but I can understand the mindset) take offense at having to take coding tests, thinking that their years of experience and stellar references should be adequate proof of their ability. Second, these kinds of problems can have a profound effect on the job candidate, and can affect the course of the interview. Sure, throwing a curve ball at someone is a good opportunity to judge how they react to adverse situations, but with programmers (and problem-solvers in general), if they get this kind of thing wrong, or even worse if they can’t solve it at that time, this problem will work itself into their psyche, DEMANDING that it be solved, and will take a measurable toll on the individual as they obsess about the problem while trying to continue to answer the interviewer’s questions as they move on to other areas, and in the end this kind of problem colors the company’s perception of the candidate in a manner disproportionate to the applicability of the skills involved to the job being applied for. Third, these kinds of problems have yet to demonstrably select the “best” candidate for the job. The skills used to solve logic puzzles are not necessarily those used to solve programming problems, and 95% of any programmer’s job is not going to require thought of that order at all. Take Microsoft, for example - they are notorious for using these kinds of interviewing tactics and as a result they do write some very good code, but they also make some of the most horrific blunders in code and application design known to man.

Probably the biggest problem with this kind of interviewing pattern, though, is that every worthwhile company has their own problem or three, and every worthwhile company thinks that pushing their candidates through the technical interview/logic/coding problem wringer results in getting the best of the best. Each and every company prides themselves on having the best and the brightest, evidenced by how well these individuals did on their tests. This calls into view a white lie that recruiters tell themselves - that there are more bright people than there are job openings. Any person of moderate intelligence can do the math and realize that the number of positions governed by hiring managers employing these tactics exceeds the statistically probable numbers of “best and brightest”. Not everyone gets to be an astronaut, and there are a lot more fry cooks than there are rocket scientists. But most importantly of all, these managers and these companies ignore one of the brutal truths of programming in general: 95% of coding is performing the equivalent of menial labor, the kind of tasks that you could train a monkey to perform if you had the time. No matter how intelligent your programmers are, their intelligence is largely wasted if all they do is implement specs. For every person developing an algorithm for an autonomous combat drone, there are dozens squirreled away in a cube farm updating corporate software for the next big product switch, changing enumerations occasionally throughout the code, or hunting down an elusive typo.

As a job seeker, there’s not much we can do except rail against the system quietly after we’ve already gone through the wringer and found that next employer. The only means to change this process come when you have power that is typically granted to people that don’t have Computer Science anywhere in their credentials, and even then a significant portion of technical manners swear by the “beat down” method of interviewing. For myself, all I can do is know that I am competent, that given enough time I can perform 95% of coding tasks in the business world, and that no matter what my inability to solve a problem is much more easily explained by stress than by a phantom loss of intelligence.

Note that this is not an indictment of my current employer. Yes, I had to take a coding test when I was interviewing with them, but they also had one of the least BS-laden interview processes I’ve ever been through. I only wish the rest of the companies I interviewed with had been as straightforward. All I’m really doing here is releasing some pent-up aggression from my job hunt in the form of an internet rant. Not really effective, but it does help me feel better Anyway, I’m done with the incoherent ramble.

Kilties 2009 Open house has come and gone. I’m not exactly sure how to feel about it. On the one hand, my physical preparation definitely paid off in spades - I was able to control the horn better, had better endurance, and didn’t have nearly as much arm pain this year as I have in years past. So if nothing else, I’m definitely more physically fit than I have been before.

The other side, though, is two new experiences that I went through this weekend. First, I moved up to 1st bari to give it a shot. It’s a bit outside my range now, but I’m hoping that if I work my ass off over the next couple months I’ll be able to manage the show range-wise come January. As it went yesterday, I did OK for about the first 15 minutes, but then repeated Ds above high C wore me out quickly. I’m kind of facing the same problem I had on trumpet - no problems at all with technical stuff or with rhythms, but lots of trouble with endurance and range. Of course I’m told by several people that the opener for this year is a lot tougher on the baritones than it was last year, so I suppose that should be taken into account. In any case I’ll definitely be busting my ass to improve my range and tone quality before January Camp.

The second experience was my first weekend as a staff member. After last season, Scott wanted to make some changes in how we handle staff. Mainly he felt that he wasn’t getting enough commitment from the staff he had at the time, and furthermore that some of the membership was doing a better job teaching things that he could see than the staff he had. So he’s trying something new this year - pulling most of the staff from within the corps itself. Horn and visual techs, percussion techs, and guard staff are all marching members (with one or two exceptions due to physical limitations). There are still non-marching staff members - coordination and big-picture tower stuff necessitates the person teaching that caption not be in  the line - but most of the winter program is being conducted by members themselves. I was fortunate enough to be chosen as a visual tech for the brass line. This basically means that I get to teach the entire visual program, and lead basics and visual sectionals.

So anyway, this weekend was my first camp as visual staff, really my first camp as any kind of staff member. We had spent several weeks discussing the finer points of the visual program among ourselves (things like “The arms shall form a 120 degree triangle, the weight shall be 60% forward, etc), which I then got the opportunity to present to the corps during basics blocks this weekend. The main problem we’ve had as a corps is that so far we’ve had a different visual program every year that I’ve marched. Unfortunately, that includes this year. As we had our staff meetings in October and November, we came to a consensus that there were some things in last year’s visual program that just weren’t working as well as they could. So we made a series of small changes that ended up amounting to some major-ish changes in how the hornline presents itself. The core philosophy presented last year by the visual staff is still essentially the same - movement initiates from the center of the body, emphasis is on moving the center about as opposed to reaching for positions - but some of the particulars are changed. In particular, what we’re emphasizing is almost an alternative way to think of marching in that instead of stepping with the left foot, we’re pushing off with the other foot. Some stuff we are changing - for example, we’re pulling the corps down off the platform some on the backwards march. This is to make the program more accessible, and to improve balance and maneuvering among those who may be having trouble in the first place. But the main concept of the movement is the same - the center of the body has always been the focus of the movement - it just may never have been adequately stated to the corps.

But I’ve digressed a bit, I think. As I mentioned, this was the first weekend, which means that I was essentially responsible for teaching the corps the new visual program. This also means that, from a certain perspective, the staff’s changes are MY changes. The new program is MY new program. Some of the stuff we’re doing with the upper body is quite different from what the corps has done in the past (but not that different from how most DCI corps do things today), and it showed as I tried to teach it. It was almost as if I could feel a “WTF is this?!” gravitating off everyone in the line.

It’s kind of weird, because from one perspective I know that I’m perpetuating a problem that the corps has had in the past - a visual program that changes from year to year - but from another perspective I’m really just doing what I can to push the program that pretty much the entire staff agreed upon. Yeah, it sucks to have to change every year, and for this to be just another year in the sequence, but we’ve got to be honest with ourselves - every visual person has a different idea of what’s “modern,” of what “looks good,” of what is “old school” much as most brass staff have differing ideas of a hornline’s characteristic sound. By virtue of having changed visual staff every year I was there (Chad Quamme in 2007, Andy Brady in 2008, Myself, Terry and Scooter in 2009) you’re going to see changes in the program. The trick then becomes one of staff retention. If the staff doesn’t change from year to year, the visual program won’t change from year to year either. It really isn’t change for change’s sake in that case, it’s more along the lines of “Look, you hired me to teach to the best of my ability, and this is what I know how to teach.” The best case for a group like the Kilties is to have a consistent staff year in and year out. If the staff doesn’t change, then the main program itself doesn’t change. My view is that staff retention leads to program stability, and I think that a lot of people can agree with that.

In any case, as a staff member this year, I feel two impulses. One, I have to overcome the frustration/reticence/irritation at yet another visual program change as I teach, and two, we as a staff need to settle on something that will change as little as possible. As a person who is new to teaching anything, I feel a little bit out of my depth taking this on. I know that what I’m presenting is well thought-out and well-reasoned (even if some people disagree with it), but because I’m inexperienced I have no way of knowing if I’m doing an effective job of getting this across. One of my biggest concerns is that the hornline comes away from visual sections thinging that I’m throwing this stuff at them completely at random. I think most of this is in my head, though. All I can really do is offer open communication on any issues the members have, and be confident in my own abilities in the end. Some people won’t like the things I’m presenting, and if I can change their mind that’s great. Some people don’t think the staff model is the right way to go, and they’re entitled to their opinion. I can only hope people keep an open mind and discuss their concerns before using them as a reason for leaving the organization.

My work is cut out for me. From what I’ve been told, we’re doing a lot more communication as a staff this year than has been done in years past. Being new to this I don’t have any basis for comparison, so all I can do is make sure I know everything I can ahead of time. Time to buckle down.

Surely you remember the French and Indian war. Even though that was technically a loss for the colonies, we were able to snag a small amount of territory in the extreme north of Canada, as they were distracted by a raid in Montreal (we were attempting a long-term pincer tactic - by the time they figured out our plan on coming from the north, it’d be too late). No bigger than 36 miles square, but it was enough for our purposes. At that time we didn’t have a flag of our own to plant, still being under british rule, so instead we put up a striped pole to indicate cooperation of the old (the red, Britain) and the new (the white, the pure, American colonies). In this territory we set up a small arms-manufacturing venture, as due to our sheer distance from standard supply lines the soldiers needed to re-arm and resupply themselves. They had a lot of help from the local population - a tribe of small, compact humanoids who scraped a living hunting reindeer and caribou - who proved to be a mighty boon to our productivity. They were actually a splinter tribe from the main Eskimo population of what is now Alaska, popularly known at the time as the Eskimo Liberation Front (ELF, for short).

Well the war ended in 1763, just as the northern production base was getting under full steam (back in those days, they took a long view of things). When the soldiers received the message, they promptly abandoned the facility at the “north pole” (as it came to be known) and began the long journey home. All, of course, with the exception of one redcoat Sergeant, a Christopher Nicholas Kringle, who had discovered a home among the Elves and the frigid north. He had also fallen in love with one of the Elves, and was married according to their custom (the exact ceremony is lost to time, but is thought to involve snow sculptures augmented with coal and carrots). With his new bride and tribe, he realized that a weapons production facility isn’t the best place to raise a family, so he had the entire facility converted into a toy shop and bakery. Within a few years he became renowned for both endeavors - for his high-quality wooden toys, and for his Danish Kringles (named after the cook who invented them - Dana, an ELF of great renown, and for the proprietor that gave him the means to create such delicacies - Sgt. Kringle).

After a while, though, the price of base foodstuffs became too much to justify the supply train the North Pole workshop regularly received, so he sold off his bakery to some Scandanavian merchants, who promptly went on to make a name for themseves in the pastry business. After this, the North Pole kind of fell off the map, so to speak, as due to their self-sufficiency they didn’t have much need of the standard traders, who after a while just stopped coming. Memory of the area slowly faded until one fateful Christmas, twenty years later, when Chris Kringle (or Sgt. Nick as he liked to be known) made a visit to the Colonies bearing the fruits of 20 years of ELF toy-making labor. Having had a hard journey, he was so overjoyed at his arrival that he gave away most of his toys for free to celebrate.

Thus we have the true origin of Christmas. Sgt. Nick, over time, has lost the ‘g’ in his appelation, to become St. Nick, and the whole world knows the joy that Chris Kringle’s toys can bring to unsuspecting tots. Now you know, and knowing is half the battle.

With the “z” ’cause they’re edgy. Not really, though.

Upgraded wordpress, added themes, expanded my massive advertising campaign. Ads are put there in the hopes that some kind sole deigns to click on them, but I really only put them there in a “just in case” kind of manner. I don’t necessarily like them (see my earlier rant regarding advertising), but if they make me money who am I to complain. For those of you reading this on facebook, check out http://evilstickman.com/blog/ to see what exactly I’m blathering about.

Most websites run off all this fancy web code that I don’t really know. It’s not hard, I’m sure, to pick up - I just don’t really have the time or anything. That and I lack the type of artistic vision required for a really coherent web design. You want a pixel shader, fine, no problem. You want a coherent color scheme, go ask someone else - I am as good with colors as I am with oil, which is to say I am not good at all

I’ve got a 41-hour playlist at work, but for some reason I tend to skip
through large portions of it (even though I like pretty much everything that
I’ve got on it). Here are the songs I tend to stop on:

- Africa by Toto
- Tank! by The Seatbelts w/ Yoko Kanno
- Country Road by Maynard Ferguson
- Black Hole Sun by Soundgarden
- Interstate Love Song by Stone Temple Pilots
- 16 Tons by Bluegrass Student Union
- Coney Island Baby by Bluegrass Student Union
- Simon and Garfunkel Montage by Acoustix
- Celebration by Phillip Sparke, performed by Tokyo’s Kosei wind ensemble
- Irish Tune from County Derry by Percy Grainger (unknown who performed it)
- Beginnings by Chicago
- The Hummel Trumpet Concerto performed by Wynton Marsalis
- Country Band March by Charles Ives (also unknown who performed it)
- Drive by Incubus
- Sticky Situation by The And Band
- Ring of Fire by Johnny Cash
- Bohemian Rhapsody by Queen
- No One Knows by Queens of the Stone Age
- Festive Overture, as performed by the Eastman Wind Ensemble
- Chop Suey! by System of a Down

Kind of eclectic, eh?

I’ve got major changes in store for http://www.evilstickman.com which I hope to begin implementing within another couple weeks (real life permitting, of course). As it is now the site is unfocused, lacking direction, and exists with no real discernable purpose. I hope to change that by giving it a purpose and a focus, as well as maybe find a way to make a little cash on the side.

First. I’m going to restrict the site to 4 primary things (at the start, that is) - intro video, forum, blog, and the Evil Stick Depictions. I like being a smart ass, and I like drawing satirical (or, in many cases, just plain farsical) stick figures, so I’m going to focus on that - make it kind of like a web comic with attached blog commentary (when applicable - think penny arcade style, with less blog commentary). I’m going to try to develop this myself, so we’ll see how that goes. I’ve kind of got a design in mind for the image presentation app, but kind of lack the expertise to implement it at the moment. Hopefully that’ll
change as I progress in development.
The rest of the stuff (history, pictures, articles) will either be moved to http://www.mattbillock.com where applicable, or disposed of altogether when the material is pointless and lame. Until then, though, be warned that the most invisible page on the net is soon to change.

There’s a misguided notion that permeates our society and colors people’s perceptions. It’s something that many of us take for granted. It’s something most of us have been taught since birth, but that only a few have railed against. I’m talking about the idea that some people deserve respect by default, especially seniors and their ilk.

Many call my generation narcissistic, conceited, arrogant, or whatever else you may because we reject one of the tenets that has been a staple of life in american society - all people are deserving of respect, and the aged deserve it most of all. I contend that it is not a rejection of the popular wisdom, but that it is a renouncing of bullshit tradition passed off as the “right thing to do” by those who directly receive its benefit!

Most people deserve common courtesy, to be sure. The world would just generally suck if people were total assholes 100% of the time. But respect is a different beast altogether, and is at the crux of the dissonance between the old and the young. We view respect as something to be earned, and not deserved. Our “elders” view respect as an inalienable right. We are right, and they are wrong, for one simple reason - not everyone is deserving of respect.

Look at it this way. Let’s say I respect my elders. Let’s then say that I find out a person older than me was formerly a rapist, or a thief. This person is obviously not deserving of respect (no matter how reformed they appear to be), but I have already given it blindly. Doesn’t that, in theory, reduce the quality of the respect that I give? It reflects poorly on me to attribute respect to a person that I do not know well, as it shows me to be naive and too trusting. It is an apocryphal example, to be sure, but it is apocryphal for the same reasons that rote recitations of idiotic generalizations are silly artifacts of a bygone era.

Respect is an acknowledgement of a person’s achievements and an expression of an underlying desire to emulate that person (or, at the very least, an admission that the respector would not be entirely opposed to being in the same position as the respectee in terms of achievements). In this light, giving respect to an elder is akin to patting them on the back and saying “way to not die!” Back in their day, perhaps merely surviving was an accomplishment in itself, much as a
journey of 26 miles would seem an arduous one. Today, though, both are fairly pedestrian accomplishments - most of the time those things that kill a person are random and unavoidable (thus making any escape from them one of sheer luck), and people routinely drive 30 miles just to go to work.

The point is that times change, and as they do so does the way we look at the world. What was once respect-worthy is now an everyday task, much as what many of us now respect may eventually become commonplace. If everyone can stay alive for 40 years, the act ceases to become respected - in fact, it ceases to garner special recognition. Respect should be accorded for actions performed, and done so in proportion to the “weight” of those actions, and how can I grant respect unless I know the person has done something that is deserving of it?

This applies to all cases of automatic respect. As a child you’re told to respect and honor your parents - why? Just because they managed to bring you into the world? Looking at some of the screaming monkeys around todat, and the “parents” responsible for their upbringing, I’d
argue that having a kid these days is more deserving of scorn than respect. As a child you’re told to respect an honor your teachers. Why? Because they managed to make a living wage on a job in teaching? Because they chose to forego the higher salaries and better quality of life in
the real world over the misguided notion of molding tomorrow’s youth? Given the quality of most teachers, I’d say that any respect given them has been wasted. You’re taught to respect superiors, when there is no proof whatsoever that they are your superior. You’re taught to respect others’ beliefs, even when they are stupid and offensive. It goes on and on - like ribbons given out to 11th place contestants, everyone and everything gets respect for whatever meaningless activity or action they’ve performed. In an environment in which everything is to be respected, how can we be allowed to have a differing viewpoint?

Everyone deserves simple courtesy. Respect is to be hoarded and granted sparingly, lest the very idea of respect become cheapened and the word itself become meaningless. You have to earn my respect, and whining about how that makes me conceited or arrogant isn’t getting you very far.

So yeah, I ended up slacking off on the trumpet experiment. There’s an excuse, as there always is with these kinds of things, but as usual it is not sufficient justification for a failure of this magnitude.

However, the excuse is the purpose of this post. The thing that had me slacking off on my horn playing was a final project for my GPH 541class, which is entitled “Advanced Lighting Techniues”. It’s essentially a seminar with a focus on lighting a scene, where you get to choose your own final project. My partner and I chose to attempt to emulate a day-night cycle in real-time.

I’m pretty proud of our result, and so was our professor. So much so that she’s going to use it to show to potential students and their parents, faculty, and alumni. She even said she was going to try and get a screenshot into the alumni magazine. To be honest, I’m not sure it’s worth the accolades she is bestowing upon it, but who am I to turn down this kind of recognition, right? In either case, I’ve set up a small website for it at http://www.evilstickman.com/gph541/daynight.htm - you can judge the quality for yourself. The app is available there, as well as a screenshot of the scene at about noon.

I’m hoping to be able to turn the foundation that I wrote for this thing into something larger and cooler, but only time will tell how successful I’ll be at that .

So I tried yesterday to lay low so that I wasn’t shot or damaged for rehearsal. I failed miserably - rehearsal was total shit. Complete and total shit. I can only assume that taking a day off to let the chops recover doesn’t do a damn thing, like I had hoped that it would. I don’t have the time this morning, so I’ll be playing this evening (which is what I’ve done the past few days anyway). I also lost about 8 days worth of data because a program caused my PC to freeze - luckily i have the “online archives”.

But that whole thing is kind of secondary right now. I’ve had what I hope will be a fortuitous event take place which, provided that everything goes well, could start the next chapter of my life off rather nicely. Mindi and I have been talking about moving lately (me more than her, I think), and as a preparatory measure I updated my resume on a gaming job website (gamasutra.com, for those interested). I didn’t apply to any jobs, I simply updated my resume. The very next day I got an email from a game company recruiter who asked me if I was interested in anything in California. I gave him a call the next day, and actually did a phone interview on the spot. He sent me a programming challenge to complete and, provided that I do that well, I’ll hopefully be called in for another interview.

For those who aren’t trying to break into the game industry (or haven’t already broken in, my position as such is debatable), this kind of thing is pretty unheard of. All you ever hear about is how people will put out resume after resume after resume, and not hear a response. Some people apply to positions for a solid year before they even get an interview. I apparently got one just by updating my resume. So to use the words of some younger generation, I’m pretty stoked about all of this. I can go into this thing with a bit of swagger and confidence because, after all, they contacted me. I’ve just got to rock the world on this programming challenge and, hopefully, that will hold their interest enough that they call me out there for an in-person interview.

Which brings me to the only downside of the whole thing. The job’s in Camarillo, CA, which is about 51 miles north and west of Los Angeles. Seeing as how CA is the center of the games industry, this was to be expected (if a company was going to contact me outta the blue, it’d most likely be from CA), but it is still a major life change. The questions in my mind right now are if I get the position, will Mindi and I be able to handle the change in environments? How about the distance from family and friends? The cost of living is also higher in CA, which might mean this would be another in the series of temporary places (unless the real estate market really tanks, as I’m hoping it will). I’m sure that all of these are surmountable obstacles, and it’s probably premature to take them into consideration. Plus, I’m most concerned about how it will affect Mindi. She loves me and has said she would go wherever, but I’d still feel like a large bit of asshole if I didn’t give her at least a little bit of a say.

But I’m getting ahead of myself. Tonight, I complete the programming challenge and then continue work on my project. I swear that all I’ve been seeing lately when I close my eyes is code, between 8 hours a day at work and 4-5 hours a day at home/class. At least it’s decent training for crunch time in the industry…