The number one question I get in any job interview goes something like the follow:
Interviewer: “So, Scott, I see here you were an English lit major.”
Me: “That’s correct.”
Interviewer: “So, tell me, how does an English major end up in the IT systems world?”
I get this without fail. Every interview I’ve had for the last ten years.
So, how does an English lit geek become a IT systems geek?
It started with Borders Book and Music. Remember them? They were the upstart to Barnes & Noble that eventually became a chain themselves, and so unwieldy a chain that they could not react fast enough when the nature of retail changed (thank you, Amazon), and they went belly-up. I was finishing up my degree at the University of Maryland and working as a lifeguard in a hotel. It sucked, but it was decent money, and the staff (mostly) got along well enough. Then someone suggested to me, “Hey, you’re an English major, why don’t you work for Borders?”
To quote Bill Engvall, “That sounds like a superb idea, my friend!”
I loved being a bookseller. I went into Borders and stayed with them full time for five years, and part time for five more after I left. People ask me sometimes what I could do if I could do anything, and the answer is always “be a bookseller”. I love finding books for people, people searching specific titles, or just a suggestion for something to read. And the harder the search the better.
Alas, as much as I enjoyed being a bookseller, I enjoyed eating more, and being a bookseller doesn’t quite cover all the bills. (So be nice to the staff the next time you go into a bookstore, cause they’re there because they love it, not cause they’re raking in the dough!) But money was only half the issue. I was, after all, on a management track and was probably a year away from getting my own store. No, the bigger problem were the hours. Eventually I decided that I really wanted nights and weekends back. I hadn’t seen a full set of either in five year. And holidays? What are those?
So I decided to make a change. I decided to look for something new. But I had all of this retail experience now, so retail seemed to be the perfect choice. But not in the stores. I wanted to see something in a corporate size and color.
From here on in, I’ll refrain from naming companies. Border is all well and good (and gone), but the rest are still around, and I don’t want to cause trouble. Not that I plan to badmouth them, but people (and the Supreme Court has taught us that corporations are people) can be touchy.
I wandered through a series of jobs and a couple of companies. I learned Excel in bits and pieces. And slowly, very, very slowly. I was a bookseller. I’d never seen a spreadsheet before. And macros? What the hell is a macro?!? People showed me a few things, both in spreadsheets and then in the macros underneath. My Excel experience grew. It was not, however, exponential growth. There were some things I could not get my head around. Things like variables. How could something start with one value, then, halfway through a process change values? That’s crazy talk!
Eventually I landed at a company with a boss who was very forward thinking. He always had the next five steps planned even while we were all taking the first. He was the one who really pushed me into programming Excel. I was administering a system that I had become proficient on in the last six years of constant use. It was the first major application I learned to use after leaving Borders, a heavy-duty replenishment and inventory management system. I had been hired by this company to administer this system, and I did do some of that. But my new boss pushed me into programming. He saw a gap that didn’t really exist, and created the need to fill that gap. It was all about expanding the power base, and he was damned good at it.
My first application was this piece of shit I built called the SKU Tracker. This thing was terrible. My boss and the business representatives told me what they wanted (something I would later learn were elusive and skittish and typically called [gasp!] “requirements”) and I set about building it. I won’t lie, that thing was built by Google. I had no programming experience and no idea how to even begin. I remember one part of that thing ran in a loop doing calculations and creating sub totals without using the SUBTOTAL utility in Excel. I must have worked on that loop for two weeks before it worked. In the end, that thing was functional, but held together with toothpicks and duck tape.
And that was it. I was hooked and off to the races. I bought Excel books of every kind, and built tons of applications. I was contracted with one company to build a new merchandise planning system for them out of Excel and Access. Since that crappy thing called the SKU Tracker, I’ve continued to read and experiment and program and fail and succeed and curse and smile and now, write about Excel.
And that’s how I came to be an Excel Geek.
3 thoughts on “Excel Geeking: How I Came To Be An Excel Geek”
Hi Scott – I just came across your blog today searching for VBA related to OneNote and then I read several articles. Great writing style. Enjoyed the humor and slant. Subscribed!
Regarding rabid Excel converts, stranger things have happened I suppose. I have a music degree and have been working in a corporate accounting role for a number of years. Weird right? I too have labored for years to get decent at Excel and have most all of the books you mentioned and peruse the sites you’ve recommended. The more I learn the more I recognize there is yet infinitely more to learn.
I do have a question if I may – when referencing cells (which I realize can be done a number of ways), I notice most code I read, for example, will tend to us Cells(1, 26) instead of Cells(1, “z”). I think the 2nd version is much more friendly when stepping through a macro for validation as well as troubleshooting. Is this just not the way the cool kids code?
I’m assuming the “z” in your example is supposed to be the column Z? As far as I know, the Cells property only accepts numbers, though I’d have to check. I’ve seen some examples where the column letter is captured and converted to a number, usually using a ginormous Select..Case statement. But one of the benefits of referencing your columns as numbers is that, if the range you’re referencing on a sheet shifts over by one column, or if you have to iterate through a range of columns, its a lot easier to do that by just incrementing your column number than changing all your code from “z” to “aa”.
By the way, glad you’re enjoying the blog. You’ll find it’s rather…eclectic.