Embedded Curmudgeon Column MTE June 2013 Ways of learning By Chris Hills

 

Embedded Curmudgeon, Chris Hills, looks at different routes to information enlightenment

I have just completed the gruelling schedule of working at three trade shows in ten days. A lot of driving, setting up, packing up and trying to eat healthy at 21:30, when all that is left is high-cholesterol specials and the only fruit is covered in batter and served with cream. Living in hotels when working is not as much fun as you might think!

At these events the workshops were popular, and well received: in my case I was co-presenting on MISRA C:2012 (C3). The interesting thing was the questions that sprang from the attendees, often on some of the incidental comments rather than the main points on the slides. These questions then generated some off-the-wall comments from another attendee, which would raise a serious question from some one else.

This reminded me of something that I have known for a long time: you can’t beat face-to-face meetings for transferring information. I called Glennan Carnie at training company, Feabhas. He carries out classroom training on embedded software development, including courses on MISRA C and I asked his opinion on face-to-face learning versus getting information from books or the internet.

Off the top of his heads he suggested that you only get 10% of the information from reading a book and 30 % from webinars where you get just the voice. But add in being able to see the person talk and watch their body language, and this increases to 60% plus. He also echoed my comments from last month’s column about using web forums and email, as with these channels, as people tend to not get the context, especially on international forums.

An interesting thing Glennan mentioned was that in communicating information, it is key to get across the concepts and philosophy: if you can manage that, then the facts fall into place almost automatically. This is interesting as my presentation at the three workshops was, Why MISRA C:2012 Won’t Save Your Project. It discussed the concepts of MISRA C and how to implement it at a conceptual and strategic level and I covered only one specific rule. I was slightly worried that people would want to know how we on the MISRA-C team, had changed the rules from C2 to C3.

Actually it turned out that it was far more useful to explain the concepts and processes as after that the question of implementing or deviating the rules sort of “fell into place”.

Lauterbach, also at the shows doing training on their high-end (and complex) emulators and debuggers, said much the same: while the actual buttons and menus are listed in the manuals it is only in a face-to-face dialogue that it is possible to communicate the concepts and strategies.

Face-to-face you can sense when a point has been made by the responses of the person you are talking to. Reading alone doesn’t establish the common understanding for concepts, but once you have the understanding of the concept, then you can read the books and understand not just what the button/switch etc does, but also why it is there in the first place and why it works the way it does. This understanding of the philosophy and concepts behind how the tool or emulator works allows you to make far better use of it. Going with the flow of the way it was designed to work means you can quickly get it to do a lot for you. Then, when you understand how it works and why it was designed that way, you can stand it on its head and get it to do other things.

Returning to the idea of how seeing a speaker improves information flow – at a recent meeting several people could participate only over Skype. An attendee physically present asked if the screen could be projected to allow those in the meeting to see the remote speakers, saying that the visual element added greatly to the audio stream. This reinforces Glennan’s earlier point. As well as picking up clues from body-language, sighted human beings incorporate some lip-reading into their listening. This is one reason that face-to-face meetings are more productive, and explains why the apparently useless projection of a speaker onto a screen helps the understanding of what is being said.

Things are improving in that there are a lot of webinars and videos but these are still one way and there is a dis-joint with the viewer. In fact you can demonstrate this for yourself. Attend a live webinar, one where you can make live text comments or better still where there is live two-way sound. Then watch a pre-recorded webinar. Notice the difference? Given that a good webinar is only 60% as effective as live meetings, then bad videos and recorded webinars are probably going to be less than 50% effective.

If you want information, as opposed to data, and you want to be able make good use of the information, don’t scour the internet for data sheets but spend a day in a classroom or at a seminar in a trade show. This applies to all those tools you need for your next project, or even the project you have already started. It is amazing how many people get half-way through a project before realising there is a better way or that they are missing a tool or two.

Even though the tool vendors and distributors are improving web sites with videos, webinars etc., even a couple of hours of video is not as effective a 30 minutes face-to-face at a trade show. More to the point, after the first chat you can read the brochures, perhaps over coffee and a doughnut, with far more understanding. Then you can go back to ask some more questions: if you can do this for a couple of competing tools, suddenly spending a day at a trade show starts to look very cost effective. And that is before the other random things that you see and hear at trade show. I wish I had a pound for every time some one has said: “I never knew that!” as they discovered something that “everyone knows”, because it was being talked about by others or because they saw something on a stand.

“Everyone knows” is a segue to an item by Nigel Jones on embeddedgurus.org about information blocks on source code. Now “everybody knows” that the point of information blocks is to give the reference to the specification and design requirements and, where appropriate, the input and output requirements. Because you all use version control there will also be a revision history. However, Nigel frequently finds a long legal/copy right notice that dwarfs the other information if, indeed, the other information is there at all. This misses the whole point of the information block. The whole philosophy and concept has been missed.

You do need a simple copyright statement - © Phaedrus Systems 2013. This is supplemented by a reference to the document that contains the full legalese. In the same way you will have references to the requirements and design documents (won’t you?)

Nigel has clearly had to work on projects where, although the code has survived, the documentation has not. He suggests that the information block should also provide the context – a description of the product that the code is for and what it supposed to be doing. And also information on the compiler used (with any settings), details of third-party libraries used, even the text editor settings. All the information that is lacking when you find yourself maintaining 20 year old legacy code. Especially when, in horror, you realise it may have been you that wrote it for the company that your current company bought last year.

On that cheerful thought have a good summer and hopefully I will see you at a trade show in the autumn.

 

 

 

Author Details and contact

 

Eur Ing Chris Hills BSc CEng MIET MBCS MIEEE  FRGS   FRSA is a Technical Specialist and can be reached at This Contact

 

Copyright Chris A Hills  2003 -2013
The right of Chris A Hills to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988

 

 

> EC-Index