Second help-yourself evening
Yesterday we had our second evening where we tried to cope with the teaching weaknesses of our lecturer. Since we already repeated the theoretical basics last time this instalment was mainly about diving in the code and trying to solve the different parts of the exercise.
For me this went not too well this time because we were stuck on an algorithm and altough I already had all puzzle parts of the solution in my head I couldn't put it together for a complete result. At least not in C code. I tried different styles of visualisation and drawings to sort my thoughts and wade through the logic but in the end one of my colleagues found a pseudocode solution on StackOverflow.com which we could use almost 1:1. And it showed me two things. Firstly I saw, that I've been already on the right track. And secondly it showed me the power of high-level languages. I mean I'm quite sure that a few years ago, when I still was working full-time on C/C++-code I could have solved this problem without much thought. But the comforts of high-level languages, all their frameworks and idioms, are so tailored to object-oriented solutions and splitting up the problems in small pieces that I'm not used to picking up so many different loose ends of a problem at once and combining them anymore. I'm very aware of the technological basics but I'm just not used to working at such a low level anymore.
I don't know if this is a good thing or not. On the one hand abstraction and frameworks make difficult problems easy to tackle with and one becomes more productive. But if those frameworks and abstractions are pulled away, many people (and now also including me) would have serious issues coming up with a solution. They know the theoretical path to finish the work but cannot translate it into actual code.On the other hand if there is hardware involved somewhere low level code has to be created to access the input/output and manage the data. On this level people are used to solving many problems by hand, over and over, just because they cannot use ready-made frameworks out of performance or space-constraints. But these people are unused to solving problems which span several logic units or business layers and I'm quite sure that most of them would struggle the same way if they would have to solve an abstract business-problem with workflows, rulebooks and similar frameworks.