Tufte Would Be Proud

{

PingMag again with something very interesting for all of us.

}

Youth Obsession

{

I read Paul Graham's essays out of habit these days; I loved the earlier gems concerning matters of being a Great Hacker and even though less and less of what he says is designed for people like me, I still read them hoping for something special. Something inspirational.

The current essay, Why To Not Not Start A Startup, is geared towards people considering as much. Among Graham's many ideals for the person starting a company, a recurring theme revolves around youth and freedom.

I caught a bit of it earlier in the week and one comment that stuck was in reference to people like myself, who also have a family life. I have no children yet, but even then I'm within the target zone albeit to a lesser degree.

"What you can do, if you have a family and want to start a startup, is start a
consulting business you can then gradually turn into a product business.
Empirically the chances of pulling that off seem very small. You're never going
to produce Google this way. But at least you'll never be without an income."

The emphasis in the quote is mine because I think it struck at the heart of what bothered me - it seemed to go further than the notion of not starting a startup to what Google symbolizes in the social imagination: the Next Big Thing, the Brilliant Idea, the Company After Which To Model. It was the feeling a few weeks ago I got at the airport when I saw a young woman - a UCLA college student - with a Google backpack and I got a strange envy thinking "How'd she get that!?"

The quote remained in my head and last night while I was finishing the essay, my wife was watching the TLC show What Not To Wear and I began to connect the youth obsession from the show to the kind of youth obsession I recognize creeping into my own value system with the help of quotes like the above. It's the obsession that the good ideas - the potence as it were - is gone once a threshold of age or lifestyle is crossed. It's not unique to programmers or "techy" people; it seems that mathematicians can be plagued with the thought that Einstein and others resemble a universal truth: the best ideas are to be had in youth and from there you live in the afterglow of them.

I wonder about this. I grapple with the difficulty of truth generalized - I think Graham is in many ways right - and the desire to be an edge case of his statement. Two books I read recently come to mind: Masters of Doom, the chronicle of the founders of Id software, and Weaving the Web, Tim Berners-Lee's recollection of how the web came to be. In Masters of Doom, John Romero and John Carmack seemed to model the notion of Graham's thinking: youthful obsession, low budget living conditions, energy and the freedom to have fun. Tim Berners-Lee is a massive contrast - less a picture of overnight "hacking" and pizza, and more of thoughtfulness, patience, and the desire for his idea to be bigger - an idea that would prove its usefullness and universality. I don't remember the exact day, but on one important occasion Berners-Lee was absent, his son was born on whatever "special day" it may have been. Even though he could have monetized his work, his values seem shifted. And I find ironic the fact that the afterglow of the web is bigger than the afterglow of Doom.

I'd be interested in discovering some older founders - people whose paths were a little more thoughtful and wise. I'm sure there are some out there who break the age and family barriers to become successful as they've defined success. Although I'm pressed to think of them in technology, elsewhere they come to mind quite easily - the company I spend most of my time at, Daktronics, is just one such case.

I still love reading Paul Graham though - one thing he's written that I think I'll always remember comes from his essay Hackers and Painters where he described the attribute of relentless:

"This sounds like a paradox, but a great painting has to be better than it has to be. For example, when Leonardo painted the portrait of Ginevra de Benci in the National Gallery, he put a juniper bush behind her head. In it he carefully painted each individual leaf. Many painters might have thought, this is just something to put in the background to frame her head. No one will look that closely at it."

"Not Leonardo. How hard he worked on part of a painting didn't depend at all on how closely he expected anyone to look at it. He was like Michael Jordan. Relentless."

"Relentlessness wins because, in the aggregate, unseen details become visible.
When people walk by the portrait of Ginevra de Benci,
their attention is often immediately arrested by it, even before they look at
the label and notice that it says Leonardo da Vinci. All those unseen details
combine to produce something that's just stunning, like a thousand barely
audible voices all singing in tune."

I can walk away, a thirty-one year old married guy or no, as relentless as I can be. I'm off to paint some leaves. (But first I have to go home and do some yardwork.)

}

Yagni

{

Tim posted about trying to explain Yagni on Twitter and after looking it up I realized it's something I've tended towards without having a vocabulary for it - you know that sense when something is so familiar that you think there's got to be a technical term for it.

And a person need not be an "Extreme Programming" proponent to see the truth; I have a Yagni moment almost each day when a person asks a question about how to do something and I'm more bothered with the question (why on earth would you do that???!!) than coming up with a solution.

}

Step In, Step Over, Step Out

{

Just a quick note from a late night's coding session, something that I sort of knew but finally got fed up enough to begin implementing everywhere. I'm working on a fairly large Windows Forms application and one library devoted to safe type conversion is filled with methods like this (yes, could've used Int32.TryParse, I'm not the original author though... ):

private int ToInt32(object val){
int ret = 0;
try{
ret = Convert.ToInt32(val)
}
catch(Exception ex){
// suppress
}
return ret;
}

It's nice to just attempt conversion and expect a zero for an invalid value, but it's annoying when you've got a method call like:

MyCall(SafeConvert.ToInt32(num1), SafeConvert.ToDecimal(num2));

The easy, clean fix is to apply the System.Diagnostics.DebuggerStepThrough attribute to your method. Any calls to that method are stepped over, making your life in debug mode that much easier.

System.Diagnostics has quite a few other debugger attributes, one of which allows you to mark code that came from a library you didn't write (DebuggerNonUserCode). Very useful indeed, especially when you've got unit tests that can assert something needs never be "debugged" again.

}

Tech Support

{

This spot about medieval tech support is hilarious.

}

Beane's Programmer

{

I recently finished Moneyball, Michael Lewis's tale about general manager Billy Beane, the Oakland As, and the sport of professional baseball (note: I'm African and knew nothing about baseball for a long time - but after a few years playing fantasy online, I'm a major addict; it's hard to love math and hate baseball). What's special about the Oakland As is that as a small market team with nowhere near the financial resources of a team like the Yankees or the Red Sox, they do quite well in the major leagues - better than many of the money-rich competitors the play. What's special about Billy Beane is that he's been able to buoy the As performance by picking players that would have otherwise gone unnoticed for cents on the dollar.

Far be it from me to overextend the anecdotes of sport to something like software development but in this case I can't help thinking that a dominant culture of the development community online is obsessed with Fizz Buzz and functional programming languages in a manner similar to the way that old baseball scouts have an infatuation with high school standouts, good looks, and the Adonis body. I couldn't help but wonder about what was boring and yet obvious - the decisive factor between a good programmer and a bad one that was right under our noses but we miss because we're reading articles on the new shiny meme that is traversing the "blogosphere."

And then one thing came to mind... really a few weeks ago as I was reading Larry O'Brien's column in SD Times on estimation at a moment when my own lack of precision in the department had begun (and is still) eating at me. Estimation seems so pedestrian in comparison to Haskell, editors, language foibles, language pleasures, clever interview questions, and all the other things we look at for entertainment online. But I wonder if it isn't more important to be able to look at a project and give a relatively realistic guess at when you'll be finished - certainly in my case where the client is not going to notice my beautifully terse recursion inspired by Scheme under the covers, and they will become progressively discontented for each month that goes by when I'm still "working on things." I wonder that it isn't important enough for a guy like Atwood to call people unfit for programming over, or a major idea that sweeps across the net. Perhaps Agile methodologies fit into that, but more in the sense of philosophy than selection of team members and teammates.

What confirms this even more so is Steve McConnell's book on Software Estimation parked in the same spot it has been in our office over the last few years when we've rushed to everything (anything!) else: Fowler's Refactoring, C# References, Object Thinking, and the list goes on.

Estimation isn't exclusive to other traits that good programmers seem to have; in the same way that a person who happens to keep their On Base Percentage high doesn't necessarily do this at the expense of their Fielding capabilities. Indeed, a person who can reasonably estimate that a task will take them 50x longer than it would take others is probably in the wrong career to begin with, kind of like a baseball player who hits better than anyone else but is so phenomenally slow while making it around the bases.

Okay, that's all the sports and programming I have for a while...

}

Be The Editor

{

Derek Slager, whose background sounds a lot like mine, makes a case for using Emacs as an editor. It makes me think of two occasions: first, when I guffawed at James Gosling saying that his favorite IDE was Emacs, and then later on when I was teaching a .NET development class at Countrywide and a person sitting the class (graduate of UPenn) sneered at using Visual Studio .NET and instead opted for Textpad (he hadn't used it before but still leaned towards a simple text editor and his ability with the command line). Needless to say he put everyone to shame.

}

Foo, Bar, Monorail, and being Test Driven

{

People I work with are always amused by my excessive use of "foo" in naming things while I do examples or sketch out ideas. I was equally amused with Hanselminutes 55 which I can roughly quote here:

... so once you've got your foo class accepting a bar class
and more likely it's going to be accepting a IBar interface... foo depends on bar which depends on blah and yada ... your instantiation looks like new foo, new bar which takes new yada...

Fun stuff, but the real conversation was about Monorail, a piece of the Castle Project, a .NET web application framework I've been interested to look at for some time. The most interesting argument for the use of Monorail/Castle was the ability to have greater and more precise test coverage than with a typical ASP.NET application using Watir or an equivalent technology. All the buzz about being Test Driven usually breaks down for me when I'm looking at the kind of web applications we build. Even something like Watir is a frightening prospect on an ASP.NET page with several grids, in a masterpage, loaded with javascript - and has about 10 different "directions" that a tester could take. Extend that to about 100 pages, many of which support different "views," and you've got, well, a bit of a problem in being "Test Driven."

The conversants, besides Scott were Aaron Jensen and Jacob Lewallen.

}

Beautiful Code

{

Here's something for the radar: Greg Wilson and Andy Oram have a forthcoming release (wow, I sound like a radio DJ) from O'Reilly entitled Beautiful Code: Leading Programmers Explain How They Think. If the title isn't seductive enough, a look at the essay authors should be - including Charles Petzhold, Yukihiro Matsumoto, Douglas Crockford, and Elliotte Rusty Harold amongst others.

}

Perlcast Interviewed

{

Josh McAdams, the guy behind Perlcast, is interviewed over at ClearBlogging. Buried in the interview is the answer to something I've always wondered: his mellow southern accent is from Arkansas.

}

Keyboard shortcuts with Javascript

{

Creating shortcuts on textboxes is none too difficult in Javascript, but (and don't get me wrong - I love Mr. Flanagan) the Rhino book is a bit abstruse. I was adding this functionality to my night project and pared it down to:

function handleKeyCommand(event){
var e = event window.event; // Key event object
var kCode = e.keyCode ¦¦ e.which; // What key was pressed
// I am trapping Ctrl+e (69) here
if(e.ctrlKey && (kCode == 69)){
var theButton = document.getElementById('actionButton');
theButton.click();
}
}

I'm calling that from the onKeyDown event of a TextArea the boring way; because I'm assigning it from the server side in ASP.NET, I have:

actionButton.Attributes.Add("onKeyDown", "handleKeyCommand(event);");

Which translates to onKeyDown="handleKeyCommand(event)"... the Web 2.0 kids would thumb this down since it's not an anonymous javacript function assigned after the page is loaded (I need to question that "inobtrusive javascript" ideology, but it's a post in the making), but this keeps it simple.

The main pitfall for me was in using onKeyDown rather than onKeyPress - the latter is more appropriate for obtaining ASCII related keyboard events, not special keys like shift, control, and so on. Another pitfall was browser compatibility; Flanagan also uses a nifty idiom when he allows the assignment of the event object occur with the operator. It returns the first true value and since an unassigned object returns false in javascript, writing the following assigns a reference to the event object based either on the parameter which would be passed by the browser (Firefox) or the built in window.event object (IE):

var e = event ¦¦ window.event; // Key event object

}

The FizBuzz Conundrum, Ramanujan

{

Imran observed not too long ago that one proof of the difficulty of finding "quality" developers was that he (or she) was encountering a shocking amount of failure among applicants to write code that solved even simple problems. This was picked up for comment by Raganwald, Atwood, and even Hanselman.

I resisted the urge to write up a solution but after that much buzz I thought there's got to be a catch. So this morning, before I "clocked in" from my basement (we're under blizzard conditions here in South Dakota), I wrote up the first thing that came to mind:

for (int i = 1; i < 101; i++) {
Console.WriteLine((i % 3 == 0 && i % 5 == 0) ?
"Fizz-Buzz":((i %3==0)?
"Fizz":(i%5==0)?
"Buzz":i.ToString()));
}

No catches, it seems. But after thinking about it, I thought that a lot of people I work with wouldn't be happy with my solution to that particular problem. It could come across as "convoluted."

The more I thought about it, the more I knew the more acceptable answer was:

// iterate given range
for (int i = 1; i < 101; i++)
{
string output;
// if the number I'm on is divisble by 3 or 5
if (i % 3 == 0 && i % 5 == 0)
{
output = "Fizz-Buzz";
}
// if it is divisible by 3 then set output to "Fizz"
else if (i % 3 == 0)
{
output = "Fizz";
}
// if it is divisble by 5 then set output to "Buzz"
else if (i % 5 == 0) {
output = "Buzz";
}
// if divisible by neither 3 or 5, output the number.
else
{
output = i.ToString();
}
Console.WriteLine(output);
}

And as I think about it, there may be more to this test than just the matter of output - you may be able to get a sense of what type of thinking a person employs in solutions and how their values mesh with them. Even if the answer is "right" it may not be right.

A while back I was feeling some angst toward my employer (when I used to live in California) and put my resume on Monster to see what I was "worth." The first party to express interest went under the guise of an actual company, but really they were just recruiters. They scheduled me for a "test" at 8:30 am in downtown Los Angeles.

At 8:30 am in downtown Los Angeles.

Traffic and personal discomfort aside, I made it to the office where a person who was obviously non-technical gave me a (photocopied?) sheet of paper and a number two pencil to write some javascript code that manipulated the DOM and XML.

I was a little green and was writing stuff like this:

document.getElementById("foo").appendChild(root.createTextNode((entry == foo)?"This":"That")...

You get the picture. I wasn't used to writing things on paper so I was erasing here and there, and because I tended towards multiple steps in one line, my lines were going across the page and I'd curve them upward so I could get it to fit. It was pretty messy, and I'm sure the recruiter picking up the "test" wasn't impressed with how disjointed it was.

And I can imagine the people at the software company, if it ever made it there, looking at smudges and pencil marks and an utter lack of comments on a piece of paper which they'd never be able to verify unless they entered it by hand. I doubt it made it that far but if it did, they might have thought the messy code was indicative of a "messy" mind that didn't write enough comments and consolidated steps too much. It would either go into the "Not a team player" or "Quixotic" pile before it was dumped to the trash.

In defense of myself, or if I may be bold enough to think of my ideals in this light, I keep thinking about Ramanujan, the brilliant Indian mathematician. As an autodidact, he was not familiar with protocol and convention and the step by step approach other mathematicians used... he would skip steps by presenting formulas without rigorous proof in order to arrive to his solutions. Of course this is an unassailable attribute if you're as smart as a Ramanujan and a death blow if you're not.

Now Hanselman has a podcast on the whole thing. I'm going to check it out.

}