Archive for September, 2008

Looks like we’re rolling with Moose…

September 26, 2008

After the nth person telling me to try Moose, I finally gave in.

The first thing I wanted to know was how to handle private variables, hash table properties, and object type properties. The Moose Quick-Ref Card lists the built-in Data Type constraints. I think Randal L. Schwartz has written the definitive introduction, though. (His follow up goes into more detail about custom types….)

We can see below that the read-only field on the Example object needed to have a writer defined for it. Even though the method is named private_set_x, it can still be called from the outside world. Also, we can set the “read only” member via the constructor hash! Hash and object property types seem to work just fine. The only real trick there was to use an in-line sub to initialize them.

#!/usr/bin/perl
package Example;
use Moose;

has 'x' => (isa => 'Int', is => 'ro', writer => 'private_set_x', default => 21);

sub test {
    my $self = shift;
    my $x = $self->x();
    print "My x is currently a $x\n";
}

sub setit {
    my $self = shift;
    $self->private_set_x(42);
}

package Another;
use Moose;
extends 'Example';

has 'hashtest' => (isa => 'HashRef', is => 'rw', default => sub { my %hash; return \%hash; } );
has 'exampletest' => (isa => 'Example', is => 'rw', default => sub { Example->new(); } );

after 'setit' => sub {
    my $self = shift;
    print "The after method is getting called now.\n";
};



my $thing = Example->new();
$thing->test();  #My x is currently a 21
$thing->setit();
$thing->test();  #My x is currently a 42
$thing->private_set_x(84);
$thing->test();  #My x is currently a 84

my $otherthing = Example->new(x => 168);
$otherthing->test();  # My x is currently a 168

my $another = Another->new();
$another->setit();  # The after method is getting called now.

my $h = $another->hashtest();
$h->{"One"} = "Hello";
my $v = $another->hashtest()->{"One"};
print "The hash value is $v\n";  # The hash value is Hello

my $e = $another->exampletest();
$e->test();  # My x is currently a 21
Advertisements

Roll-your-own OO system with Closures and a Dispatch Table

September 25, 2008

Okay… this isn’t an article or an essay… just more rambling notes from a random guy working on learning Perl. This is not a plea for help, so don’t feel like you have to jump in and rescue me or anything. I should develop my ideas further before posting, but I figure I’ll quit working on this if I “go dark” too soon.

I write these little programs and then I try to turn them into classes and try to instantiate them. Somehow, I don’t understand references, variable scope, and packages well enough to grok why I’m falling on my face here. (I remember a few years ago trying to read an early edition of Learning Perl and giving up pretty fast. Programming Perl was just plain frightening then. I can understand a lot more of it now, but I still get lost when I try to apply it.) I’m mad enough at the OO system that I’m willing to roll my own just to avoid the issue: I’d rather have a system that I understand completely than use one that’s much more robust but that does things that seem weird or wrong to me. Of course, I’d sacrifice some much-needed compiler help in the process, by there you go…. I have played with Moose, but my standard brain-dead OO use case that I want to roll with isn’t in their recipe list. It’s probably there somewhere, but I’ve used it enough that I know I need to understand more about regular Perl OO to use it—just so I can pick up the syntax and know what’s going on under the hood.

In any case… my view of objects may be shifting. I don’t know. I think an object should be completely malleable at runtime. I want to be able to add and remove properties and methods at will. Reflection should be drop-dead easy. Maybe I want to reinvent Smalltalk or something, I don’t know…. For some reason this just seems too hard to me in most OO systems. There’s probably some technical reason for this– or maybe I’m just lazy. Who cares. Meh.

In my last bit of Perl code, I had a table object glommed in with the rest of my code—it’s just crying to be abstracted out. I use dispatch tables all the time now, so a dispatch table class seems like a good idea. How many times do I need to cut and paste that code before I roll it into a module file?? And finally, we have the beginnings of the widget that I’m sketching out below. (Yep… totally done with closures—fun, fun, fun! For some reason I couldn’t figure out how to pass arguments to the dispatch table subs. I spent hours messing with it and I just don’t understand why I couldn’t. That’s why it’s using lame global variables in there for that….) At any rate, if I thought I could just pick up the Perl OO system and just run with it, I was wrong.

Time to sit down and RTFM– back to Programming Perl and Intermediate Perl for the time being…. Then we can revisit class definitions for data tables, widgets, dispatch tables, and my parser if I don’t come to my senses by then….

#!/usr/bin/perl
use warnings;
use strict;
my $show_debug = 0;

my @current_arguments;
my $current_stuff;

my %dispatch_data = (

    'Create Field'  => {
        code    => sub {  my ($field, $regex, $default) = @current_arguments;
                          $current_stuff->{$field} = create_field($regex, $default);
                          return $current_stuff->{$field};
                       },
        debug   => sub { print "Create Field called\n" },
    }

    );

my $dispatch_table = {};
while ( my ( $command, $dispatch ) = each %dispatch_data ) {
    $dispatch_table->{ $command } = sub {
        $dispatch->{ code  }->()  if exists $dispatch->{ code };
        $dispatch->{ debug }->()  if $show_debug;
    } if exists $dispatch->{ code } or ($show_debug and exists $dispatch->{ debug });
}

### return a closure that handles get and set methods for the field
sub create_field {
    my ($regex, $default) = @_;
    my $value;
    $value = $default if $default;
    return sub { my ($v) = @_;
                 if ($v) {
		     if ($regex) {
			 die "Value $v does not match |$regex|." unless ($v =~ /^$regex$/);
		     }
		     $value = $v;
                     return $value;
		 } else {
		     return $value;
		 }
               };
}

sub create_widget {
    my %stuff;
    return sub { my $command = shift;
                 if ($dispatch_table->{$command}) {
                     @current_arguments = @_;
                     $current_stuff = \%stuff;
                     return $dispatch_table->{$command}->();
                 } else {
                     my $thing = $stuff{$command};
                     die "No such thing '$command' in our stuff!" unless $thing;
                     my ($field, $value) = @_;
                     return $thing->($field, $value);
                 }
               };
}

my $f = create_field('\d+');
my $x = $f->(42);
$f->(77);
my $y = $f->();
print "x is $x and y is $y\n";

my $w = create_widget();
$w->('Create Field', 'Prop', '\d+', 43);
my $z = $w->('Prop');
$w->('Prop', 78);
my $a = $w->('Prop');
print "z is $z and a is $a";

using the sphincter-sigil to abuse Perl

September 23, 2008

(Sorry about the title. Don’t you hate it when you’ve got a syntax question and you don’t even know what to google to find out what it means…?)

draegtun dropped by recently to offer suggestions for tuning up some of my Perl code… and some of his code appeared to do some strange things. (Thanks for the help, as always….) Maybe it was something to do with closures and maybe it was operating directly on the internal function table of Perl. So I decided to mess with it some before rolling it out to my mini-project. I’m sure draegtun ‘s a nice guy and all, but I remember all to well the poor wannabe lisp hacker that picked up code for formatting his hard drive via some random use-group advice…. You just can’t be too careful…. 😉 Yeah, this is silly… but this is what passes for understanding code snippets before plugging them in….

Anyways, flipping through the Camel book I quickly came across a similar example in the section on closures. I couldn’t find out what the weird * sigil meant even after flipping around in the index. Logically, Perl is a postmodern language. Therefore the * sigil means the same thing as it did in Kurt Vonnegut’s Breakfast of Champions. Obviously, applying the * to a scalar shoves its associated reference up Perl’s hind end. Perl’s DWIM features should cause it to psychically intuit which internal table you meant it to go to based on the type of reference you’re passing….  (Well, I figure if I can think like Larry, then learning Perl will be a lot easier.  That’s my theory, anyway.  Let’s see if this is right….)

#/usr/bin/perl
use strict;
use warnings;

sub hotwire {
  my $number = 42;
  my $string = "foo";
  my $subname = "blarney";
  no strict 'refs';
  *$subname = sub { print "Yes, it's $number and $string.\n"; };
}

hotwire();
my $number = 12;
my $string = "bar";
blarney();

Okay, this is fun…. Now, we know from the opening chapter of Intermediate Perl that you can use eval as a substitute for the type of error-catching try/catch block activity you might have seen in other languages. Of course, as in other languages, using eval for what it’s supposed to be used is generally stupid and a form of language abuse. However we feel it is our divine right to abuse whatever language we have at our disposal, so let’s just check to see that we can load evaluated text into our environment as a function:

sub loadme {
  my ($name, $code) = @_;
  no strict 'refs';
  *$name = eval $code;
}

loadme("noway", 'sub { print "yadda yadda yadda\n"; }');
noway();

Wow… it works! Woo-hoo! Okay…. Let’s try adding in our own syntactic sugar. We’ll create a function and we’ll search for a pattern and replace it with our function call:

sub check {
  my ($a, $b, $c) = @_;
  return "$a...$b...$c...";
}

sub loadme2 {
  my ($name, $code) = @_;
  $code =~ s/(\w+)~(\w+)~(\w+)/check('$1','$2','$3')/g;
  #print "$code\n";
  no strict 'refs';
  *$name = eval $code;
}

loadme2("yesway", 'sub { my $a = 99; print try~this~out, "\n", $a, "\n"; }');
yesway();

Dumb dumb dumb! There are surely better ways to accomplish this! But yeah, it’s nice to know that (in a pinch) we can do evil nasty things like this…. Let’s try one more variation that loads the text in from a file. Also, let’s store our reference in a scalar variable instead of hotwiring the package’s table of functions….

open TEXTFILE, "< loadthis";
my $file;
while (<TEXTFILE>) {
  $file .= $_;
}
close TEXTFILE;

loadme2("crazy", $file);
crazy();

sub loadme3 {
  my ($code) = @_;
  $code =~ s/(\w+)~(\w+)~(\w+)/check('$1','$2','$3')/g;
  return eval $code;
}

my $C = loadme3($file);
print "Now we'll try running the code from a scalar...\n";
$C->();

There we go!

Now… this is evil… this is wrong… this is bogus and brain dead. But but by marrying this to our table parsing code, we can create our own Frankenstein style scripting language. We already can create specialized data structures can initialize them with data parsed from a pseudo-DSL. We can customize these structures with perl code tacked on however we like. This can be basic event and override code like you see in GUI frameworks. I figure that the code is already interpreted for us into compiled-ish code when the references are read in, so you won’t see any real performance hit when you call these things– they should be indistinguishable from any other sub. Just look for things to slow down at startup as you add more and more of these to the script files. (Yeah, I know. I need to learn about hardware and assembly language– and I need to go pick up a comp sci degree, too– I’ll get around to it sometime. Right now I just want something that works….)

Back in Lisp we made the mistake of trying to create an all-new language that ran on top of Lisp. This was bad because we couldn’t take advantage of Lisp’s language features in our hacked/custom dsl-thing. (We should have gone with the grain of the language and modified Lisp slightly so that it became our lisp-ish DSL by itself.) In Blub, we hacked someone’s custom evaluator to go even further to craft our own language from scratch. This proved to be an unsustainable amount of work beyond a certain level of complexity. With Perl, we are compromising by creating special language-interfaces for initializing data structures… and then switching over to (maybe) slightly-abused Perl code where it suits. There’s better ways to do this, but this may be sufficient for a certain class of problems….

Probably what we’re doing is rolling our own Meta-object protocol. (After a fashion, anyway.) That’s not necessarily a complete waste of time: now maybe if we study it, we’ll have a use for it….

A little experimentation with dispatch tables…

September 16, 2008

The basic model of development that’s been my hobby for the past year has been to use a custom scripting language to configure an object model which is then consumed by a GUI or something– eliminating large amounts of maintenance and opening up a form of tool-oriented development that allows for an order of magnitude increase in code reuse. That was my big thing after getting halfway through SICP– and the trojan horse by which I could sneak in some of the benefits of Lisp into a more Blubby environment. Doing that sort of thing got me into some serious parsing, which made me realize I really needed to bone up on regular expressions. I messed around with sed and awk enough that I finally broke down and decided to learn Perl. Now I’m working through O’Reilly’s Intermediate Perl book so I can understand and use more stuff from Dominus’s book Higher Order Perl.

The code below was mainly done so that I could get a better handle on references in Perl. I’m having a hard time getting up to speed with it, but hopefully after a few more projects like this I’ll get the hang of it. I also wanted to try to improve on the parser design that I thrashed out for Blub a while back. Finally, I wanted to play around with the concept of a dispatch table before rereading Dominus’s chapter on the subject.

Anyways… what I’ve done is constructed my first complex data structure in Perl: a set of nested hash tables and arrays that describe a table of data. We’re loading up the tables by parsing a text file. I’m tired of parsing beginning and ending brackets, so I’m trying maybe a more Python style approach of just using whitespace to indicate the end of a section. Here’s an example table.

Table Stuff:
	Key/[A-Z]/,     Description
	A,              Fooie
	B,              Barrie

The dispatch table (and Perl’s core features) allow us to treat code as data. With just a few language features built in to our parser, we can allow the users of our scripting language to extend and redefine the parser from within their scripts. Pretty cool…. (Dominus goes much further into this than I do, of course. And I’m crazy, so don’t judge his book by my bad code– I’m just learning, here, with my lame “3rd grade” level of Perl fluency.)

As I go further into the book Intermediate Perl, I can maybe come back and revisit this by turning it into an object. Also, I’m not using the regex’s I’ve tacked onto the table columns, so maybe I could write a validation routine that checks that the column data matches the expression. Another change might be to have a second dispatch table to handle the different state changes… but that may be overcomplicating it. [Actually, after refactoring a bit, it seems okay.] I’m sure I might come up with a different architecture if I read some chapters on compiler-like code….

#/bin/perl
use strict;
use warnings;
my %tables;
my $read_type = 0;
my $current_table = "None";
my $show_debug = 0;

sub cell {
    my ($table, $key, $column) = @_;
    my $rs = rows($table);
    my $r = $rs->{$key};
    return $r->{$column};
}

### returns an array of column names
sub columns {
    my ($table) = @_;
    my $t = $tables{$table};
    return  $t->{"Columns"};
}

### returns a hash of row hashes
sub rows {
    my ($table) = @_;
    my $t = $tables{$table};
    return $t->{"Rows"}
}

### returns an array of column regex's for validating cells
sub column_regexes {
    my ($table) = @_;
    my $t = $tables{$table};
    return $t->{"ColumnRegexes"}
}

sub add_table {
    my ($key, $table) = @_;
    $tables{$key} = $table;
}

sub add_row {
    my ($table, $key, $row) = @_;
    rows($table)->{$key} = $row;
}

### pass an array of columns and an array of column regex's
### and get a table hash back
sub initialize_table {
    my ($columns, $regexes) = @_;
    my %table;
    $table{"Columns"} = $columns;
    $table{"ColumnRegexes"} = $regexes;
    my %empty_rows;
    $table{"Rows"} = \%empty_rows;
    return \%table;
}

### pass a comma delimited header line from a table definition
### and get two array references describing the table structure
sub parse_column_header {
    my ($line) = @_;
    my @fields = split /,/, $line;
    my $column_number = 0;
    my @columns;
    my @regexes;
    print "reading columns to table $current_table: $line\n" if $show_debug;
    foreach(@fields){
        my $field = $_;
        $field =~ s/^\s+|\s+$//g; # trim field
        if($field =~ /^([^\/]*)\/([^\/]*)\//){
            $field = $1;
            $regexes[$column_number] = $2;
        }
        $columns[$column_number] = $field;
        $column_number++;
    }
    return (\@columns, \@regexes);
}

### pass a table name and a comma delimited header line from a table definition
### and get the row's key and a hash of detail data
sub parse_row_detail {
    my ($table, $line) = @_;
    my @fields = split /,/, $line;
    print "reading rows to table $current_table: $line\n" if $show_debug;
    my %row;
    my $column_number = 0;
    my $rowkey;
    foreach(@fields){
        my $field = $_;
        $field =~ s/^\s+|\s+$//g; # trim field
        if ($rowkey){
            $row{columns($current_table)->[$column_number]} = $field;
        } else {
            $rowkey = $field;
        }
        $column_number++;
    }
    return ($rowkey, \%row);
}

sub reading_table_header {
    my ($line) = @_;
    my ($columns, $regexes) = parse_column_header($line);
    add_table($current_table, initialize_table($columns,$regexes));
    $read_type = 2;
}

sub reading_table_detail {
    my ($line) = @_;
    my ($rowkey, $row) = parse_row_detail($current_table, $line);
    add_row($current_table, $rowkey, $row);
}

my $dispatch_table =
    { '^Table ([A-Za-z]+):'     => sub { $current_table = $1; $read_type = 1; print "(reading table $1)\n" if $show_debug; },
      '^\#(.*)'                 => sub { print "found a comment: $1\n" if $show_debug; },
      '^[\w]*$'                 => sub { print "(Whitespace line)\n" if $show_debug; $read_type = 0; }
    };

my $alternate_dispatch_table =
    { 1 => \&reading_table_header,
      2 => \&reading_table_detail
    };

while(<>){
    my $line = $_;
    my $success = 0;
    my $key;
    foreach $key (sort keys %{$dispatch_table}) {
        if ($line =~ /$key/){
            $dispatch_table->{$key}->();
            $success = 1;
            last;
        }
    }

    if ($success == 0 and $read_type > 0) {
        chomp($line);
        my $altcode = $alternate_dispatch_table->{$read_type};
        $altcode->($line);
    }
}

my $a = cell("Stuff", "B", "Description");
print "a is $a\n";
my $cols = columns("Junk");
print "Look at this: $cols->[0], $cols->[1], $cols->[2]\n";

Going up One more level of abstraction up from objects and relational data…

September 12, 2008

This is the thing that I start to build in every programming language… no matter what. I’m not particular about how it gets done. It can be done all in Lisp. It can be written in any language and made to make script files to compile to a Blub. There may even be languages that integrate these sorts of features already. Whatever works.

The first thing I need is to have tables be first class citizens of the language. Following the “simple things should be simple” dictum, the core case of the standard table of data with the first column being the “key” should be easy to write and edit. Non-coders should be able to immediately maintain some of this. For a lot of what I want to do, I don’t care about data types. Having everything in the table cells just be what they are (in the tradition of Perl’s scalar’s) is sufficient for most cases. The tables have to be globally accessible throughout the coding environment. Individual cells should be referenced with some sort of sigil or read macro– if I can do it however I want, I tend to use something like TableName~Key~ColumnName.

As far as syntax goes for defining a table, it takes at least two lines to specify a table: one to name it and one to list the columns. There could be parenthetical asides for each column name with a regular expression for use with validating incoming data. After those two initial lines come separate rows of comma delimited data. You could maybe use a marker on the table name to specify different delimiters or alternate methods of outlining the data if you wanted. One thing I do is (by default) trim off the leading and trailing spaces before loading up the data into the hashtable (or whatever) that will store it. That way the code for the tables can be prettied up for readability purposes.

The next thing I want is a way of defining objects that eliminates much the boiler plate that I tend to have to write when I code them. I want to go up another level of abstraction, organize everything a little better, and synthesize a lot of concepts that I picked up here and there. This isn’t really a more generic way of doing objects… but more of a specialized implementation of them for a particular domain of problems. I’m probably specifying an awful version of something that already exists, but here’s what I’m thinking anyway.

Your primary component of a widget is its Input or Read-Write fields. These can be modified with a regular expression in a similar way to how we specify table columns. Heck, we could even specify a validation message if some input fails to meet the regular expression. We could also optionally tack on some parenthetical modifiers– default values, markers that note the units of measure being used, etc. In order to fulfill the closure property, some of the Read-Write fields might be other widgets or collections of widgets.

A secondary component of the widget is a set of derived fields. These are specified as an expression that references other fields in the widget and/or tables in the environment. One crazy idea I had was to be so dynamic that some of these fields disappear altogether given certain combinations of Input fields. Properties and methods come, go, and change depending on the values of the input fields. Next there are warnings and errors that are triggered by certain combinations of Input fields. Finally, there should be a suite of events that can be filled in with custom code like you see in typical GUI frameworks (and maybe even CLOS, I think.)

Where I’m going with this is I want to be able to make an interface (both command-line/scriptable and GUI) that can consume these widgets, present the options to the users, and interactively display the results of fiddling with the different values. This way, complex things can be configured by the user… and the programmer can maintain the “model” definitions without having to touch any user-interface code.

I have a domain in mind for applying this framework, but I don’t think I can both develop the framework and apply it given the limitations on time, knowledge and resources that I have. I do have time to develop test cases for a hypothetical system and hone the overall design concept with real feedback from a concrete application. (I estimate that it would take me years to work out a mediocre way to do this… when there’s people out there that could crunch through the core architecture in a weekend or two. And then there are the mondo-evil problems that I haven’t anticipated yet that would likely derail me from ever finishing anyway. So… I’m just tossing this out there to get feedback from wiser, more experienced developers before I waste months of time chasing a dead end.)

(And as with sed one-liners and other kewl Unix tricks, the point of this is not so much the particular domain or example that I have in mind. The point is… someone that can do this and understand how to deal with these issues could code really good maintainable solutions to all kinds of things. It’s this kind of problem that motivates me to study Lisp and other “hard” problems.  There’s no immediate business value to it, though solving this may put you within “5 minutes” of getting something done that is valuable.)

Here’s a “back of the napkin” type example script:


Table Stuff:
	Key[A-Z],Description
	A,Fooie
	B,Barrie

Widget Foobar:
Read-Write Fields:
	Level [Option A|Option B|Option C]
	Weird /GRIBFOO[\d][A|B|C]/ "This is a validation message."
	Stuff [A|B]
	Number [1-72] (in pounds, default to 42)
	MyFoos (Collection of Foos)
	MyBars (Collection of Bars)
	MyBaz (Widget Baz)
Read Fields:
	TableLookUp --- Stuff~{Stuff}~Description
	ExpressionExample (If {Stuff} = "A") --- {Number} * 3 + 1
	ExpressionExample (If {Stuff} = "B") --- {Number} + 100
	TotalOfChildFooThingies --- Sum({MyFoos~FieldName})
Warnings:
	{Level} == "Option A" --- "This might not work."
	{Level} == "Option B" --- "You really hate this!"
Errors:
	{Stuff} == "A" and {Level} == "Option C" --- "Bad {Stuff} for {Level}."
Number_AfterChange:
	print "You just changed the number field.\n";

The Distracted Developer: Tactics and Workarounds for a Fast Paced Scene

September 10, 2008

I recently realized that I inadvertently tune out about half of all verbal instructions. Often I can “squint my ears” and pick up the gist of things by the context and fake it. If I actually start solving a problem, I literally tune everything out. (I noticed this last thing back in high school when I tried listening to music while studying: every once in a while I’d come out to the “zone” and realize that most of the album had gone by and I missed my favorite songs!) Another thing that happens is, if I don’t take care of an issue right away, I’m liable to put it off indefinitely. If I get overwhelmed, I have a hard time picking out what to work on and when.

Being a developer, my knee-jerk response to a problem is to solve it with code. This drove me to using source control for *everything*. And instead of cluttering my code files with large swaths of commented-out code, I cleaned that junk out and checked it back in. If I really need to see that stuff, I can dig through the repository– otherwise, there’s just one last distraction to burn up my productivity as I page through source code. (And who wants to stop in the commented sections every time you do a search?) Yeah, my desk may get a little messy occasionally, but I’ll use every tool and abstraction I can find to keep the code base clean and succinct.

And what do I do with that twenty minutes between meetings? Just blow it surfing reddit? Another trick I learned was to leverage that time with test-first development. Nobody wants to start working on something, leave their IDE open, and then come back and try to figure out what they were doing before. But twenty minutes is plenty of time to sketch out a few tests. And when I come back from the meeting, my brain will have kept working. I can come back and tune up existing tests, fix the glaring syntax issues that weren’t obvious at first, and write the tests that really needed to get written. And if I have my tests already set up and I’ve got maybe an hour between meetings? Well, the tests make it easy to pick something I can finish and check in before the meeting starts. And if I get a six hour block to just focus on my code? (Yes! Yes!) With tests in place, I can go heads down and not have to fret near as much about “the big picture”.

(Essentially, unit tests are a means of sketching requirements and design concepts during a time in which it would otherwise be impossible to think. Someone that doesn’t like to be organized or plan things out too much will do that stuff by default if they adopt a tests-first approach to coding.)

But then there’s the problem of coding something up and then endlessly having to iterate on it. Oh the pain! Yes there’s the hacker approach to eliminating the pain: create a custom scripting language for the problem space and build a GUI that can interpret the script and build itself accordingly. Bam! No more lame design meetings about what color to make the button on form number forty-seven. Next there’s the deployment issue. You’ve got to figure out how to compile and deploy the project with a single command or mouse-click. You will already be in pain if you have to fix something– no need to make it worse!

But there you are… you have the ultimate hacker tool set, yet you’re still miserable. Development is still painful and the gears are still grinding, as it were. What to do!?

You have to get out of your “dungeon” and go talk to people. If you’re a developer in a typical IT setting, your work impacts everyone in the company. You have a good excuse to strike up a conversation with just about everyone. Don’t expect people to open up right away. It may take five minutes for them to start talking about work, ten to start telling you about their problems, and 15 for them to actually tell you what they really think the solution is, but hang in there for it. Also there are the issues that people will tell you informally in the hall or on the floor that they’ll never mention to a manager or bring up in a meeting. Some of this stuff is critical to producing high quality solutions that solve the ‘real’ problems.

So back to me, Mr. Distracted…. I was the guy that got up to go get a drink a water all the time back in high school. At work… instead of going to the Coke machine for the nth time… I can take initiative on go on little “requirements gathering” missions and get something useful done in what would otherwise be a pointless excursion. As a bonus… if I can get the information I need on my own, that’s less meetings to go to and fewer middle managers that I have to work through!

And that guy who couldn’t keep up with his assignments in school? You know… me? Well, I’ve survived by touching base with people frequently. People don’t have to see the guy who can’t pay attention to verbal instructions as long as they see the guy that always strives to clarify the issue and pin it down. People don’t have to see the guy that keeps lousy notes as long as they see the guy that takes the time to personally review solutions one-on-one instead. And that guy who doesn’t do so well planning a schedule? People tend not to notice him as long as they see the fellow who often comes around asking the question “is there anything I can do to make your job easier” and “is there anything that we’ve discussed in the past month that hasn’t gotten done due to the recent overload?”

And yeah, I am the kind of guy that will lock his keys in the car. I’m also the kind of guy that keeps a spare set of keys in my wallet. Yeah… I am the kind of guy that is practically unable to match socks when they come out of the drier. But I’m also the kind of guy that takes a second to safety pin his socks together before he throws them in the dirty clothes hamper. If anything related to my general nerdiness and cloddishness becomes an issue, I’m humble enough to recognize that it’s my problem and creative enough to come up with a workaround to deal with it.

A reminder that I’m not so original…

September 4, 2008

I came across this and after reading back to April or so was surprised to find a collection of quotes that summarize everything I’ve thought for… a long time now.  Looks like I’m a slightly more quirky and moody version of a subset of miscellaneous Paul Graham remarks, Brad Bollenbach advice, zen philosophy, and nerd jokes.  Good to know.  Anyone that couldn’t stomach my last fit of self-critical psychoanalytical naval gazing posts (tl;dr!) can get a much more entertaining rendition of the same theme there– with lotsa pictures, too!

(The generic looking office pictured in the many mug shots there reminds me of the matte background of the endless cubicles in Tron.  To think that something so generically stultifying could have once been glorified….)