Generalist

I am a “generalist”, with over 17 years of experience in a little bit of everything – after sales customer service, testing, developer(progressed to tech lead, and architect), and project management. The bulk of the recent work has been on the J2EE platform, with some VB, C, and C++ in the distant past. Even further back, there is a computer science degree.

Java, J2EE

If you are a J2EE shop, invested in web applications, I can hit the ground running, or at the very least be productive in short order.

For the last 8 years or so, these are some of the technologies I have been using to varying degrees of depth:

• infrastructure (JBoss, Websphere, Spring, Apache Commons)
• presentation (JSP, JSF, WebMacro, WebWork, Javascript, HTML, CSS)
• business layer (Drools, JBPM)
• data access (Hibernate, Torque, Oracle, SQL Server, and DB2)
• xml based integration (Apache CXF, JaxB, XSLT)
• text based search (Lucene, Solr)
• configuration management (ANT, Maven, Subversion, some Groovy).

The softer skills

I am not always a clever developer; my natural instincts lean towards analysis, thoroughness, and clarity.

What leadership skills I have tends to be the “lead by example” variety – show rather than tell.

Further, while I can make a clear argument, present an intelligible case, especially when I have time to prepare, nobody would accuse me of being a great salesman.

Enterprise Consulting

I believe I can be an effective consultant – I am aware that significant, if not predominant, challenges in most enterprise consulting engagements are non-technical.

The critical problems are:

• management (manage expectations, negotiate scope, and manage resources – people, and material)
• analysis (business, and technical)
• communication (get the right information from the right sources, and supply it to the right destinations, at the right time).

The programming is often the simplest part of the job.

Finally, having had to deal with off-shore development these past few years, I am cognizant of some of the issues related to this.

Interests

People & high quality engineering

The technical, nuts and bolts, problem solving aspect of software engineering provides real satisfaction.

However, for me the work becomes sublimely interesting only when you throw people into the mix.  Remove people, and I find engineering a little dull.

• Business stakeholders who only know something is wrong, but can’t tell you what the remedy ought to be.
• Business people that know what they want, but can’t describe it precisely.
• IT folk, including business analysts, who treat business stakeholders like adversaries.
• Technical resources that are very bright but lack the discipline for rigorous analysis.
• Programmers of varying levels of skills and cognitive ability.
• Executive management that holds the purse strings, and the whip, but also keeps getting in the way.
• Business competitors that will happily eat your lunch if IT fails to deliver.

In the face of all this, how do you build something of high quality?  This challenge seems never-ending; sometimes maddening, sometimes exhausting, but always engaging.  It makes me want to get out of bed in the morning.

In enterprise environments, as Joel Spolsky says, the powers that be are usually happy with ‘good enough‘. On the other hand, I believe that there is a lot of opportunity for going beyond ‘good enough’, which when taken, can produce value that business can easily see, and appreciate – in improved processes, reduced costs, happier and more efficient employees, and a healthier bottom-line.  How do you negotiate the tension between these two view-points? How do you supply benefits that business does not know how to ask for, or often, does not even know exists?  Another fight, that renews itself every day.

Communication, in engineering

On purely technical terms, any software development activity that involves communication between people, rings my bell.

Code

The code you write is instruction to a machine, but it must also tell a story to the engineer who will read, and maintain your code.

On a day to day basis, the struggle to write code that clearly expresses intent while remaining extensible, and at a larger grain, language design, especially language that describes a domain (DSLs), I find particularly interesting.

Interfaces

Design of any interface that is exposed to another human being (a UI, an API), is an act of communication (Thank you, Donald Norman). In both cases you have to answer the same question – how to convey to the user what she can do with the tool, without having to lead her by hand.

UI design, or more generally product design, which exposes the power of the tool without sacrificing usability, has become a major interest of late.

Requirements and Specification of Solutions

Gathering requirements from business, and specifying a technical response to them, is communication in many formats – in meetings, speaking, listening, helping people get their point across; putting the story (business, and technical) on paper accurately, succinctly (prose? poetry? UML?), such that you have a useful reference, which can provoke effective review, and feedback.

I have thoroughly enjoyed, and been fairly effective at, whatever opportunities I have had to do this kind of work.

Goals

After all the shouting is done, what am I left with?  I am an engineer; I want to build high quality artifacts; I want to see people using what I build.

In the ideal world, I would be an engineer in an environment that sees value in, and actively harnessses my interests, and strengths. In addition, my working environment must make it possible for me to constantly get better at my job, which in turn directly provides value to my employer.

Of course, in this here real world, I’ll take any job that I can hold down, and which will pay my bills ….