On the Importance of Design Patterns

The use of design patterns for software developers is the most important area that one must master. Design patterns are the solutions to problems which are commonly, and sometimes uncommonly, occurring throughout the course of a project. The solutions, in the context of object oriented design patterns, usually consists of the general arrangement of classes. Design patterns provide you with an easy way to create objects, control behavior of objects, and structure your code in the most reusable and robust ways. When interviewing people, I always ask about design patterns and disappointingly enough, 90% of new grads I’ve interviewed will have a 4.0 GPA but cannot accurately write an implementation for a singleton pattern. Seriously?!

During my time at MRG/Emerson, I was interviewing interns (post to come on this) and one of the interns put “Design Patterns” under his skills section. I questioned him about it and apparently his school taught design pattern theory with little to no practical implementations of design patterns. He even received an A in the class. Absolutely ridiculous! I proceeded to write a strongly worded email to the dean of his school’s computer science program, explaining how their “Design Patterns” course is inadequate for listing as a skill on their graduates’ resumes. It was incredibly frustrating that an entire organization, being that school, was ignorant to the fact that they were wasting their student’s time and money with their current course. After a few days, a response was given which in all honesty was eschewing the idea that they have a wasteful implementation of this course. He preceded to tell me that, “He could recommend a few other viable interns who would would be very knowledgeable in design patterns.” His suggested candidates weren’t any better. If you want to impress your interviewing, be able to talk at length about why you chose a specific design pattern and how you implemented it.


Design patterns encourages SOLID principles.

  • Single responsibility principle
  • Open-closed principle
  • Liskov substitution principle
  • Interface segregation principle
  • Dependency inversion principle

The more you use other people’s code, the more you realize the importance of maintaining standards and adhering to a specific guideline. Take for instance the library available on nuget called, NBuilder. This is a unit test object creation library, built upon the builder design pattern. The design pattern dictates how the class must be implemented. We can see below, that a proper implementation of the builder pattern, as used with the NBuilder library, allows for the user of this object to have control over creating custom mocked objects.

 var customers = Builder<Customer>.CreateListOfSize(100)
            .With(c => c.FirstName = Faker.Name.First())
            .With(c => c.LastName = Faker.Name.Last())
            .With(c => c.EmailAddress = Faker.Internet.Email())
            .With(c => c.TelephoneNumber = Faker.Phone.Number())

This is just one example of one pattern though. Searching in the nuget repository and throughout code on github, you’ll find design patterns everywhere. In Entity Framework alone, you have the use of 8+ patterns:

Factory Method, an Entity Framework ObjectContext provides a CreateObjectSet<T> method, which creates an ObjectSet<T> for the given type. Since those object-sets are the main approach to access the entities within a context, I would say it is also a very important pattern used in EF.
Proxy, obviously EF dynamically creates proxy-types for your entities (unless you tell it not to, or it can’t create a proxy because a class is sealed or does not qualify as a “proxyable” type).
Decorator, this might be a bit far fetched, but to implement lazy-loading in proxy-types, the property-getters of navigation-properties are overloaded, to perform the lazy-loading until requested. This is handled in the proxy type, but also depends on whether lazy-loading is enabled and the navigation-property itself.
Interpreter, EF introduced Entity-SQL which is a somewhat generalized form of SQL that also has knowledge of the object-oriented entities. You can define a those queries as strings which are then interpreted by EF and turned into provider-dependent SQL.
Strategy, looking at the various overloads of the ObjectContext.SaveChanges method, you can select from different strategies that are used to determine changes made on known entities.
Memento, the ObjectStateManager keeps track of changes made to the entities and can be used to access those information including the original-values.
Facade, exposing entity-sets as IQueryable should qualify as “a simplified interface to a large body of code”, since turning such expressions into Entity SQL and than provider-specific SQL is a big deal.
ObserverObjectContext provides two eventy ObjectMaterialized and SavingChanges. Since .NET events are an implementation of the observer-pattern, EF also qualifies for this one.


Another less talked about aspect of design patterns is that it gives developers common language to talk about solutions. The pattern is agnostic of the implementation language which puts more focus on a strong idea design rather than getting caught up in physical technological design and language limitations. This enables the developer to be more empowered when choosing which technologies to work with for a given project.

Developers should keep in the forefront of their mind that code should be written in a reusable way, whether or not there are any current plans for reuse. I can’t tell you how many, small or one off projects I’ve had that in hindsight, I wish I spent more time analyzing the design and building for reuse.

Why are design patterns important to me?

If you happen to have read my earlier posts, you know that I worked in the field while attending school. Every project that I coded, for school or work, was very procedural in my head. My brain just didn’t have the aptitude to think abstractly about object design. Well, that is until I took a course on design patterns.

We started out learning simple design patterns. By examining the differences between creational patterns such as the abstract factory and the builder pattern, it all started to come together and make sense. Design patterns make your job easier. Anything that makes my job easier, I’m always advocating for.

The class would normally begin with the professor giving us a problem statement on the board and we would individually or sometimes as teams, figure out a design using one of the Gang of Four design patterns, and then justify our design. This exercise demonstrated that not only is there more than one answer to certain problems, but that collaborative design where there is a common shared understanding of design patterns, yields the best software designs. Out of all the classes I have taken for Computer Science and Management Information Systems, this was by far the most valuable class I have taken.

How do I begin learning about design patterns?

Here are a list of resources I recommend:

“Learning from your mistakes makes you smart. Learning from other people’s mistakes makes you a genius.”


Learning Corporate Culture

After getting my first offer to get paid for actual development, I was elated. I couldn’t wait to start making a name for myself and building innotivate solutions. Keep in mind, I was still pulling in 38 hours a week at the grocery store, full-time school, and this internship which was 40 hours a week.

I began the internship at the Housing Authority Insurance group and was placed in a software subsidiary company called Housing Systems Solutions. They positioned me in the team responsible for taking a popular system that was widely used amongst housing authorities, and reverse engineer some of those features inside a new, modern product. To be blunt, that task was daunting for a brand new intern. It took my team 6 months before I even started to get the code for Midas to even compile. It was written about 8 years prior in Asp.Net web forms. I believe it was .Net framework 2.0. For the first two weeks of my job, my tasks was “figure out how this works”. It was the most boring work to a fresh developer. I wanted to write code!!

My dissatisfaction didn’t go unnoticed. Eventually, I was given some tasks concerning the database. I was delighted at this because I was currently taking a database class focused on SQL Server at my community college; so I wasn’t completely lost. My manager gave me what would’ve been, 1-2 days worth of updating stored procedures but with a little googling and some regex, I was able to complete the task in 30 minutes. My manager was shocked and incredibly pleased at the speed at which this was completed.

I often times would talk to a friendly, talkative contractor on my team named Muzzy. He was an incredibly gifted developer but he had an very apparent stutter that made longer conversations a little cumbersome. Him being an contractor and not a salaried employee, he was not under the same loyalties as the rest of the company. He was on contract and was incredibly aware of the separation of employee and contractor. Having been a contractor at Northeast Utilities gave us things to bond and talk about since I understood, at a basic level, about contractors being “outsiders”. My experience with Muzzy was education to say the least. He mentored me in his own way, telling me things like “don’t drink the red kool aid”. Meaning, don’t buy into the corporate culture that was almost cult like at that place. Dissatisfaction started to grow as a saw a preference for politics and procedure over logic and reason. We were a god damn software company and we were getting bogged down with corporatism, just like Muzzy was warning me.

The main developers of the application were located in Belarus. If you’ve never heard of it, it is on the European side neighboring Russia. A tiny poor country with a unique Belarusian culture. I asked my managers, “Why did you guys outsource to Belarus, everyone uses Indian sources?” His response, “Indian developers always agree with everything you say. You tell them to do something, they do it. There is no push back; they aren’t thinking, they are doing. The Belorussians will question whether you are making the right decision for the good of the company.”

This was my first entrance into a distributed team. We practiced agile scrum and had the Belarusians on the conference line every day at 9am (5pm for them). They often ignored what our project managers suggested and did there own thing. They had an attitude like, “We’re the experts, do it our way.”

Every few weeks, a couple of the business analysts, develops, or architects would come in person to visit. During one of the visits, the lead architect on the Belarusian side, tasked me and Muzzy with creating a stock ticker application in Asp.Net MVC 3, Jquery, HTML, IoC container, etc. I had never used so many different concepts and technologies at once. I was overwhelmed with anxiety of the unknown. Imposter syndrome, feelings of not being smart enough to finish this application; feelings that I am a fraud. But Muzzy and I rallied and took on the this fool’s errand. The rationale for having Muzzy also work on a sample application, was to help demonstrate the capabilities of MVC’s scaffolding and code conventions. We both made pretty weak applications but proved to them that we were capable of contributing to the actual software product they were trying to build.

This was all in the time during which I’m realizing the type of corporate culture they had at that company does not match with my needs which enable me to thrive. Individual needs are often overrun by the needs of the company as a whole. I do not like that one bit. So I began interviewing at many other companies. I was tired of the indirect disdain that senior developers showed towards interns. That their work is less valuable, that they are less of a contribution.

I eventually found a company called SMC Partners in Hartford, CT. I literally had no “real” development experience. I haven’t wrote a single line of code that had seen production. The interview seemed to go on forever — 3.5 hours to be exact. I met with 2 developers, who then passed me onto a manager, who passed me onto another manager, who then passed me onto the CEO. This was unlike any interview I had ever experienced because whether it was intentional or not, it had a dynamic feel to it. The interview was long but the content of our conversations were free-flowing and non-monotonous. I could tell right away that this company would help me grow into my career.

That same night, I received an offer letter with a salary much higher (in comparison to the $20/hr as an intern), that I couldn’t have dreamed that it would be this easy. I was so excited, I didn’t even think to negotiate and eagerly accepted the offer. That was my first big mistake. Always negotiate. Know your worth. Do your research. Research the role, research the company, research what the company pays that role. After, ask for 10% more than what you see. Managers and executives are given a lot of wiggle room with salary negotiations and will respect you more for knowing your worth.

Lessons Learned:

  • Spreading your focus seems like a good idea in the moment to accomplish a lot. Be mindful of getting burned out.
  • Never call a Belarusian a Russian. Two different cultures and they will be offended.
  • Consider the culture of outsourced work. It will be embedded into your project.
  • Always negotiate. They will never offer you what you’re worth, you need to tell them your worth.

All our dreams can come true, if we have the courage to pursue them.

– Walt Disney

The wheels are turning

We left off that I received an offer from Northeast Utilities. I was ecstatic. This was my first “real” job. A job that requires specific skills, not just a grocery store or some other menial job. So I get to the office on orientation day. This is the day where they get all couple hundred interns into the same room and tell you what the company really stands for and how to succeed in my internship. Eventually I am taken with 3 or 4 other interns by the gentlemen that had interviewed me. They dropped off each intern at distributed departments to further learn what real world coding is like. I was so excited — until they dropped me off at the help desk. “With your A+ certification, this would be the best fit.”, was their rationale. I protested and they said next semester, they would get me somewhere more that I wanted. There was nothing else I could do, this wasn’t my ideal job but it was my first foray into corporate America.

I was on a team of about 9 other help desk employees. Our job was to support all technical issues for the entire company. Nationwide, this equated to roughly 8000 employees. So from the hours of 7am to 12pm and 1pm to 5pm, the phones would be ringing non stop. I excelled. I was the youngest person on the team, had lots of energy, had the drive to accomplish my goals, and handled more daily calls than any other person there. A co-worker/friend and I used to compete to get the most calls handled. They loved us there and would frequently get asked to take calls out of queue because we were requested by name. This same co-worker, we’ll call him John, who was a contractor, would routinely ask me to act like his manager for employer references. He was a great employee and highly liked, so I never fully understood why he didn’t just use me as a co-worker reference, but according to him, I had to be a manager to make the reference more legitimate. For him, it was more of the control aspect I think. He wanted full control over the outcome of his interviews and didn’t want any surprises.

I worked my internship all summer until it was time for the internship was over. I heard talk of some interns extending the internship through the school year, so I of course discussed the possibility of staying on the team with my co-workers and manager. John had given me the idea to negotiate a contract gig for Northeast Utilities through the head hunting firm that he was using. I immediately emailed his point of contact and suggested the idea to him. They went for it.

I began working as a contractor for a few more bucks an hour but basically was still in the same role. I continued to work this job while utilizing my free time to interview for roles focusing more specifically on development. In hopes of creating business connections, I would frequent the company directory and message developers and development managers asking for the opportunity to shadow them and see what this job is really about. I met with someone who I had a family connection with and worked side by side with him for a couple of hours. I was asking him questions about workflow, technologies used, system overviews, etc. This is where I first realized that this job is only difficult, if you make it difficult. There’s something that he said to me that always reverberates inside my mind whenever I’m starting a new project, “Always build your application for the web, only use desktop applications when the web cannot do what you need the application to do.”

I took these experiences with a heavy heart and channeled that fire building inside me to seek other employment that would allow me to create applications. I found that employment with the Housing Authority Insurance company as a software analyst/programmer intern. The wheels are finally turning.

Lessons learned:

  • Manager references are more legitimate. Use these before any peer references.
  • Never limit yourself into thinking xyz is impossible. It is improbable that most things are impossible.
  • Don’t be afraid to ask someone to shadow them to learn about various roles. In all likelihood, they will be incredibly flattered and will help you.
  • Modern careers are dynamic, don’t worry if your resume shows you jumping around a lot. Every possible flaw an interviewer can find, can be properly spun in your favor.

What lies behind you and what lies in front of you, pales in comparison to what lies inside of you. –Ralph Waldo Emerson