Tuesday, January 24, 2012

On Programming Languages

I know several/many programming languages.  I've written code in C, C++, Java, Python, Perl, TCL, fp, bash, ksh, Pascal, FORTRAN, Lisp and PHP.  I have "extensive experience" in perhaps three of those languages - PHP, Perl and Python.  Overall, I've got over 15 years of Software Engineering experience.  Not "scripting"; Software Engineering.

At every job I've taken, I've exceeded the expectations that the people hiring me had for me.  At my last group at Sprint, I got hired as the "script writer".  Within four months, I was the technical team lead.  I was hired to do TCL and Perl scripting.  Within a month I was trying to teach "Java Programmers" how to write Java code.  Oh, they knew how to construct an if-then-else block.  They knew how to connect to a database.  They knew how to write a class and fill it with methods and member variables.  But they had no idea how to design an application.  They had no idea how to build components.  They were forever re-inventing the wheel.  I became the technical lead on that team because I was the strongest software engineer they had.  And I was the script writer.

After a year or so of working on my projects and helping out where I could, I started to tackle some of the fundamental issues the team was facing.  When we deployed an application it required a rebuild.  There were hard-coded references to servers and URIs and file locations that had to be changed when we took code from development and put it into production.  For Java applications, this required a recompile.  So we never tested the code that went into production.  Deployment was always fraught with peril.  So I decided to fix it.  I wrote a set of comparable classes in Perl, PHP, TCL and Java that would all read in information from the same server specific configuration files.  A series of overlays would allow config files to be layer on top of one anther to achieve a state where you could deploy the same code to any development or production machine and it would pick up the right configs - no recompile was necessary.  And all four languages we used could use the same set of config files.  All of a sudden, deployment was a non-issue. 

I didn't write much Java.  A couple of classes.  Hack some method calls into places where we previously had hard coded strings.  But I knew WHAT Java code to write.  I knew how to write it.  And I was able to integrate that code into a diverse environment so that it lived and played well with the rest of what we were doing.  Which was more indicative of a fundamental understanding of Java and an ability to write good code?  The couple of classes that I wrote?  Or the 25 Java servlets that had to be recompiled when it was time to migrate from development to production?  Who would claim "extensive Java experience"?  Who do you want on your team?

Yes.  There is a point to this.  I want to work for Google.  I think I would fit in well.  But they've got this bullet item front and center:

  • Extensive programming experience in C/C++ and/or Java
I don't have it.  I have extensive programming experience.  But I don't have extensive C/C++ or Java experience.

No comments:

Post a Comment