My conversation with Ben Schomp, April 2011

Ben Schomp received his B.S. degree in computer science from URI in 2001. While a student, he worked at WebMachines, a small start-up company, and was an undergraduate teaching assistant. He currently is employed by Vector Software as a senior software engineer.

FMC: Why did you major in computer science, Ben?

BS: Growing up we had an Apple II in the house, but my father wouldn't buy any software for it; it was basically a glorified word processor. I asked him for an Atari or a Nintendo and he got me a book on programming text adventure games in Applesoft BASIC.

After that I was hooked and would buy my own magazines and books, eventually moving to QBasic on an IBM 386 I salvaged from my neighbor's basement. However, once high school hit, I took the one “programming” class that was offered and that was it until my first year of college.

I'd enrolled in Electrical Engineering because it seemed like a fun career pathto design and build electronic things. As it turned out, I most enjoyed the required Programming for Engineers in C course. It was my first (but brief) introduction to Linux, X, and telnet. I spent more time doing extra credit work for that throw away class than I did for my major-focused circuits course.

Again, not knowing there was more to learn, and having no one to point me in the right direction, my next semester was nothing but EE, physics, and calculus. It wasn't until I transferred to URI and had to choose my first classes, that I tried looking for “computer programming” in the course book and first became aware of Computer Science as a discipline.

Once I read the curriculum and course descriptions, I don't think I considered anything else! I think there's still a fair amount of mystery for recent high school graduates about what CS is and who should be considering it. Add to that terms like computer programming, computer engineering, information technology, and management information systems and it’s amazing I ended up where I did ... but I'm glad I did!

FMC: Let’s begin with your time at WebMachines. How did you get this position, and what did you do?

BS: WebMachines started as a paid internship through URI. I was recommended by a professor (you!) and a classmate who had a friend who worked there. This was my first lesson in networking (we didn't have Facebook and LinkedIn back then).

It’s clear to me now that this internship laid the foundation of my applied software development skills. The URI coursework help me learn the theory behind the day-to-day decisions—to know the right and wrong way to do things; how best to attack hard problems. Yet cutting my teeth on actual development tasks, being exposed to open source software, learning Unix system programming, and working with experienced engineers in the field was really where it all clicked for me.

It was exhilarating to jump from the nice, cozy world of Java CS homework to designing and implementing systems running on a custom embedded Linux device: being constrained by low memory requirements, worrying about device drivers, interfacing with Apache and MySQL, utilizing Bash, Python, and Perl—doing whatever it took to get the job done.

And fun! Working with smart people motivates me to do better; to learn more. I can't credit and thank my WebMachines colleagues enough for showing me the way. There's a certain arrogance that is often found in software development. I suggest all up-and-comers abandon this mindset immediately, find a mentor (or five), and soak up the knowledge. There is always more to be learned.

FMC: How did you get your position with Vector Software?

BS: When I graduated from URI, some of the WebMachines folks had taken jobs with Vector just up the road. Programming in C/C++ with open source tools on Linux? Working with my friends in a casual environment for a small company offering full benefits? Sign me up!

FMC:  What does Vector do, and what have you done?

BS: As software becomes more ubiquitous in modern products and systems, companies and governments are recognizing the need for standards and/or accountability for the behavior of that software.

Most engineering disciplines have centuries of successes and failures on which to build a set of rules, regulations, and best practices. Software engineering (for good or bad) tries to move at the speed of Moore's Law! And however rigorous and well-intended the best of us may strive to be, the complexity of software systems can often mask potential problems. Or, we just write buggy code—it only takes one unaccounted for use case to bring the whole thing toppling down.

The industries where software accuracy is of critical importance (aviation, medical, military, aerospace, automotive, etc.) have hard requirements for the developers to prove that their code behaves a certain way under certain conditions. There are varying levels of certification depending on the potential results of software failure—the most strict of which can be quite overwhelming.

At Vector, we build software tools for software developers to run their code through repeatable tests, which document the overall correctness of the system. Ultimately, this leads to industry certification and deployment on things like airplanes, missiles, and heart pumps.

Personally, I have done almost everything you can imagine at Vector: from writing low-level libraries in C to implementing front-end feature requests in C++; writing extendable, automated document generation frameworks with Perl and LaTeX; creating platform-independent user interfaces with Java; finding deep bugs in Ada; improving core algorithms; performing process automation with Python; teaching classroom-based training courses; and providing on-site engineering and technical support for customers.

Working at a small company is great because there's always something different to be done. You can change the things you wish were different, and you get to see the results of your efforts directly affecting your customers.

FMC: Did your college education adequately prepare you for your first and current positions?

BS: Yes and no. I think one of the greatest lessons I learned is that we have the tools to solve some very hard problems. Rarely do I have to use the multidisciplinary techniques we learned in our 400-level courses; but when something large and complex comes up, I'm unfazed by it because of my education. And even though there are many different ways to solve these problems, my core background reminds me that there are right and wrong ways to implement the solutions. I'm able to identify and avoid potential pitfalls and pinpoint where existing pieces can be improved.

I think where my education lacked was in the day-one, hit-the-ground-running applied developer skill set. Obviously the speed of technology is so fast that any CS curriculum needs to focus on the theory and large scope issues of computing. However, I count myself lucky that I chose the internship that I did. I'm not sure where I'd be today if I'd simply built a flat website for a local business for a single semester.

The good news is that the Internet is so much more useful than it was when I was at URI. There are so many more resources available: forums, discussion boards, tech news aggregators, sourceforce, github, screencasts, developer blogs, fast, relevant (and sometimes independent) book publishing, and blazing hi-speed download speeds mean the entire world of applied software development is there for the taking, to anyone interested enough to go looking.

FMC: How hard do you work? Does your career leave you with enough time to enjoy life?

BS: I try to work efficiently, which means I try to write algorithms that let machines do the “hard” work for me.

Traveling can be difficult at times with a young family at home, but modern screen-sharing applications like WebEx or GoToMeeting have significantly cut my need to visit customers.

I enjoy what I do, so that helps me enjoy life since so much of what we “do” is who we “are.” I make sure that my hours don't cut into evenings and weekends, and I refuse to allow myself to slip into an always-connected lifestyle. I'm in front of a screen all day—I  don't need social networking taking over my nights. I like to come to work enthusiastic about the day ahead. Avoiding always-on screen time burn-out is a personal goal of mine.

FMC: Can you give some advice to our current students?

BS: Yes! As those who know me will tell you, I'm almost always spouting off advice about one thing or another...

For me, my time at URI was where I “came into my own.” I credit this with the drive and focus I applied to my work in the CS department. Since I was a transfer student and most of my math and science requirements were out of the way, I was able to dive in and spend my time at URI taking three and four CS classes each semester. It was a very engaging time for me!
I immersed myself in the material, but also the department. I first worked in the Envision Lab and then as a CS tutor, a CS teaching assistant, and eventually a CS instructor. Getting to know the people in my department—not just the professors, but other CS students, administrators, advisers, etc.—was a huge factor in my personal success at URI. Involving yourself in this manner and building relationships develops a sense of place and community and holds you to a higher standard of accountability. Don't just drift in and out of class—you’re building your future—take it seriously and strive to do your best, always!

Here's a list of things/skills/principles I think all CS majors should take advantage of, if they're interested in a successful career:

  • Learn and embrace open source tools:  Visual Studio is nice and convenient, and F5 is your friend; but gcc and make via the command line force you to learn what's actually required to build a software project.

    Also, these tools are free! Had I known I could have taken my old PC and installed a free OS with all the essential build tools to do all my CS homework, that would have been one less credit card payment during those college-poor years ... books are expensive enough as it is.
  • Choose a text editor and get good at it:  My personal choice is vim but emacs, TextMate, and Notepad++ are all viable options. Moving around quickly, substitute/replace in bulk, recording macros, handling indents, etc. are all things you should be able to do without thinking. Don't get hung up in the debates about which one is better—it’s like pencil or pen; just choose the one that fits best in your hand and get coding!
  • Become a command-line and PC “power user”:  In order to efficiently coerce these machines into doing what we want them to do, let's use the tools that were put in place by our predecessors. Yes, you can get there by pointing-and-clicking your way through life, but software developers should have basic fluency in all user interfaces.

    I've traveled all over the world as a consultant and trainer. If I have to explain to one more software engineering professional what an Environment Variable is and how to set your system's PATH, I just might blow my stack.
  • Learn the popular languages:  Don't get hung up on the oldies, just get through the basics on the ones people are using right now: C, C++, Python, and PHP. Then tackle Java, JavaScript, Perl, and Ruby. And make sure you pick up SQL along the way.

    If I were to do it all again, I'd work through each semester with a different language as my 'goto flavor' until I knew what was what.
  • Read books:  Yes, your text books are big and may seem to have more words than could possibly be needed—and why buy books when everything is available online for free, and PDFs and Kindles are taking over? But I like a nice physical book that can sit on my desk and be highlighted, annotated, dog eared, bookmarked, and referenced again and again. Plus it makes me look and feel smart sitting on my shelf. The Pragmatic Programmer should be required reading before issuing all programming licenses.
  • Don't forget what you've learned:  Web programming requires good decisions too—sometimes even more so than applications development.
    If your first job out is web-something-or-other, don't think that just because you're on Rails, or cranking out straight line PHP, that good software design principles don't apply! The world is full of bad programmers taking bad shortcuts and deploying bad software—don’t be one of them!
  • Make friends:  Talking about CS concepts with the people sitting next to me in class really helped me grow my passion for software. Just think, we could be taking economics classes—let’s get excited!
  • Seek advice:  This isn't high school. Go talk to your professors and start building relationships. We're all here for the same reason, we're all on the same team, let's work together and enjoy the ride!
  • Raise the bar, stay humble, don't take the easy way out, and have fun!

No comments:

Post a Comment