Home Home

Teaching patterns

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
130
articles
April 3, 2015

College degrees in IT-related disciplines are known for not teaching some crucial things that every developer should know. Many students may be proud of contributing to dozens of projects, but don't know what a version control is. They might spend months learning design patterns, but never heard of microservices. They may learn by heart the biographies of Bjarne Stroustrup and Donald Knuth, but have no idea who Martin Fowler or Steve McConnell are.

I'm OK with that. Three to five years is a period too short to teach the 600-hundred pages Code complete or a slightly shorter Sam Newman's Building Microservices, and it's not that hard to teach someone how to use version control.

What surprises me more is that nobody teaches students neither how to think like a developer, in other words how to think about problems, nor what patterns should one apply in order to solve a problem.

What is even more surprising is that I recall my years in law school when lecturers were telling us that the goal of spending five years in a law school is to think like a lawyer. And indeed, a few years later, we were thinking like lawyers. I also recall the two years learning psychology, where we were trained to apply specific patterns to specific situations. For example, we knew that there are specific rules to apply when designing and conducting an experiment—a strict approach to follow in order for the experiment to be considered trustworthy by our peers.

We had to learn by heart the names and dates of important court orders, and we had to learn what Freud brought to neurology, but those learn-by-heart things were secondary; what was much more important is those transcendent models and patterns.

It looks like IT-related colleges have chosen another functioning. There are students who know extremely well a specific programming language, or can recite the most used 50 design patterns, but they simply don't think like developers, and they don't really know how to solve problems.

Is it a question of practice? I don't know. My suspicion is that if not learnt in college, this sort of things will be too difficult to acquire later.

Case study: a BSOD on boot

A basic example. A new intern was spending the whole day on a problem: a virtual machine starts to boot, then BSODs and reboots. The intern remained pretty passive, telling to others that her VM is not booting, but not specifically asking for help, and, I imagine, not really knowing what to do to solve the problem.

What would be your actions if you were this intern?

It is not even a question of being proactive. It's as simple as applying a pattern to solve the case:

  1. Go see Windows Events. It practically never helps (because most software doesn't log anything), but it's still a good start.

  2. Check Google. This one works nearly every time. If you have a problem which can be solved, there are chances someone already had this problem, found the solution, and published it.

  3. Try Last known good configuration option.

  4. Start the VM in safe mode to check the disk and system files.

  5. Ask for help (starting by colleagues and ending by Stack Exchange).

When trying those steps, the problem was solved within minutes: the machine successfully started in safe mode, and then restarted without BSOD.

Case study: duplicate entry in web.config

Yesterday, a colleague complains that an ASP.NET application is not working and reporting a error about a duplicate entry in web.config in a relation to Entity Framework.

I immediately ask if there are hierarchical configuration files. No—responds the developer. Given that the question makes no sense (there is necessarily a hierarchy there), let's assume the answer is irrelevant.

OK, we are facing a problem. What could be the pattern? Since we have a error message, the first step of the pattern may be to actually read the message—a task which most developers prefer to avoid, because error messages look scary. Without actual access to the machine, I could only guess that the error is about Entity Framework and a duplicate entry, given that the reference to EF may be irrelevant. Let's search for “web.config duplicate entry entity framework”.

The first result doesn't look promising. It will probably solve the problem, but doesn't explain why the problem exists in the first place.

The second result is much more interesting:

The problem was related to the root directory of the site; I forgot it was pointing to another related project, with this project mapped to a virtual directory. This lead to the other web.config being loaded.

Me
Is it a virtual site?…
Jeff
It is.
Me
Then you may want to check the web.config of the root site.
Jeff
I didn't thought about that. I'll check it.

The funny thing is that it takes seconds to find the answer. Patterns make our work simple.

Case study: scripting languages and shell

The previous article Scripting languages, automation and productivity was all about patterns as well.

The problem is simple. We have Excel data we must extract in a specific format. The solution might not be simple, but the pattern to use to find the solution is:

  1. Split the problem. It looks like an ETL, so splitting it like one makes sense. Extract looks simple: just export the data in CSV format. Load is reduced to anything which can be copy-pasted, such as a text file or terminal output. Remains the transform: how could we do that?

  2. Think about the tools which can be used. In my case, I immediately thought about my own code. It solves the primary problem: calculate the size of the columns and insert the whitespace to align the separators.

    The usage of this library creates another problem: the borders of the cells and the table are not what we expect. The solution looks straightforward: grep. It works, and we get what we need (although it appeared later that this is not the optimal, fastest way).

  3. Implement the whole thing. Easy.

I'm not sure why colleges don't teach their students to think as IT professionals. Why do law or psychology students learn that, but not future developers? It doesn't seem that difficult to teach, and is damn useful during the whole career. Why would any university prefer wasting students' time teaching them PHP?

Because of that, I've seen much more talented developers without a degree than with one. Probably because the first ones know that it's not by learning every namespace in .NET Framework or knowing who Donald Knuth is that they will succeed; students, on the other hand, are trained to rely on learn-by-heart approaches, and just can't have an effective approach of a problem by themselves.