Should Have Listened
Originally published at Kyle Boddy. You can comment here or there.
When I was 16 years old, I took a generic personality/work test at my high school that mapped my answers to basic preference questions ("Do you enjoy working alone," "Do you work well with others," "Do you like mathematics," and so on) to a list of potential careers that would theoretically match up well with my computed personality. I only remember two of the top five: Nuclear Physicist and Systems Analyst. Despite only being 16 and quite arrogant about my intellectual ability (tempering this feeling came during my first year of community college through Post-Secondary Enrollment Option - known in Seattle as "Running Start," but that's a subject for another day), I knew that I was not smart enough to study physics at any reasonably high level, and Systems Analysis seemed fairly interesting to me.
Systems Analysis as the program described it essentially boiled down to translating the nerd speak from the pocket protector-wearing scientists to plain dumbed-down English for the business suits at the executive levels. I knew that I didn't want to sit in front of a computer and write hundreds of lines of code (ironic, given my current occupation) per day, but that I also wouldn't be happy being a middle manager of sorts, so it seemed like a natural fit.
Ten years later and I'm just now learning this for the second time: I love designing and analyzing systems. It's the only thing I'd say I'm very good at - my ability to translate unnecessarily complex ideas into plain English (and vice versa). It helps that I'm also a quick study; I pick up new skills and areas of study rapidly, though my interest tends to wane as diminishing returns kicks in.
I've also learned that you can call a "Systems Analyst" a lot of different things: Quantitative Data Analyst, Rapid Application Developer, Project Manager, etc. I define a Systems Analyst as someone who does the initial legwork into understanding an unknown (or little known) project and mapping out the basic details for the developers, business units, and executives. Sure, the tools are different based on your title, but the task at hand does not change meaningfully: Describe (or invent) the system, propose solutions, and be able to think multiple steps down the line with the possible implications of your solutions. Whether you use PHP, Java, Matlab, Excel, Calculus, Powerpoint, or flowcharts, it's just a matter of language and context.
There weren't a lot of things I was correct about when I was 16, but this was apparently one of them. Oh well.