Emotionale Blickführung

Für diejenigen, die nicht Motorradfahren oder sich damit beschäftigt haben, mit Blickführung ist das Konzept gemeint, dass das Motorrad dorthin fährt wo man hinschaut. Das bedeutet, dass der Fahrer z.B. in Kurven nicht vor das Motorrad sehen soll, sondern zum Kurvenausgang hin. Genauso soll man immer den Blick heben, also gerade aus schauen, und nie nach unten, d.h. vor den Reifen. Dies hat zum Ziel, das Gleichgewicht besser zu halten, da so auch kleinere Bewegungen des Motorrads leichter wahrgenommen werden.
Ein weiteres Konzept, dass in diesem Zusammenhang oft genannt wird, ist die Zielfixierung (im engl. target fixation). D.h. der Fahrer nimmt eine Gefahr war, z.B. ein Gegenstand auf der Strasse, und ist so sehr in der Angst gefangen, diesen Gegenstand zu überfahren, dass er den Blick nicht davon nehmen kann mit dem Ergebnis, dass er darüber fährt.

Was hat das nun mit emotionaler Blickführung zu tun? Durch einen Anlass, der hier keine Rolle spielt, hab ich mich in der Situation befunden, einem Freund in einer emotional herausfordernden Phase zu helfen. Dabei ist mir aufgefallen, dass das grösste Problem war, dass er sich so sehr mit den negativen Auswirkungen der Situation befasst hat, dass er völlig den Blick dafür verloren hat, was für ihn wichtig war und was er eigentlich erreichen wollte.

Das Problem ist sicher jedem auf die eine oder andere Art bekannt. Anstatt sich mit der Lösung zu beschäftigen, beschäftigt man sich nur mit dem Problem. Und das worauf wir uns konzentrieren wird zu unserem Fokus und damit verstärkt. Ich erinnere mich gerne an die Zeit zurück, als ich angefangen habe zu Segelfliegen. Damals hat sich mein Blick nach oben gewandt und ich war überrascht, wie viele Segelflieger es am Himmel gibt. Die waren selbstverständlich auch vorher da, nur habe ich da nie hingesehen. Genauso ist es mit emotionalen Fokus. Wenn ich mich ständig damit beschäftige, dass etwas negatives eintreten könnte, erhöht sich die Wahrscheinlichkeit, dass es passiert. Und selbst wenn es nicht eintritt, beeinflusst es mich doch negativ, da ich ständig diese Art Gedanken mit mir herumtrage.

Das positive an diesem Konzept ist, dass es genauso in die andere Richtung funktioniert. Beschäftige ich mich gedanklich mit etwas positiven, ändere ich in diesem Moment meine innere Haltung. Das kann so stark werden, dass meine Ausstrahlung das widerspiegelt. Meine Wahrnehmung ändert sich - Dinge, die vorher negativ betrachtet wurden, werden nun ignoriert oder in einem anderen Licht gesehen, mit dem Ergebnis, dass das Problem in den Hintergrund tritt.

In der Situation mit meinem Freund habe ich versucht ihm das klar zu machen. Geholfen hat hier, dass er früher auch Motorrad gefahren ist und somit mit dem Bild, das ich benutzt habe, direkt etwas anfangen konnte. Ich konnte ihm vermitteln, das seine Situationen immer wieder negativ ausgegangen sind, weil er durch seine Betrachtungsweise gar nicht zugelassen hat, dass sie sich anders entwickeln konnten.
Das Ergebnis von unserem Gespräch war beeindruckend. Er konnte das nächste Mal die Situation komplett drehen. Das ist sicherlich kein repräsentatives Beispiel, da es gerade in emotionalen Dingen häufig schwierig ist, den Fokus so komplett zu wechseln. Auch ist es in Beziehungen so, dass i.d.R. zwei Personen für das Ergebnis verantwortlich sind. Nur braucht es einen, der mit Veränderungen beginnt. Und es ist immer wieder erstaunlich, wie sehr sich eine Situation ändert, wenn man seine eigene Einstellung ändert und anpasst.

Alles in allem beschreibe ich hier nichts neues. Aber manchmal hilft ein anderes Bild ein Konzept neu zu begreifen.

Now officially a nerd :-)

Sometimes you have to do ridiculous stuff.... like taking a nerd test :-)

Programmers and design knowledge

A few days ago I stumbled across an interesting article on java.net. There a java guy (Giovani Salvador) who was doing several hirings complained about the lack of design and architectural knowledge of java developers. His point is, that nowadays developers only care about frameworks instead of the problem domain they are working in. In his examplary job interview he asked the developer in question to explain him what kind of architecture he would use for a medium sized enterprise application. Without thinking the developer answered he would use spring and hibernate and thats about it. Even after some more detailed questions the developer did not go in detail with the architecture of such an application but talked in terms of spring framework internals.

I understand the point of Mr Salvador, that it is more important to understand the problem domain of an application than think in terms of which frameowrk to use. In my current project (a 20 person project that has the goal to replace a 30 year old cobol application with a complex datawarehouse with java clients) the company we work for has severe restrictions of which frameworks we java developers could use and how. For example spring and hibernate were strictly forbidden. The reasons for this are many and as a consultant I was in no position to argue about that. So I had to come up with alternatives how to solve database abstraction and transaction handling and so on.

My team and I then created a simple framework using the well known Java and J2EE patterns (Value Objetcs, DAOs, Factories, Session Facades, Service Locater, ... just to name a few) and found a very elegant and simple but yet powerful solution for all these problems. We even found a very performant solution for our  query performance requirement. If an application has very high requirements for query performance I would almost always use the pure sql approach.  Maybe I am not skilled enough in the usage of hibernate or jpa, but none of these frameworks were as fast as the pure approach.

My bottom line of this is "think first, code second". The existing frameworks are all very nice and helpful and ease many things. But you always have to think about your problem first to decide if it is really neccessary to use this or that framework or even any at all. Sometimes like in my example, you mustn't use any at all. Then you are forced to come up with a good design. But even if you are given plenty of rope it is better to first think about the problem domain and how to solve this in an abstract fashion.

Purpose and hello

Hello dear readers,

this is blog is an attempt to express my thoughts on developing things (frameworks, applications, games, ...) and related topics. I really like every aspect of developing, espacially the design part. So this blog will also contains my thoughts on designing and architecture of programs. I often read articles of fellow developers or reknown architects and sometimes think things like "hey, this is interesting. I already encountered such a situation and could add some stuff and ideas to this". But until know I didn't had a place to put this and I lacked the courage to do this at all.

I hope you will enjoy reading my articles and maybe put your comments here. By the way, I decided to write my articles in english so I could reach more people as most of the developers are able to read english. But as I am a german guy please excuse my lack of style or bad grammer or whatever you encounter here :-)