Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Design Patterns and it all

During my internship here at Pivotal, I have learned quite a few things. One that happened to become apparent quickly was about design patterns and their role in (actual) object-oriented programming, the stuff that isn’t given a good treatment in school. The entire “gang of four” book was squished into an hour long hail mary lecture accompanied by an irrelevant TA-led 30 minute discussion. Until working here at Pivotal the words ‘factory’ and ‘delegate’ were the centaurs and unicorns of anything that stepped into the realm of code.

I often scratched my chin at why my professor was explaining whether inversion of control had to do with design patterns or foundational software engineering. Literally the week into my internship, a lot of the academic fluff was turned up on it’s head. People actually used these words and they actually have context!? I thought this must have been some Ruby voodoo…until I saw the mobile team discussing these terms also. It was then that it all came together: that 5% of class had translated into a whole state of mind on the battlefield of software development.

After a month into my internship, it was clear in my mind that I would have to switch gears from worrying about the Big-Oh notation of everything I saw to worrying about whether what was done had accomplished the job. Design patterns facilitated this “get it done now” mentality all the time: the delegation pattern was scattered around the Cocoa framework and Objective-C code – that was when the bubble burst from the obfuscated box and pointer to diagram to something (somewhat) tangible. I later saw the proxy pattern heavily used in Android testing frameworks to essentially have communication between the object without the object there in all of it’s stuffy goodness. The Rails world is sprinkled with them: factory and decorators are prevalent in RSpec and Cucumber. The design patterns help preserve the Rails DRY-ness of the tests, making the code leaner and more reusable. These are only a few examples of what has been seen, the list goes on and on while that lecture becomes folklore.

The disparity between software development and academia has grown over the length of my internship here at Pivotal, and it really shows that the 5% in school could be more than 95% in the industry. I hope to elaborate later on the impact that test driven development has had on me in the context of coming straight from academia.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *