I am not a good golfer

Neither am I terrible, but I'm definitely not good.

I played in a 4-man scramble tournament a couple weeks ago, and our team came in last place by a mile. I was one of the better players on our team, and wasn't playing well, even by my own low standards.

A good score for a scramble is usually around 60 strokes for 18 holes. We shot 80. Lots of bad shots all around, some bad luck, etc. Nobody was really close to our score. Awesome!

But I can't complain, because it was still better than working.

My game seems a bit rusty right now. During my previous job, I didn't have much time at all to play. Same goes for the year before. I'm finally starting to play semi-regularly, and the results are pretty sporadic. My swing plane is all over the place. I'm not shifting my weight properly half the time. A few great shots come out every once in a while, but not often. I'll hit a beautiful 300-yard drive followed by a series of terrible iron shots on one hole, and on the next, I'll send my tee shot into the trees, only to save it with a great recovery and a beautiful pitch to within 6 feet.

I'm still shooting around 100 strokes for 18 holes right now. I've set a goal to start breaking 90 on a semi-regular basis, and it still seems quite a ways off right now. Definitely need more practice time to get my rhythm back and fix things up. Maybe a lesson to clean up a few bad habits.

The worst part?

This ridiculous game still has me addicted. I love it.

"The Pines Of The Appian Way" rocked my world

Last night I performed Ottorino Respighi's "Pines of Rome" with the Salt Lake Symphonic Winds. During the last movement - "The Pines of the Appian Way" - an antiphonal brass section of 16 players joined in with the rest of the group, just belting away, adding even more power to the ensemble. Add the fact that the trombone section (my instrument) was seated in the back, next to the trumpets, and right in front of the percussion and extra brass, and we were on some sort of hollow floor that was shaking when the bass drum and tympanis played, and that has got to be the one of the most visceral music experiences I've ever had.

Holy crap.

The last movement was absolutely incredible. I think the sound was ringing through the concert hall for a full 5 seconds after we finished. My big old Conn 88HO got as much as it could take in terms of sheer, focused sound projection without distorting.

Now I've got to find a good recording of somebody much better than us performing it. I bet it will sound better overall, in terms of performance quality, but it will be tough to beat the experience of actually sitting right in the middle of the group and getting enveloped by huge, building tidal waves of sound, envisioning huge columns of ancient Roman soldiers marching up the road as the dawn breaks. Goosebumps.

I whole-heartedly recommend it to all musicians out there. If you ever get a chance to perform this piece with a good group including the extra brass section, do it. What a rush.

C++ is a psycho hose beast

C++, you and I go a ways back. We've been together since before I finished my degree. Since before I got married. I had great times with C++ in college, and we were hanging out pretty much exclusively during my first 3 years as a professional, and I thought things were just great the whole time since we'd met, 12 years ago. That's a pretty freaking long time to be deluding myself into enjoying a dysfunctional relationship.

I've had enough. You suck, C++. We're getting a divorce.

I'll be civil about the whole thing, and we'll still deal with one another to support the kids (legacy projects). Maybe you'll still have a happy life in low-level systems code, but I just don't love you any more, and I've got to move on with my life. But before we split, it's only fair that you know why I'm taking such drastic measures.

How do I hate thee? Let me count the ways...

1) You can't decide who you are.

Any time we're with our other compiler friends, you are maddeningly inconsistent in your behavior. It's seriously creeping me out when I hear about the multiple lives you're going on with. I talk to one buddy and he says that you've adopted the standard namespace and no longer want to deal with your old friend and all her friends. Another says you told her you've never heard of the standard namespace, and you're as close to the old ".h" gang as ever. And now I heard that you actually acknowledged the existince of the "export" keyword with that one pedantic friend, and now that's all he'll talk about when we meet. It's like you brainwashed him into thinking it's commonplace.

I'm tired of trying to remember which compiler we're hanging out with, and having to walk on eggshells with the preprocessor so you don't blow up. No more. My next significant other will be somebody that not only has standards, but sticks to them.

2) You live in a constant state of self-denial

The other day I wanted to ask you about an enumerated type, to see if you'd defined a particular name. Of course, you would have covered your ears and done your "I don't know what you're talking about" routine. Just once, it would be nice if I could give you a string, and you could tell me if a class had that particular method, attribute, whatever. Instead, you basically tell me screw off and do it myself. Introspection opens up all kinds of amazing framework and metaprogramming possibilities, but you're utterly incapable of doing this without help from clunky libraries.

3) You don't know what strings are.

Speaking of strings, what the heck is your problem? Every time I want to use one, I have to use a null-terminated pile of garbage, or a std::string with a horribly bloated interface, or any number of nonstandard third-party solutions with different interfaces and conventions. I shouldn't have to put up with this every time I want to do some high-level string manipulation.

4) You barely know what arrays are.

Arrays are just pointers to the data with no comprehension of the length of said data? Seriously, do you know how crappy that is? You make two-dimensional arrays needlessly cumbersome and obtuse. How tough would it be for a minimal, non-resizeable version of std::vector to be a first-class citizen? Heck, just making them objects that are aware of their own size would make "ProcessArray(int data[], unsigned int length)" a thing of the past.

5) Your templates are uglier than Sam the dog

Sure, at least you have templates, which is more than Java could say before generics. But holy crap, do they have to be so freaking nasty? And I'm just talking about usage, not implementation. I hope I never again have to type "for(std::map>::iterator ix = data.begin(); ix != data.end(); ix++)"(note: The fact that I forgot to use the preincrement operator instead of the postincrement is yet another stupid detail I have to devote brain cells to) just to set up a loop. Frankly, I'm amazed that people have produced compilers that can make sense of your nonsense.

6) Crappy dependency resolution

I could just #include everything I need, but then every time I make a change half of the project gets recompiled. Admittedly, this isn't a problem until I, oh, get out of school and enter real life, and have to work on sizeable projects, and then it takes 15, 30, 60 minutes, or even hours if you've got a really gnarly program. Way to kill productivity, jerk. And even with #include peppered all over the place, if I get a circular dependency loop, I still have to throw forward declarations in there to get by. Then I have to keep track of when to give you a forward declaration or an inclusion. When I'm subjected to this kind of micromanagement, how does this help me?

7) The neccesity for design patterns

Let me make this clear: I don't hate "Design Patterns", neither the book or the concept. What I do hate is that these are even neccesary in C++. A lot of these patterns are simple to use and don't require a cookbook if implemented in another, more capable language, unlike you, you decrepit heap of ineptitude. I guess this is nitpicking, but I'm at the limits of my attention span on this blog post, and I felt I just had to throw one more reason in there. I could probably go on all day, but then I'd get all weird and incoherent on my imaginary audience, so I'll just take a deep breath and move on to my conclusion. Let's get this rant, er, break-up over with.

(deep breath)

Programming language monagamy considered harmful

Ruby looks like a really cool language, and I'm going to start playing with it more, and hopefully use it on some lightweight applications. Yet, as great as Ruby looks, I'm promising myself that I won't ever get married to another language. I need to broaden my skillset some more, wrap my mind around different paradigms, that kind of thing.

I've heard it said many times, in various forms, that I don't neccesarily need to use Lisp for real work, but I need to learn about it, get comfortable with it, really explore what makes it different from the C family of languages, and it will make me a better programmer. That's next on my list, after I try building a few decent-sized apps in Ruby. Maybe I'll try Haskell or OCaml next.

It's hard to get away from the safe languages, like C, C++, Java, Perl, etc. That's what employers want, because they're popular, and they can pick up just about anybody that can read some C, and have a vauge idea of what's going on. It's hard to use some of these more different languages at many companies, which is understandable, because for all of it's groundbreaking amazingness, who has real world work experience with OCaml? Speak up. Anybody? That's what I thought.

But if we had fewer language monagamists out there, more die-hard language bachelors of the kind I'd like to become, this wouldn't be as much of an issue. We might just find ourselves asking each other why the heck we're still using Perl, when Ruby does everything Perl does with practically none of the downside. And then some of us start using these new languages on some low profile, internal projects, and it works, and we start using them more and more, and suddenly it reaches some sort of critical mass and a language like Ruby completely supplants an inferior cousin like Perl.

It could happen, and I hope it does.

Plausible software scheduling for rookies

Anybody with a few years of experience has had the displeasure of being held to overly optimistic development schedules. Sometimes it's endemic to the organization, possibly as a result of having to submit ridiculously low bids in order to secure any work whatsoever. Sometimes it's the result of a simple brainfart. Sometimes it's the result of having giant alien space ants in your organizational chart that callously give out unreasonable demands to their human underlings. (I, for one, welcome our new insect overlords. I'd like to remind them that as a trusted code monkey, I can be helpful in rounding up others to...toil in their underground sugar caves.)

This post won't contain anything new to all of you awesome code gorillas with 15 years of experience. Consider it a rant. Remember, this is the blog of a journeyman code monkey, not a super-duper guru code monkey. I aspire to reach your exalted plane of existence where we can have these great conversations I made up in my mind:

• "Ho, ho, yet another little code monkey just saw The Mythical Man-Month for the first time."
• "How quaint. I can't wait until he goes through his 'Lisp is the most beautiful language EVAR' phase." *flings code gorilla poo* "Let's go back to writing mind-bogglingly expressive, functional, concurrent, mind-reading languages in our spare time."
• "Superlative idea, old chap!" *flings code gorilla poo*
• "I love Emacs!"*flings code gorilla poo*

Now that's the life. Listen to my nuggets of quasi-wisdom, little rookie monkeys, and someday we'll be able to have these incredibly deep coding discussions out loud. Awesome, huh?

Vacation/leave
Assuming 2 weeks of vacation and 2 weeks of sick leave per year, you can count on 4 weeks per year, on average, that each developer will be out of the office. Throw in another 10 days of various holiday leave, and 6 out of 52 weeks of the year are gone. Poof! Write them off now. That's 11.5% that the project is not going to get back.

Management can always disallow vacations when the project starts falling behind, calling developers in on sick days, working holidays and weekends, etc. However, if schedule-affecting factors are habitually ignored, these measures quickly become a permanent state of affairs, a perpetual death march, mass hysteria, dogs and cats living together! The end result of this is our next item...

Developer turnover
It's a fact of life. Developers are going to leave, and management will need to hire new ones. Face it, 20% of your people are going to be recycled within the next year. Some years more, some years less, but that's going to be your long term average. If it's significantly more, maybe you work for Electronic Arts, if it's much less, you must work for Google, that fabled realm of free gourmet lunches, super geniuses with complete intellectual freedom, and disgustingly amazing stock benefit options, or some other fairyland that a real programmer wouldn't be caught dead working for, and you should leave a comment telling me who I should send my resume to.

Losing strong developers has a huge impact on project schedule that I'm not sure how to quantify just yet. But it's there, and it's significant.

Nasty surprises
So I'm working out in the yard, digging up some roots,trying to make up for ineptitude by putting on displays of brute strength, without much success, (or much brute strength for that matter), and I've encountered this root with a bad personality. I'm hacking at this thing, pulling it up, and it goes on and on. It's hard work, but I seem to be making some progress when my wife comes out to tell me what an amazing hunk of a man I am. I know it's coming - she's got that look of awe and wonder in her eyes. As I hold up the trophy root, she sings my praises - "Honey, why are you destroying the sprinkler system?"

Oh. I thought roots were supposed to be black and rubbery.

Well, looks like the whole weekend is shot to crap. Now I have to make 20 trips to Home Depot, trying to figure out what piece I'm supposed to buy while my handy neighbor wonders how this hopeless wreck ever managed to live past the age of seven.

This happens in software, not always, but often. Attempts to extensively plan your design to account for every single possible eventuality will rapidly demonstrate diminishing returns, to the point where all that time spent planning kills your productivity, and you would have been better off spending some of that time on rapid prototyping and other forms of actual development. (The extreme opposite of over planning is "Agile Programming", which comes with its own problems)

Surprises will affect your schedule in bad ways. The good news is that you can attempt to account for this by collecting data on your past estimates, being disciplined and consistent in your estimating methodologies, collecting data on time spent on unplanned surprises, and figuring out an average percentage of buffer time you need to build in to your future estimates.

Distraction
As you come up with more refined plans, and dutifully track your work time, you'll notice that a lot of your time is spent on things not in your original plan. Some of this is in the form of unplanned development surprises, as covered above. Some if it is in other tasks, checking email, workplace training, meetings, answering the phone, random conversations, office chair demolition derbys, you get the idea. The end result is that, as an industry standard, developers, on average, spend only 15 hours out of a 40 hour work week toiling on tasks that were planned beforehand.

This means that if you've got a task that you've planned out at 80 hours of effort, even after adjusting your effort estimate to correct for your own built-in estimating inaccuracies, there's no way that sucker is going to be done in two weeks of normal 8 hour days. On average, you're gonna need 5-6 weeks to get that done.



This is list is by no means comprehensive. But accounting for these factors gives you a start at making more realistic estimates than I did, all bright-eyed and bushy-tailed, straight out of college.

Blargh!

I'm a software puke. Appropriate, yes?

This is likely the shortest post you'll ever see here. I tend to get a bit verbose when typing, rambling on, etc. Maybe I should have joined the debate team in high school in order to learn how to make a point succinctly and concisely. Yeah, and maybe I should have developed an internal sense of motivation, busted my butt, and gone on to academic and financial success beyond my wildest dreams. Great idea, in theory, except for one thing.

I love efficiency.

No really, that's the problem. Let me explain. Wait, that would be too much work. Let me summarize. No, still too much work. Let me draw a semi-related parallel, a sort of meta-metaphor, and let all the astute readers draw their own conclusions.

In the spirit of politically-correct naming conventions, I submit that "laziness" should be heretofore designated as "efficiency of work and/or effort". Work ethic? Can't I be ethical without lifting a finger? Procrastination is just a non-computer application of "lazy evaluation" and avoiding "premature optimization". As all us geeks know that premature optimization is the root of all evil (or at least most of it), so by a deft application of faulty logic, my standpoint on work minimization is the noblest of pursuits.

Oh yeah, back to that software puke thing. Being that "software puke" is my current profession, be warned that there is a definite possibility, nay, a near certainty, that there will be more programming-related content here than the average non-geek is comfortable with. If Blogger had some sort of post-classification system, all you poor "normals" would be off the hook, and you could simply filter out all the (hypothetical at this point) mind-numbingly boring rants about programming languages and the like. Unfortunately, I'm not aware of any such feature here (though Blogger's affiliation with Google is promising) (edit: I discovered the label feature immediately after making this post. I'm such a tool). I've been introducing myself to Rails (programming boringness already), so maybe I could code up my own blogging software, but not only am I a Ruby noob, I've got that whole work efficiency issue to work out. The return on investment doesn't seem too high. Especially on a topic (blogging) that I have had absolutely zero involvement with up to this point.

In fact, don't be surprised if I lose interest next month, and this blog withers and dies on the vine, frozen in its current, bland state, like the rest of the cyber-flotsam out there. If so, at least I have the comfort of knowing that my contribution to the blogosphere will be forever coupled with the words "blargh" and "spew". Heartwarming.

This introductory post has already gone on too long. Any attempt to salvage this piece of garbage will just make things worse, so I should wrap things up, ASAP. Remember that verbosity thing? It might be some sort of genetic disease. Curse you father! Screw you too, Gregor Mendel, father of modern genetic theory! Gah, this post just won't die. Maybe I should simply take this post out to the backyard and shoot it in the hea-