Monday, December 28, 2009

What do you do at the office?

Someone asked me, and I flatter myself that some other reader(s) might want to know too.

I work for (but don't speak for) NetApp, a great place to work. I started there in 2002, after getting laid off from HP along with 20,000 others in the wake of the Compaq thing. I kept my 2002 résumé for some reason.

My first NetApp assignment was on management software -- this was portable C (Solaris, Linux, and Windows) -- then I worked on replication (SnapMirror and SnapVault) for a few years. In 2005, I became part of a "quality team" within the Engineering organization (I told them a "mediocre team" might be a better fit, but they weren't buying), where I helped institutionalize static analysis tools. It's all very well to say "Thou shalt run lint frequently and study its pronouncements with care..." but when you have hundreds of programmers, thousands of files, millions of lines, and schedules to meet -- not to mention interruptions and other pressures of a commercial software organization -- integrating static analysis tools feels rather like adjusting the ignition timing while rolling down the freeway.

Since then I've worked on various other initiatives in engineering tools and our home-grown build system. It turns out that I now write more English prose than code. This is not a big problem, since I do get to code now and then, albeit more in Python and bash than in C or assembly. My current mission at the office is to make life better for development and QA engineers, whether by streamlining some process or making it easier to get at information that's otherwise hard to discover.

Sometimes I do some work on the product (troubleshooting mainly) in areas of logical replication that are not widely understood. Earlier this month I had an opportunity to meet with a customer to describe how we use our own technology in our build and release processes (the dog-food theory) to provide some great advantages to our developers and to the operations folks.

Also, for the past 18 months, I've shared an office with a young fellow right out of college. I've helped bring him up to speed, and I'm very happy and proud to be involved with his professional development. My boss told me a few months ago that I was an "awesome mentor" and that she's never seen a new college grad become a solid contributor in so short a time. (Is there anything in professional life better than that?)

So that's the summary. Any questions, please leave a comment here. Thanks for reading!

2 comments:

Ozan Bellik said...

How do you feel about coding "more in Python and bash than in C or assembly"?

Collin said...

It's fine. Debugging is easier.

When I got started, interfaces (can you say "ibm 029"?) were primitive and the machines were some 3-4 orders of magnitude slower. Even 15 years ago, "/bin/sh" on HP-UX was drastically slower than bash/ksh or Python is today on a machine costing orders of magnitude LESS.

Scripting in those days (JCL, or later, "batch" files) couldn't be used for all that much, whereas today Perl, Python, and the shell can do what used to take "real programming" before.

Short version, it's just fine :)