Mucke-Ecke Phillo-Ecke

Tägliches Training, Teil 2: Fingerfertigkeit

Im zweiten Teil der Reihe „Tägliches Training“ widme ich mich dem Thema Fingerfertigkeit. Grundlage für das Training sollen hier die Etüden Nr. 3, 4, 5 und 17 aus der Schule der Geläufigkeit und Fingerfertigkeit Op. 135, Heft 1 von Hans Sitt (Friedrich Hofmeister Verlag) sein, aus denen ich vereinzelt zitiere.


Notes on Frameworks?

It came that I’ve recently been asked, which frameworks I’ve already worked with. That simple question made me kind of stuck in answering and I was going like „Uhh… aah, well… lots of…“. Later, resuming this conversation part, I came to the conclusion this happened, because I actually have been working with lots of frameworks. In fact, there were so many in so different constellations, that it failed me to give single and simple answer. Oops! I thought.

Well, programming libraries provide frameworks, frameworks provide APIs to work with. When for instance talking about web-based PHP applications, it’s about well-known PHP-frameworks, or maybe JavaScript frameworks and such. Implementing server-side backend applications for processing special sort of data structures may require other libraries/ frameworks.

There are so many different cases where various frameworks are in use. Obviously, I lacked to quick-sort that huge collection for an appropriate answer. Well, things happen, that’s okay. But I decided for myself that I’m going to pre-sort a bit for the next time.

Pre-sorting turned out to be a challenge. There had to be some sort criteria. Sorting by what? By programming language? By topic? By popularity? If I took one criterion, I felt the importance of another was missing. The more I was trying to sort I felt like creating chaos in my head. I decided to go for a little walk.

Airing on the riverside, I was asking myself how to answer a question more accurate, when the ostensible answer could only be „Well, any…“. Thinking futher about this, I guess it’s kind of a tricky question. Not on purpose by the questioner, but because of the question itself. Why? Because the question is generic.

But what is the interesting point about a generic question? Sure, there is no wrong question in this world. It’s often just hard to find an appropriate answer.

Imagine you’re some kind of social worker and you’ll be asked the following: „What methods did you work with?“. Well, accordig to what? Participation? (Child) care? Conflict management? There could be many more counter questions, I guess.

The tricky thing about a generic question is its missing context. In order to create an adequate answer, which surely is the desired intention of the questioner to hear, must exist some kind of context.

But, what to do, if the question does not present you any context because it’s generic? You can either go like me stummering around, which clearly seems not satisfying to both, the questioner and the answerer. Instead, try to create your own context! In the end, it’s pretty easy. First, think of projects you’ve worked on. Then, tell the questioner shortly about it. Now you have context where you can explain which kind of methods/ frameworks, or whatever has been asked for, you utilized. With that, you even create yourself the opportunity to give reasons why you preferred to chose one method/ API/ lib/ framework instead of another.

So, the thing I’m learning from this is: There is no need to pre-sort anything for any eventualities. Better tell your story wherein you embed one of those things you’ve been asked for and others in the next chapter.

The more generic the question is, the more freedom you have to create your own context to integrate your answer into. As freedom always coheres with responsibility, you should make use of the ability to put your answer into appropriate shape whenever possible. Easy said, but might be practiced!

However, I’m always thankful for learning from conversations!