What Makes You Architect?

In the past few years, I have participated on many interviews. I met several different kind of IT professionals, mostly programmers. I was the one who is seeking for the best possible person for a given assignment, and they were the applicants. Sometimes it was a junior assignment, some other times it was a senior or even an architect job. The applicants had to solve a preliminary test first, and I saw only those who has succeeded.

The first lesson I have learnt soon was that the number of years of experience has only a very limited impact on the suitability of the applicants. Sometimes the ink hardly dried on the diploma yet the just graduated newbie was lightyears ahead of others with several years of experience. In other cases the applicant with over 25 years of experience applied for an advanced but not really senior assignment, and during the interview it turned out that not without reason – he still was not on the level that fits for a senior, and he apparently knew it well.

Just recently I have started to think about the reason, and I think I’ve found a possible one. Those people who advance rapidly think very different than those who stay on a lower level for an extended time. The people of the former group see behind the curtains, they know why the things work that way. The latter guys’ knowledge is shallow, and they usually stick in the technical implementation (they know the how’s instead of why’s).

Let’s see how it works. First question, explain the Java’s volatile keyword.

Answer x: The volatile keyword marks those variables that are shared and possibly modified concurrently by different threads. These variables are never cached, and their access is synchronized although it is never blocking.

Answer y: The volatile keyword marks the variables that are not allowed to be cached, because another thread may modify them. These variables are accessible only on a non blocking synchronized way.

One might think that the two answers are the same. That’s not really so however. Answer x clearly describes the meaning behind the keyword, and tells how that behaviour is implemented. Answer y tells what’s happening, but feeling that it’s just half of the story, adds a reasoning too.

To make it even clearer, let’s see another question. Explain the Java’s transient keyword.

Answer x: The transient keyword marks those fields that are not part of the object’s persistent state. When the object is serialized, these fields are ignored.

Answer y: The transient keyword marks those fields that are not serialized with the object.

Now it is obvious. From the applicant's point of view answer y is full, that’s what really happens, so no more reasoning is necessary. But only answer x is full indeed, because it gives hint when should one consider the use of the keyword too, not just tells the effect.

So answering the question presented in the title, having the why’s instead of the how’s in mind is what makes someone architect. The experience is still needed of course, the architect must have a hands on knowledge on many technologies in order of being able to make good decisions. But the experience alone is just not enough.

Kategóriák

Címkék

Komment

Még nincsenek kommentek.

Mondj valamit

A szövegben nem lehet HTML-t használni, a linkeket pedig automatikusan aláhúzzuk. Az email cím megadása kötelezo, de az oldalon nem jelenik meg. Ha van freeblogos felhasználóneved, itt bejelentkezhetsz.

Az IP címedet megjegyezzük, de ezt csak a komment spam jellegének vizsgálatához használjuk fel.