Not Just a Software Engineer

While my official job title is Senior Software Engineer, many times I’m also:

  • detective, historian,
  • logician,
  • aesthetic judge and grammarian,
  • and salesman and/or marketeer

There are other roles I play, as well.  Sometimes as maintainer of existing software, less often as initial designer, but still…

Although it is not, in the general sense, productive to figure out “whodunnit,” it is sometimes necessary and useful to find out who did the original writing of this piece of software, or who was the last person to change it, in order to answer why was this done — there may be a reason, which is important to preserve, and not simply undo the effect.

Frequently, at least in my work, the answer to the preceding involves digging thru history, recreating the past — fortunately, modern software development entails using a  version control system, which tracks who changes what, when.  Just recently it was the case, not uncommon, that the problem was not caused by any particular change, but the cumulative effect of several changes — and those are not always related!

In some situations, more often than not long after deployment to a production environment, the process of debugging involves a strange mixture of “reading tea-leaves” and guessing, based on extrinsic information (by “reading tea-leaves” I mean guessing about the current state of affairs by viewing only partial, random, sometimes seemingly meaningless bits of information).  Many times it becomes necessary to deduce the scenario causing the problem based on contextual information and situational data, and interpolating the flow of a program with incomplete knowledge — then it is almost like solving a sudoku puzzle: “the actions taken in the intervening time (where we have no direct knowledge) must have been thus because the information at the beginning and the results indicate that this is the only possibility.”  (“The number in this square must be six, because that is the only remaining value for this row/column and square of nine.”)

Let me add here two personal notes: first, none of this is a shocking revelation — not to those who do this work regularly; secondly, this is sometimes the interesting and exciting part of my work — sometimes, decidedly not, but at times, historian/logician is an exciting occupation of my time!

There are times — more frequently during initial development of new software — when the right choice of various competing alternatives, is determined not by logic alone, but by what “looks pretty” — at least in some sense, what is aesthetically pleasing — or what will, in the long run, prove “easier.”  The reasoning may run like this, “yeah, you could do it that way, but no one looking at this later will find it intelligible.”  Sometimes like grammar rules, the justification for a choice is, “that way is the one which flows easily and nicely, and according to tradition (not always a bad thing).”  In the past, more than today, I rebelled against this idea: “why did I spent years learning how to do this [complex technique, or obscure solution] only to continue coding at a ‘high-school level’?”  But age and experience have softened this: someone else will come after me and, if I make things difficult, curse my work.

Finally, salesman and/or marketeer: none to infrequently, I need to sell my idea to others — persuasive skills are usually required, be it a fellow developer, or a business user, a client or other co-worker.  I find myself more often than not more than just presenter of options, but also advocate.

But here’s my point in all this: they don’t teach you this in school! Computer Science education almost never covers most of the debugging skills you need almost immediately when you enter the work-a-day world.  My high-school and college did little to prepare me for a career in convincing other people to my point of view — oh, I did get that education, but not formally in a classroom (save one experience in a speech class, and that not very well!).

No one told me, when I was learning any programming language, that there is more to it than actually designing and coding — you have to pitch your ideas to others, work with people, and work after people; we never did anything even close to that in any class I can name — with people, once, my senior year, but after other programmers, doing maintenance and debugging?  Not at all!

So I’d like to hear your experiences, esp. other computer programmers, but any engineers, or, for that matter, others in any field who happen to read this.  Please give me some feedback; I may incorporate your comments here, and expand on what I’ve said.

Advertisements

One Response to “Not Just a Software Engineer”

  1. Lana Says:

    I wonder how often this is true, that the schools don’t teach the skills we actually need in our fields. They are good at teaching theory, but not “rubber meets road” skills (in my case) or “sales pitches” in your field. We could start a “these are the skills you will REALLY need in this profession” school and make millions!!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: