An Analyst's View of Programming

It's an odd thing, working as what's known as an "MI Analyst". What's my job about? Getting the best information out fastest with the smallest amount of maintainable code. A large chunk of my value to the company is my understanding of the data tables, the meaning and reliability of the data in them (what are the values and meanings of that flag?) and the processes by which the tables are produced. So I can interpret or avoid some of the anomalies ("use that table instead of this one for that exercise, it's faster and the data is, errr, more reliable"). Another large chunk is the ability to translate business-speak into data and code, suggest other things the user might want to look at, and remind them of the various odditities of the systems. The business doesn't set a lot of store on my technical competence as a programmer (in the sense of design+coding). Which seems an odd judgement, as the better I am at it, the better I work.

I have a very different focus compared to a full-time developer (code hacker), let alone a full-fledged LISP junkie. I'm not really interested in neat programming tricks to solve a problem in number theory. I am interested in how to use a language to help me achieve a task. I'm not the guy whose code uses bit-arithmetic - I'm the guy who writes copious comments and gives his variables meaningful names. For me, the languages are tools I use to get the job done, not something I think it's cool to know more about. The day I have a problem (and far more importantly an IT environment environment) best solved in LISP will be the day I learn LISP.

You'll notice something here. I have enough background to know that LISP exists, what it does well, how it differs from YACL++ (Yet Another C++-style Language), and what kinds of problems it might be good at solving. That kind of background knowledge is, to me, one of the things that separates a senior from a regular analyst. It's why I advise the young 'uns that they must scan the manuals. I scan the manuals so I know what the tools can do, not to memorise it all. Then when a new task comes along, I have an idea that this or that tool may have a feature that make my life easy. (No. Using the internet won't do. It encourages a script-kiddie attitude and works best for very specific tasks. It doesn't really work for a general problem.)

One more thing. Notice that I said I put lots of comments and used descriptive variable names. Anything can be done with proper style, and should be. It doesn't matter if I'm writing a little bit of SQL or a VBA class with a bunch of methods, I want to do it so it looks the part and makes me look the part. Call me shallow and superficial, but it leads to good code. And that ain't bad.