On object oriented dragons and improving my ability to learn

I’ve been meaning to write this post for a while now even though it’s been 2 years since I’ve completed my Masters in Software Engineering.

Those of you who follow me on Twitter may have seen a number of tweets related to my graduate career. You’ll need to understand a little more about my technical background to learn why I decided to undertake this fairly arduous effort.

I’ve been working in this industry for almost 15 years now - half of which has been primarily focused on operations/systems engineering the other half on software development.

While I did have a programming background prior to my Masters - it was largerly procedural and primarily consisted of small Perl5 (yuck) data processing scripts. I never dared to delve into Perl5 object oriented programming, not because the implementation was hacky (I wasn’t even aware that it was at the time) but mainly because OOP was cognitively inaccessible to me.

More on cognitive inaccessibility later.

By the time I had completed my undergraduate degree in Cognitive Science I’d say I was a fairly decent Perl5 programmer - having taken what was equivalent to a years worth of Computer Science classes - e.g. intro to programming in C, basic data structures and algorithms and discrete math. In spite of this I continued to avoid learning OOP and I even wrote it off as something that only real software engineers worked with.

Yeah folks - imposter syndrome is a real thing and even though I was programming in Perl I never thought of it as “real code” - primarily due to comments by other engineers that I’d worked with regarding “scripting” versus “programming”. Developers who think that dynamically/loosely typed languages like Perl, Python or Ruby aren’t “real” programming languages need to get over themselves. Might I recommend a hefty amount of “humble pie”.

I’ve always strived to be “generalist” engineer - primarily because I love learning and limiting my career to just one area of software development is ridiculously boring. I have a very gestalt or systems thinking approach to solving problems so naturally I’m keen to learn and be exposed to different roles in the SDLC.

It wasn’t until early 2009 that I realized that my lack understand of OOP was severely limiting my ability to function as a generalist engineer. At the time I was working for a startup as a “DevOps” engineer (this was before those types of roles existed) with a small team of developers. Suffice to say, that work environment was extremely toxic and while I won’t go into detail as to why this was the case - my inability to speak the same language as these developers (namely OOP) made it that much more challenging for me to communicate with them.

I’d like to stop here and point out that I am not saying all operations/systems engineers need to go out and get a degree in Computer Science or Software Engineering in order to communicate effectively with software engineers. The mere idea is preposterous. My point is that as an aspiring generalist engineer - I wanted to be able to think and learn like software engineers.

I standby devops culture and ideology - any software engineer worth their salt is going to spend the time working with operations/systems engineers to make sure their software is operationally sound.

But I digress …

After leaving the startup in 2009 - I decided to pursue my Masters in Software Engineering. I was ready to face the OOP dragon head on. Frightened and feeling relatively deflated I enrolled in a pre-masters program at DePaul University. While I had already taken most of the classes in the pre-masters program I wanted a fresh start to be able to grow my confidence in my programming abilities (moreso my ability to learn) before diving head long into the Masters program.

The first class I took at DePaul was Java for Programmers (CSC 224). I was fortunate to have a professor that focused less on the Java API and more on key OO concepts like encapsulation, inheritence/composition and polymorphism. His resounding statement was:

“All of you already know how to program - I’m not going to teach you syntax - you’ll be learning how to write proper object oriented code”.

Remember when I mentioned that OOP was cognitively inaccessible to me? After taking CSC 224 that slowly started to chip away. It wasn’t until I took a graduate level class in object oriented design patterns (SE450) that I really began to feel that I could tame the OOP dragon. Concepts like composition aren’t easy to grasp but things start to click have a professor that says things like:

“Your interfaces are supposed to model the ‘behavior’ of your space simulator movement”

That’s when the fun stuff started. That’s when I felt confident enough to dig into core Chef to implement my own “heavy-weight” resource providers. That’s when I started to really feel comfortable in actually learning the Java API.

Case in point - a shining moment of my graduate career was when I helped a data scientist I worked with at the time - rewrite their clunky machine learning data filter using Java comparators instead of mess of code that involved sets of hashmaps and a really janky implementation of quick sort. Yeah that felt real good.

If you’re an operations/systems engineer that wants to learn object oriented programming - don’t be discouraged. Go learn. You’re fully capable of doing so. Don’t let some nasty brogrammer tell you otherwise.

Everyone has different learning styles - for some it’s getting a copy of Head First Java. For others like myself enrolling in classes or a degree program is what it takes to get over that cognitive brain cloud (aka cognitive inaccessibility).

In hindsight I’ve come to the realization that I didn’t just learn object oriented programming from my graduate studies - I improved my ability in learning how to learn.